AlwaysOn是在SQL Server 2012中新引入的一種高可用技術，從名稱中可以看出，AlwaysOn的設計目標是保持數據庫系統永遠可用。AlwaysOn利用了Windows服務器故障轉移集群（Windows Server Failover Clustering，簡稱WSFC）的健康檢測和自動故障轉移的特性，因此，必須建立在WSFC之上，搭建WSFC的過程，請參考《部署AlwaysOn第一步：搭建Windows服務器故障轉移集群》。

AlwaysOn支持的高可用單位是可用性組（Availability Group，簡稱AG），AG是包含了一個或多個用戶數據庫（User Database）

一，AlwaysOn的基本架構

1，了解AlwaysOn的關鍵特性

• AlwaysOn支持的故障轉移，不是以整個SQL Server實例為單位，而是以AG為單位，AG中的多個用戶數據庫一起進行故障轉移；
• AG提供虛擬的服務器網絡名，也就是AG Listener，無論哪臺服務器是當前的Primary Server，客戶端都可以使用統一的AG Listener進行連接；
• AlwaysOn在輔助服務器（Secondary Server）上維護用戶數據庫組的副本，同步提交方式能夠使Primary Server和Secondary Server上的數據保持完全同步；
• 在特定的配置情況下，客戶端的只讀請求可以被自動定向到輔助服務器，減少了Primary Server的IO壓力；
• 一臺主服務器最多對應4臺輔助服務器，總共5臺服務器，發生故障轉移時，可以切換到任意一臺輔助服務器上；

2，推薦安裝SQL Server單機實例（stand-alone）

部署AlwaysOn之前，必須搭建WSFC環境；在Windows集群的結點上，推薦安裝SQL Server單機實例，AlwaysOn僅要求所有的SQL Server實例都運行在同一個Windows集群環境中，但SQL Server實例本身不需要是集群模式的，推薦安裝SQL Server單機實例。在SQL Server安裝中心中，選擇“全新SQL Server獨立安裝或向現有安裝添加功能（New SQL Server stand-alone installation or add features to an existing installation）”。

3，可用性數據庫（Availability Database）

AlwaysOn可用性組裏包含一個或多個用戶數據庫，稱作可用性數據庫（Availability Database），每個可用性副本上都存儲可用性數據庫的副本，這些數據庫副本彼此之間互相同步，如果可用性副本是SQL Server單機實例，那麽數據庫副本就存儲在實例的本地磁盤（Local Disk）中。可用性組不能包括系統數據庫，就是說，系統數據庫不能通過AlwaysOn實現高可用性。

在多個可用性副本上，只有一個可用性副本上運行的數據庫處於可讀寫狀態，這個可讀寫的數據庫稱作Primary Database，這個可用性副本稱作Primary Replica，其余的副本都稱作輔助副本（Secondary Replica），輔助副本上的數據庫可能是不可訪問的，或者是只讀的，這些數據庫稱作輔助數據庫。一旦發生故障轉移，任何一個輔助副本都可以成為新的Primary Replica，主副本會不斷地將Primary database上的數據更新發送到輔助副本，實現副本間的數據同步。

4，AG是集群的資源組

從WSFC的角度來看，AG是集群的資源組，因此，AG中包含的所有用戶數據庫是作為一個整體在集群的結點之間進行故障轉移的，這使得AlwaysOn非常適合那些需要用到多個數據庫的應用程序。

5，偵聽器（Listener）

在故障轉移集群管理器（Failover Cluster Manager）中，WSFC只能看到一個資源組，就是AlwaysOn的可用性組（AG），但是應用程序不能使用資源組的名字登錄SQL Server實例，必須知道當前主副本（Primary Replica）的名字，使用這個服務器名稱連接SQL Server實例。一旦發生可用性組（AG）的故障轉移，應用程序必須通過修改連接字符串（Connection String）重新連接到新的Primary Replica上，這很麻煩。通過可用性組偵聽器（Availability Group Listener，簡稱Listener），能夠解決該問題。Listener是一個虛擬的服務器，用於讓應用程序透明的連接到主副本而不會受到故障轉移的影響，一個Listener包含虛擬的網絡名（DNS Name），虛擬IP地址和端口號。創建了Listener之後，WSFC就會為可用性組資源添加虛擬IP地址和虛擬網絡名資源，應用程序通過連接虛擬網絡名，連接主副本（Primary Replica）上的SQL Server實例。

應用程序使用Listener的虛擬網絡名連接SQL Server實例，是以一個默認實例的形式訪問的，只有服務器名，沒有SQL Server實例名，因此應用程序不會嘗試使用SQL Brower 服務。推薦AlwaysOn的各個副本都使用默認實例，默認端口。如果Listener使用的端口號是默認端口1433，那麽應用程序能夠直接使用虛擬網絡名連接到SQL Server實例。

