隨着公司業務的發展，數據量增長迅速，在解決Scale Out的同時，還要考慮到主從的復制延遲問題，盡量降到1s以內滿足線上業務，如果不調整，SQL Server默認的配置可能平均要3s左右。生產的復制架構采用的是推送方式進行事務復制，發布服務器下面有4個從節點，兩兩指向同一虛擬IP，構成負載均衡，服務於不同的線上業務。對於4個節點，發布庫和分法庫的壓力都很大，訂閱庫每秒I/O能達到5M，高峰時能達到數十兆。研究並試驗了一些時間，給出一些優化建議：
1.硬件、數據庫設計：
- 使用SSD磁盤，有錢的可以使用PCI-e卡，SSD做RAID10，所有節點部署在內網。
- 更改事務隔離級別為READ_COMMITTED_SNAPSHOT。說實話，SQL Server默認事務隔離級別是讀已提交，但是沒有多版本的概念，需要設置為READ_COMMITTED_SNAPSHOT才是我們理解上的讀已提交。如果不設置這個，照樣會讀寫互相阻塞。
- 在創建訂閱之前，先將目標數據庫的恢復模式改成簡單，能夠減少日志
ALTER DATABASE [數據庫名稱] SET RECOVERY SIMPLE WITH NO_WAIT
2.發布、訂閱設計：
- 僅發布需要的數據，對於將日志寫入數據庫而且還要同步復制的，DBA可直接拒絕。
- 表中存在大量非聚集索引，發布時可以不勾選復制非聚集索引選項。經過測試，雖然數據庫引擎是在應用完快照最后創建索引的，但創建時間很長，有時甚至會出錯。可以在后期手工建立。我們采用導出腳本方式，然后只保留非聚集索引的腳本在訂閱庫中建立。
- 如果資源允許，單獨建立一個分發服務器。發布和分發服務器在一個服務器上會增加性能損耗，尤其是分發服務器下面有多個訂閱服務器時。
- 分發庫默認是distribution庫，會有專門的作業對該庫進行清理，名字就叫“分發清除：distribution”。但這個進程清除分發庫的效率太低了，會導致分發庫積累大量數據，需要修改運行間隔和每次清楚的數據量。詳見之前的隨筆：distribution庫過大的問題
- 合理使用訂閱方式，如果選擇推送訂閱，勢必加大分發服務器的壓力，但延遲低 ；如果選擇請求訂閱，代理服務是在訂閱服務器上，減少了分發服務器壓力，但延遲會增加。
- 快照代理的生成。對於生成幾百GB數據庫的快照，采用SSD盤可能在10分鍾左右。但會造成很高的性能損耗，要在業務非高峰期生成快照。快照代理文件也要放在SSD盤上，如果資源允許，單獨一個驅動盤也可以。
- 如果已經有備份了，那么可以通過備份直接來初始化訂閱，省去了生成快照和應用快照的步驟。
- 新發布新的表對象，對於發布庫很大的情況下重新初始化是不實際的，可以增量發布，詳見sqlserver同步后在不重新初始化快照的情況下新增表
- 對於已發布的表有批處理更新，一種方法是將批量更新分成若干小批量執行，減小事務處理的數據量；另一種方法是通過存儲過程執行更改，並將存儲過程發布。推薦第一種
- 將項目分布在多個發不上，這樣相當於變向的實現了多線程並行發布，當然也可以通過參數實現並行，下面會講到
3.參數優化：
- 降低復制代理的詳細級別，在初始測試、監視或調試期間除外。 減小分發代理或合並代理的 –HistoryVerboseLevel 參數和 –OutputVerboseLevel 參數。這樣可以減少為跟蹤代理歷史記錄和輸出而插入的新行數。相反，具有相同狀態的以前的歷史記錄消息將更新為新的歷史記錄信息。提高測試、監視和調試的詳細級別，這樣就可以獲得有關代理活動的盡可能多的信息。在系統開銷不是很大的情況下，建議使用默認值1，本身這點對性能消耗可以忽略。
- 增大快照代理的BcpBatchSize參數，-BcpBatch參數表示一個批事務的行數。
- 將快照代理的- MaxNetworkOptimization設置為1，減少將不必要的信息發送到訂閱服務器上。
- 使用快照代理、分發代理的 –MaxBcpThreads 參數（指定的線程數不應超過計算機上的處理器數）。此參數指定創建和應用快照時可以並行執行的大容量復制操作的數目。
- 為分發代理使用 –SubscriptionStreams 參數。 –SubscriptionStreams 參數可以顯著提高聚合復制吞吐量。它使到一台訂閱服務器的多個連接可以並行應用批量更改，同時在使用單線程時保持多個事務特征的存在。如果有一個連接無法執行或提交，則所有連接將中止當前批處理，而且代理將用單獨的流重試失敗的批處理。在重試階段完成之前，訂閱服務器上會存在臨時事務不一致。失敗的批處理成功提交后，訂閱服務器將恢復到事務一致狀態。官方文檔有這個參數，但增加這個參數報錯。
- 增大分發代理的 -CommitBatchSize 和CommitBatchThreshold參數的值。 提交一組事務的開銷是固定的；通過不經常提交大量事務，就可以將開銷分散在大量數據上。但是，增大此參數的優勢因應用更改的開銷由其他因素（例如包含日志的最大磁盤 I/O）限制而降低。另外，需要考慮以下權衡問題：任何導致分發代理重新開始的失敗必須回滾並重新應用大量事務。對於不可靠的網絡，越小的值導致失敗的幾率越小，如果導致失敗，將回滾並重新應用較少量事務。
- 增大日志讀取器代理的 -ReadBatchSize 參數的值。-ReadBatchSize 表示日志讀取器代理和分發代理支持事務讀取和提交操作的批大小。批大小的默認值為 500 個事務。日志讀取器代理從日志中讀取特定數量的事務，而不管這些事務是否標記為復制。將大量事務寫入發布數據庫，而其中只有一小部分標記為復制時，則應使用 -ReadBatchSize 參數增加日志讀取器代理的讀取批大小。此參數不適用於 Oracle 發布服務器。
- 為日志讀取器代理使用 –MaxCmdsInTran 參數。–MaxCmdsInTran 參數指定日志讀取器向分發數據庫寫入命令時組成一個事務的語句的最大數量。使用此參數能夠使日志讀取器代理和分發代理在訂閱服務器上應用命令時將發布服務器上的大事務（由許多命令組成）分成若干個較小的事務。指定此參數可以減少分發服務器的爭用問題並縮短發布服務器與訂閱服務器之間的滯后時間。由於初始事務是以較小的單元應用的，訂閱服務器可以在初始事務結束之前訪問一個較大的邏輯發布服務器事務的行，因而會破壞事務的原子性。默認值為 0，這將保持發布服務器的事務邊界。官方文檔有該參數，但實際設置里面沒有。
- 減小日志讀取器代理和分發代理的 -PollingInterval 參數的值。 -PollingInterval 參數指定為要復制的事務查詢已發布數據庫的事務日志的頻率。默認值為 5 秒。如果減小此值，日志的輪詢將更加頻繁，這會使事務從發布數據庫傳遞到分發數據庫的滯后時間較低。但是，應該對較低滯后時間的需要和因頻繁輪詢導致的服務器上增加的負荷之間進行平衡。