數據庫復制：
簡單來說，數據庫復制就是由兩台服務器，主服務器和備份服務器，主服務器修改後，備份服務器自動修改。
復制的模式有兩種：推送模式和請求模式，推送模式是主服務器修改後，自動發給備份服務器，請求模式是，備份服務器自動去請求，個人開始也比較重視去測試兩個模式的差別，但是測試發現，其實兩個模式差別不是很大，在當今的服務器配置中，沒必要考慮這麼多，雖然會有一些差別，但是可在可以忽略的范圍之內，建議直接選擇推送模式，因為配置起來相對簡單
數據庫發布類型有三種：快照發布，事務性發布，具有可更新訂閱和事務性發布，合並發布
一般都會采用事務性發布，具體好處，就不說了，網上一大堆的
復制過程：
第一：點開數據庫--復制---本地發布---新建發布
下面只提供需要注意的地方，其他的點擊下一步即可
上面已經說了，推薦事物
一般只復制表即可，但是如果需要其他的，請自行考慮
快照，如果每天需要快照一次，那麼可以點擊下面的按鈕，如果只快照一次的話，就沒必要了
使用默認配置即可
這樣不出意外就完成了一個發布服務器的配置，那麼現在配置訂閱服務器
可以在你自己機器上直接操作
第一：點開數據庫--復制---本地發布---新建訂閱--
推送模式和請求模式，如果你不想找麻煩，建議直接使用推送模式
重點說一下復制過程中出現的錯誤
①：因為主服務器和備用服務器必須在一個局域網內，而且不能用IP連接，必須用主機名連接，那麼會出現使用主機名無法連接的情況，可能是因為修改過機器名，使服務器.sql和訪問和機器名不一致
使用一下查新，查看是否一致，如果不一致，使用下面代碼修改一下即可
select @@servername和 select serverproperty ('servername')
if serverproperty('servername') <> @@servername
begin
declare @server sysname
set @server = @@servername
exec sp_dropserver @server = @server
set @server = cast(serverproperty('servername') as sysname)
exec sp_addserver @server = @server , @local = 'LOCAL'
end
②：如果你使用的是推送模式，那麼最大的麻煩將會是讀取不到快照，一般錯誤為：
由於出現操作系統錯誤 3，進程無法讀取文件“D:\DBSYNC\unc\FLOORWEB_FLOORLINK2_TESTFLOOR\20081128174839\ufoCorpAccount_2.pre”。
這個原因是訂閱服務器讀取不到快照文件夾位置.可能的原因較多，最直接和簡單的解決辦法是：
將你的快照文件復制一份，復制到訂閱服務器上F:\XX，修改一下 某個訂閱屬性-》快照位置-》“備用文件夾”，快照文件夾-》F:\XX
錯誤的原因：第一次復制時，訂閱服務器需要到主服務器讀取快照，進行同步，然後主服務器因為權限問題，無法讀取這個快照，所以導致如上錯誤，將主服務器的快照復制到訂閱服務器，第一次直接根據這個快照進行同步就可以解決了
測試的一些結果：僅供參考
1.1：如果在訂閱服務器上修改數據（例如update或delete），這個時候主服務器操作後，會報錯，直接會停止服務
1.2： 重新初始化訂閱的時候，最好使用最新快照，不要使用當前快照，會死人的，因為他會從開始到結束的快照以後的操作全部執行一次，例如，你插入了1000w，刪除了1000w，你使用當前快照，可以直接同步了，如果使用以前的，會將這兩個步驟全部執行的
1.3：在百萬數據插入過程中，內存使用大約150-200mb左右，和平時本來就占用120mb左右的內存相比，可以直接忽視
1.4：速度方面，500w的數據插入，在最後400-500w的時間約為7分鐘，插入100w的數據庫量，同步大約需要8-10分鐘