二，AlwaysOn的數據同步原理

AlwaysOn會在各個副本上維護數據庫的副本，主副本上發生的數據更新，都會同步到輔助副本上，為了實現數據同步，AlwaysOn需要完成三個任務：

• 把主副本上發生的數據更新的事務日誌記錄下來；
• 把事務日誌記錄傳輸到各個輔助副本；
• 在各個輔助副本上重做數據更新；

在主副本和輔助副本上，SQL Server都會啟動相應的線程來完成相應的任務。

1，日誌持久化

任何一個SQL Server都有個Log Writer線程，當事務提交一個數據更新時，Log Writer把數據更新的日誌寫入到物理事務日誌文件。

2，主副本的日誌傳輸

對於配置AlwaysOn 主副本的數據庫，SQL Server創建一個Log Scanner線程，負責將日誌記錄從日誌緩沖區或者事務日誌文件讀出，打包成日誌塊，發送到各個輔助副本，由於Log Scanner線程的不間斷工作，使得主副本上的數據變化，不斷地向輔助副本上傳播。

3，輔助副本上的固化（Harden）和重做（Redo）

在輔助副本上，同樣有兩個線程固化線程和重做線程完成相應的數據更新操作。固化線程將主副本上Log Scanner傳入的日誌塊寫入輔助副本的硬盤上的事務日誌文件裏，而重做線程，負責從硬盤上讀取事務日誌，將日誌記錄翻譯成數據更新操作，在輔助副本的數據庫上重做主副本的數據更新操作。

當重做線程完成工作之後，輔助副本上的數據庫和主副本保持同步，重做線程每隔固定的時間間隔，就會向主副本報告自己的工作進度，主副本根據各個輔助副本的工作進度，就能計算數據的差異。

在AlwaysOn中，在固化線程和重做線程是完全獨立工作的，固化線程負責將主數據庫傳遞的日誌寫入到硬盤上的日誌文件中，將日誌持久化存儲；而重做線程負責讀取和翻譯已被固化線程存儲的日誌，將主數據庫上的數據更新操作在輔助數據庫上重新執行。

三，AlwaysOn的可用性模式

可用性模式決定了主副本在提交事務之前，是否需要等待某個輔助副本將事務日誌記錄固化到硬盤，AlwaysOn可用性組支持兩種可用性模式：異步提交模式和同步提交模式。

1，異步提交模式

當輔助副本處於異步提交模式時，主副本無需等待輔助副本完成日誌固化，就可以提交事務，因此，主副本事務提交不會受到輔助數據庫的影響而產生等待，但是，輔助數據庫的更新會滯後於主數據庫，如果發生故障轉移，可能會導致某些數據更新丟失。

在異步提交模式下，輔助副本會盡量和主副本的日誌記錄保持一致，不過，即使輔助數據庫和主數據庫上的數據是同步的，可用性組始終認為輔助數據庫處於“在同步”（SYNCHRONIZING）狀態，因為，理論上在異步模式下，輔助數據庫在任何時間點都可能滯後於主數據庫。

2，同步提交模式

在同步提交模式下，主數據庫在提交事務之前，主副本必須等待輔助副本將日誌固化到硬盤上，主副本只有收到來自輔助副本的日誌固化成功的確認信息之後，才能提交事務；只要輔助副本沒有向主副本報告日誌固化完成，主副本上的事務就不能提交。這樣能夠保持主副本和輔助副本的數據始終是同步的，只要一直進行數據同步，輔助數據庫就會保持”已同步“（SYNCHRONIZED）狀態。

同步提交模式能夠實現輔助數據庫和主數據庫上的數據的完全同步，但是，代價是主數據庫上的事務提交延遲增加，可以說，同步提交模式相對於性能來說，更強調高可用性。

3，可用性副本之間的短線連接狀態

”DISCONNECTED“連接狀態：AlwaysOn可用性組之間有一個會話超時機制，默認值10s。主副本和輔助副本之間，按固定的時間間隔相互發送ping，在會話超時時間內，如果主副本收到輔助副本的ping命令，就說明副本之間的連接正常；一旦某個輔助副本因為故障而不能響應，產生會話超時，主副本將該輔助副本的連接設置為”DISCONNECTED“連接狀態，即使使用同步提交模式，主副本的事務也不需要等待該副本的響應就可以提交。

4，輔助數據庫的”NOT SYNCHRONIZING“狀態

無論使用什麽可用性模式，如果一個事務在輔助數據庫上重做失敗，就會導致輔助副本進入”NOT SYNCHRONIZING“狀態，即使處於同步提交模式，主副本的事務也不需要等待該副本的響應就可以提交。

如果用戶想中斷數據庫的數據同步，而不想影響可用性組中的其他數據庫，可以通過在SSMS中選擇Suspend Data Movement來手動掛機，掛起之後，該數據庫在各個可用性副本上的狀態都會變成”NOT SYNCHRONIZING“狀態。

