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

AlwaysOn是在SQL Server 2012中新引入的一種高可用技術，從名稱中可以看出，AlwaysOn的設計目標是保持資料庫系統永遠可用。AlwaysOn利用了Windows伺服器故障轉移集群（Windows Server Failover Clustering，簡稱WSFC）的健康檢測和自 ...

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

AlwaysOn支持的高可用單位是可用性組（Availability Group，簡稱AG），AG是包含了一個或多個用戶資料庫（User Database）的容器，AG里不能包含系統資料庫；AG以用戶資料庫的集合為單位進行健康檢測和故障轉移，就是說，AG中的所有資料庫作為一個整體發生故障轉移。

一，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的可用性組是集群的資源組，資源類型是“SQL Server Availability Group”，AlwaysOn的故障轉移建立在WSFC的健康檢測和故障轉移的特性之上，由於，WSFC的故障轉移是以資源組為單位的，因此，AlwaysOn的每次故障轉移都會將整個可用性組裡的資料庫一起轉移。

1，查看集群的資源組

打開故障轉移集群管理器（Failover Cluster Manager），選中集群結點，點開Roles，能夠看到創建成功的可用性組 TestAG，角色類型（Type）是Other；