alwayson的同步提交和異步提交

1.2 同步提交與異步提交
2016-6-1 高可用性

1.2.1 日誌傳輸
AlwaysOn 可用性組、數據庫鏡像等解決方案須要爲主數據庫創建一個或多個「熱備用」或「溫備用」的輔助副本，所以須要在主數據庫和輔助副本之間傳送數據。

SQL Server 2005 SP1 引入了數據庫鏡像技術經過 TCP 5022 端口在各個節點計算機之間進行日誌傳輸。輔助副本收到了「新的」事務日誌後，先進行harden（固化），再執行 redo，從而保證各節點之間的數據一致。

在這種日誌傳輸的工做模式中，主節點將有2個進程：一個進程收集事務日誌；另外一個進程監視日誌傳輸。輔助節點也有2個進程：一個進程接收日誌；另外一個進程監視 redo。

根據主數據庫是否等待輔助副本 harden 反饋信息，同步模式分爲同步提交和異步提交。

1.2.2 同步提交模式
同步提交時，須要通過一系列的過程。

（1）主數據庫在將事務日誌寫入文件的同時就傳送給輔助數據庫。而後主數據庫等待輔助數據庫的迴應。

（2）輔助數據庫收到了來自主數據庫的事務，寫入本地事務日誌文件（固化），而後發送確認信息給主數據庫。

（3）主數據庫收到輔助數據庫發來的確認信息，結束等待狀態，繼續運行。

（4）主數據庫在遇到檢查點時纔將緩存中的「髒頁」回寫到數據文件；輔助數據庫根據收到的事務在本地進行重作（Re-do）。

同步提交模式能夠保證時刻擁有着如出一轍的副本，所以具備極高的安全性。可是輔助服務器接收事務日誌、寫入事務日誌文件和發送確認信息這一系列過程也會帶來必定程度的延遲，從而影響到主數據庫的性能。

因爲同步提交對性能影響較大，所以 SQL Server 僅容許單向的同步提交（從一個主副本單向同步到多個輔助副本）。並且，SQL Server 嚴格限制了同步提交的副本數量，AlwaysOn 可用性組的一個主副本最多能夠同時向 2 個輔助副本實現同步提交，其餘副本則使用異步提交模式。。

1.2.3 異步提交模式
異步提交時，主數據庫將事務發送給輔助數據庫後，無需等待而直接繼續運行。

異步提交模式消除了主數據庫的等待狀態，所以這種提交模式對性能幾乎沒有影響。可是輔助數據庫可能遇到更新數據失敗的狀況（例如，因網絡故障致使未接受主數據庫的事務，或寫入本地事務日誌日誌文件時遇到錯誤），而此時主數據庫若是發生故障則可能形成數據丟失。