四，AlwaysOn的故障轉移

當WSFC觸發故障轉移之後，一個輔助副本被選擇成為新的主副本角色，該副本上的SQL Server實例對可用性數據庫執行恢復操作，使其成為新的主數據庫；在故障轉移完成之後，如果原先的主副本還可用，那麽它就成為輔助副本，它上面的數據庫就成為了輔助數據庫。

但AlwaysOn發現故障之後，是否立即出發故障轉移呢？這取決於可用性副本的可用性模式和故障轉移模式，如圖：

只有主副本和轉移的目標副本都配置為”同步提交模式+自動故障轉移“模式時，才能實現兩個可用性副本之間的自動故障轉移。在三種故障轉移模式中，只有強制故障轉移可能丟失數據。自動故障轉移和手動故障轉移，都必須配置在同步提交模式下，必須數據庫都處於SYNCHRONIZED狀態。對於異步提交模式的輔助副本，無論數據是否已經達到同步，都只會處於SYNCHRONIZING狀態，只能支持強制故障轉移。

五，創建可用性組

1，在創建AG之前，配置SQL Server實例啟用AlwaysOn

在SQL Server配置管理器（SQL Server Configuration Manager）中打開SQL Server 實例的屬性，輸入Windows 故障轉移集群的名稱，並勾選“Enable AlwaysOn Availabilitty Groups”選項啟用AlwaysOn 可用性組，在所有可用性副本上都啟用SQL Server實例的AlwaysOn 可用性組。

2，使用SSMS連接任意主副本的SQL Server實例，打開新建AG向導（New Availability Group Wizard）

連接到主副本，是因為該副本上擁有所有的可用性數據庫，如果所有的可用性副本上都有相同的數據庫副本，那麽可以連接任意一個副本。

3，指定AG的名字，勾選“Database Level Health Detection”選項

4，選擇可用性數據

從數據庫列表中需要添加到可用性組中的數據，這些數據庫將成為一個整體一起發生故障轉移，本例勾選Test_DW。

添加到可用性組中的數據庫必須滿足一定的要求：

• 數據庫可以讀寫；
• 數據庫的恢復模式是FULL；
• 數據庫已經做過完整備份；

5，添加可用性副本

使用“Add Replica”添加可用性副本，在Availability Replicas列表中，能夠查看各個可用性副本的配置：

• Server Instance：副本的實例名稱
• Initial Role ：是副本初始角色，Primary是主副本，Secondary是輔助副本；
• 勾選“Automatic Failover” ：副本的故障轉移模式是自動故障轉移；
• 勾選“Synchronous Commit”：副本的可用性模式是同步提交模式；
• “Readable Secondary”：可讀的輔助副本，主數據庫是可讀寫的，輔助數據庫可以設置為可讀的；

6，創建Listener

創建一個可用性組的偵聽器，實際上是虛擬的服務器，

• Listener DNS Name：網絡名，命名為TestAGListener；
• Port：推薦使用默認端口1433；
• Network Mode：IP地址的分配方式，建議使用Static IP，本例使用DHCP；
• Subnet：子網，系統自動設置；

7，選擇如何在輔助副本上初始化AG中的數據

FULL：向導自動對主數據庫做完整備份和日誌備份，並將備份文件存放在共享目錄中，其他副本通過共享目錄獲得數據庫的備份，並在各自的SQL Server實例上還原數據庫。通過FULL初始化方式，必須確保主副本上的存儲主數據庫文件的路徑在輔助副本上也存在，即數據庫文件的存儲路徑一致。

Join Only：如果已經手動在各個輔助副本上還原了數據庫，使用該選項，將各個輔助副本直接加入到可用性組中。

Skip Initial data sync：跳過該步驟，用戶需要手動在主副本上對數據庫做完整備份，並還原到所有的輔助副本，然後通過SSMS將數據庫添加到可用性組中。

推薦將主數據庫和輔助數據庫的文件路徑保持一致。

8，成功創建可用性組

執行後續的Validation和Summary之後，向導開始創建可用性組，在創建完成之後，使用SSMS打開“AlwaysOn High Availability”，能夠看到創建成功的可用性組：“TestAG”，括號中的Primary表示當前的可用性副本是主副本（Primary Replica）。

到此，AlwaysOn部署完成，可以通過SSMS連接Listener，登錄Primary Replica上的 SQL Server 實例。

參考文檔：

《SQL Server 2012 實施與管理實戰指南》第三章

虛擬化IDC的高可用和高可靠性解決方案

從0開始搭建SQL Server AlwaysOn 第三篇（配置AlwaysOn）

AlwaysOn Failover Cluster Instances (SQL Server)

部署AlwaysOn第二步：配置AlwaysOn，創建可用性組