SQL Sever AlwaysOn的數據同步原理
1. SQL Server AlwaysOn數據同步基本工作
AlwaysOn 副本同步需要完成三件事：
1．把主副本上發生的數據變化記錄下來。
2．把這些記錄傳輸到各個輔助副本。
3．把數據變化在輔助副本上同樣完成一遍。
這3件工作主要由以下4個線程完成
Log Writer線程：當任何一個SQL用戶提交一個數據修改事務時，它會負責把記錄本次修改的日誌信息先記入一段內存中的日誌緩沖區，然後再寫入物理日誌文件（日誌固化）。
Log Scanner工作線程：位於主副本所在SQL Server上。這個線程專門負責將日誌記錄從日誌緩沖區或者日誌文件裏中讀出，打包成日誌塊，發送給各個輔助副本。由於它的不間斷工作，才使主副本上的數據變化，可以不斷地向輔助副本上傳播。
固化（Harden）線程和重做（Redo）線程：位於輔助副本所在的SQL server上。固化線程會將主副本Log Scanner所發過來的日誌塊寫入輔助副本的磁盤上的日誌文件裏（這個過程被稱為"固化"）。而重做線程，則負責從磁盤上讀取日誌塊，將日誌記錄翻譯成數據修改操作，在輔助副本的數據庫上完成。
這些線程在工作上各自獨立，以達到更高的效率。Log Scanner負責傳送日誌塊，而無須等待Log Writer完成日誌固化；輔助副本完成日誌固化以後就會發送消息到主副本，告知數據已經傳遞完畢，而無須等待重做完成。其設計目標，是盡可能地減少AlwaysOn所帶來的額外操作對正常數據庫操作的性能影響。
AlwaysOn的數據同步有可分為異步提交和同步提交
2. AlwaysOn同步提交模式
在同步提交模式下由可分為 輔助副本發出同步請求和主副本發出同步請求。
2.1 輔助副本發出同步請求
此情況，主要發生在輔助副本剛剛加入可用性組、或者網絡等原因主副本出現差異、或者輔助副本出現臟頁（物理）等少數情況下。
|
步 驟 |
行 為 |
| 1.連接 | 輔助副本通過主副本的鏡像端點建立兩者之間的連接。 |
| 2.請求數據 |
輔助副本發出一個請求到主副本，要求主副本發送日誌塊。輔助副本和主副本 會協商出一個日誌塊的LSN初始位置以及一些其他的信息。 |
| 3.運行Log Scanner |
在主副本上，Log Scanner的工作線程開始工作。Log Scanner負責將日誌塊 傳送到輔助副本。 |
| 4.固化和重做日誌 |
輔助副本會使用固化（Harden）線程和重做（Redo）線程的工作線程來處理 Log Scanner發送過來的日誌塊，固化線程將日誌塊固化到輔助副本的磁盤上 ，而重做線程負責將日誌中記錄的事務在輔助副本上重新演繹。 |
| 5.反饋進度 |
每當輔助副本收到3條來自主副本的消息的時候，就把固化和重做的進度作為 一個消息返回給主副本。如果超過1秒還沒收到3條消息，進度消息也會被返回。 反饋到主副本的消息裏包含了哪些LSN已經在輔助副本上被重做和固化。 |
2.1 主副本發出同步請求，即客戶端提交SQL請求觸發的同步請求
| 步 驟 | 行 為 |
| 1.提交事務 | 在主副本上運行COMMIT TRAN命令來提交事務. |
|
2.寫入到本 |
在主副本上，COMMIT TRAN命令會被寫成一條日誌記錄（此時記錄還在主數據庫的日誌緩存中）. 然後主副本上的log writer工作線程會把直到COMMIT命令為止的所有日誌記錄組成一個日誌塊 從緩存寫入到磁盤上的LDF文件中。當日誌被寫入到磁盤之後，主數據庫就開始等待來自輔助副本 的消息來確認日誌在輔助數據庫上被成功寫入磁盤。在這之前，該事務提交操作會保持等待。 |
| 3.掃描日誌 |
當日誌塊開始被從緩存寫入到磁盤上時，它也會發信號給Log Scanner工作線程，告訴 Log Scanner“日誌已經準備好了，可以被發送到輔助副本上”。Log Scanner從緩存中取出 日誌塊，把它發送給AlwaysOn的日誌塊解碼器（Log Block Cracker）。解碼器會搜索日誌 中那些需要特別處理的操作，比如file stream操作，文件增長等。解碼器會把這些操作作為 一個消息發送給輔助副本。一旦日誌塊被解碼完畢，整個日誌塊也會被作為消息發送給輔助副本. |
| 4.處理日誌塊消息 |
日誌塊消息在輔助副本上得到處理。固化線程負責將日誌固化到磁盤上。然後日誌被保存到輔助 數據庫的日誌緩存中，重做線程從緩存中獲得日誌塊並開始執行重做操作. |
| 5.反饋進度 |
每當輔助副本收到3條來自主副本的消息時，就把固化和重做的進度作為一個消息返回給主副本。 如果超過1秒還沒收到3條消息，進度消息也會被返回。進度信息中包含當前哪些LSN被固化了， 哪些LSN已經被重做了。由於重做線程晚於固化操作啟動，被固化的LSN可能會多於被重做的LSN. |
| 6.完成提交 | 主數據庫受到了輔助副本來的確認消息，完成事務提交處理並向客戶端發送一條確認消息. |
2. 補充說明
- 在同步提交模式下，日誌塊必須在主副本和輔助副本上都被固化到磁盤上，事務才能真正在主數據上提交。但是它並不要求日誌在輔助副本上完成重做，這樣可以減輕對主副本的性能影響。
- 進入DISCONNECTED或"NOT SYNCHRONIZING"狀態後，即使可用性副本處於同步提交模式，事務也不需要等待該副本的響應就可以在主副本上提交。
- 如果為當前主副本配置了異步提交可用性模式，則它將通過異步方式為所有輔助副本提交事務，而不管這些副本各自的可用性模式設置如何。
- 它可以保證事務日誌是同步的，也就是可以保證不丟失數據，但不能保證數據變化沒有延時，這是由於輔助副本在接收主副本傳來的Trans log時，首先將其緩到本地Log Cache，接著強制硬化到本地Ldf，然後隨即向主副本告知你可以commit了，但註意，此時的硬化到本地ldf並非本地數據已經變化，這是因為輔助副本將trans log硬化到本地的同時，它是使用一個異步進程去redo這些trans log產生的Page變化到Data文件的，所以數據的延時就是肯定的了。
3.AlwaysOn異步提交模式
- 當輔助副本處於異步提交模式下時，主副本無須確認該輔助副本已經完成日誌固化，就可以提交事務。因此，主數據庫事務提交不會受到輔助數據庫的影響而產生等待。
- 對於主副本和輔助副本相隔很遠而且不希望小錯誤影響主副本性能的災難恢復方案，異步提交模式將會很有用。而且，由於主副本不會等待來自輔助副本的確認，因而輔助副本上的問題從不會影響主副本。
- 在異步提交模式下，輔助副本會盡量與自主副本的日誌記錄保持一致。不過，即使輔助數據庫和主數據庫上的數據事實上是同步的，可用性組也始終認為輔助數據庫處於“SYNCHRONIZING”狀態（即“未同步”狀態）。
部分內容參照書籍《SQL Server 2012 實施與管理實戰指南》，感謝原作者。
SQL Sever AlwaysOn的數據同步原理