一、alwayson概念

“可用性組” 針對一組離散的用戶數據庫（稱為“可用性數據庫” ，它們共同實現故障轉移）支持故障轉移環境。 一個可用性組支持一組主數據庫以及一至八組對應的輔助數據庫(包括一個主副本和兩個同步提交輔助副本)。 輔助數據庫不是備份，應繼續定期備份您的數據庫及其事務日誌。

每組可用性數據庫都由一個“可用性副本” 承載。 有兩種類型的可用性副本：一個“主副本” 和一到四個“輔助副本”。 它承載主數據庫和一至八個“輔助副本” ，其中每個副本承載一組輔助數據庫，並用作可用性組的潛在故障轉移目標。 可用性組在可用性副本級別

主副本使主數據庫可用於客戶端的讀寫連接。 此外，它在稱為“數據同步” 的過程中使用，在數據庫級別進行同步。 主副本將每個主數據庫的事務日誌記錄發送到每個輔助數據庫。 每個次要副本緩存事務日誌記錄（“硬化”日誌），然後將它們應用到相應的輔助數據庫。 主數據庫與每個連接的輔助數據庫獨立進行數據同步。 因此，一個輔助數據庫可以掛起或失敗而不會影響其他輔助數據庫，一個主數據庫可以掛起或失敗而不會影響其他主數據庫。

或者，您可以配置一個或多個輔助副本以支持對輔助數據庫進行只讀訪問，並且可以將任何輔助副本配置為允許對輔助數據庫進行備份。

部署 Always On 可用性組 需要一個 Windows Server 故障轉移群集 (WSFC) 群集。 給定可用性組的每個可用性副本必須位於相同 WSFC 群集的不同節點上。 唯一的例外是在遷移到另一個 WSFC 群集時，此時一個可用性組可能會暫時跨兩個群集。

為您創建的每個可用性組創建一個 WSFC 資源組。 WSFC 群集將監視此資源組，以便評估主副本的運行狀況。 針對 Always On 可用性組 的仲裁基於 WSFC 群集中的所有節點，而與某一給定群集節點是否承載任何可用性副本無關。 與數據庫鏡像相反，在 Always On 可用性組中沒有見證服務器角色。

二、可用性模式

可用性模式是每個可用性副本的一個屬性；可用性模式確定主副本是否需要等待輔助副本將事務日誌寫入到磁盤。

1.異步提交模式

異步提交模式是一種災難恢復解決方案，適合於可用性副本的分布距離較遠的情況。 如果每個輔助副本都在異步提交模式下運行，則主副本不會等待任何輔助副本強制寫入日誌， 而會在將日誌記錄寫入本地日誌文件後，立即將事務確認發送到客戶端。 主副本使用與針對異步提交模式配置的輔助副本相關的最小事務滯後運行。

在“異步提交模式”下，輔助副本永遠不會與主副本同步。 雖然給定的輔助數據庫可能會趕上對應的主數據庫，但任何輔助數據庫在任何時點都可能會落後。 對於主副本和輔助副本相隔很遠而且您不希望小錯誤影響主副本的災難恢復方案的情況，或性能比同步數據保護更重要的情況，異步提交模式將會很有用。 而且，由於主副本不會等待來自輔助副本的確認，因而輔助副本上的問題從不會影響主副本。

異步提交輔助副本會嘗試與接收自主副本的日誌記錄保持一致。 但異步提交輔助數據庫往往會保持未同步狀態，並且可能稍微滯後於相應的主數據庫。通常，異步提交輔助數據庫和相應的主數據庫之間的這個時間差會很小。但是，如果承載輔助副本的服務器的工作負荷過高或網絡速度很慢，則這個時間差會變得較大。

異步提交模式所支持的唯一故障轉移形式為強制故障轉移（可能造成數據丟失）。 強制故障轉移是一種最後手段，僅可用於當前主要副本長時間保持不可用狀態並且主數據庫的即時可用性比可能丟失數據的風險更為重要的情況。故障轉移目標必須是其角色處於 SECONDARY 或 RESOLVING 狀態的副本。 故障轉移目標將轉換為主角色，並且其數據庫副本將成為主數據庫。 任何剩余的輔助數據庫以及變得可用後的以前的主數據庫都將被掛起，直到您手動單獨恢復它們。 在異步提交模式下，原始主副本尚未發送到以前的輔助副本的任何事務日誌都將丟失。 這意味著，某些或全部新的主數據庫可能會缺少最近提交的事務

2.同步提交模式

同步提交模式相對於性能而言更強調高可用性，為此付出的代價是事務滯後時間增加。 在同步提交模式下，事務將一直等到輔助副本已將日誌強制寫入到磁盤中才會向客戶端發送事務確認。

在同步提交可用性模式下，副本聯接到某個可用性組後，輔助數據庫就會與對應的主數據庫求得一致並進入 SYNCHRONIZED（已同步）狀態。 只要一直在進行數據同步，輔助數據庫就會保持 SYNCHRONIZED 狀態。 這可確保對主數據庫提交的每個事務也應用到對應的輔助數據庫。在同步輔助副本上的每個輔助數據庫之後，輔助副本的同步運行狀態總體上將為 HEALTHY。

註意：

1. 如果為當前主副本配置了異步提交可用性模式，那麽對所有的輔助副本都采集異步方式提交事務，不管這些副本各自的可用性模式，所以要保證同步提交模式那麽主副本和輔助副本都需要配置同步提交模式。

2.如果主副本與某一同步輔助會話超時，暫時將該輔助副本切換到異步提交模式。在該輔助副本重新與主副本連接後，它們將恢復同步提交模式。

三、故障轉移模式

可用性副本的主角色和輔助角色在稱為“故障轉移” 的過程中通常是可互換的。 存在三種故障轉移形式：自動故障轉移（無數據丟失）、計劃的手動故障轉移（無數據丟失）和強制手動故障轉移（可能丟失數據）。最後一種形式通常稱為“強制故障轉移”

1.自動故障轉移所需條件

僅在以下條件下才發生自動故障轉移：

• 存在自動故障轉移集。 此自動故障轉移集由主要副本和次要副本（自動故障轉移目標）構成，主要副本和次要副本都配置為同步提交模式並且設置為自動故障轉移。如果主要副本設置為手動故障轉移，即使次要副本設置為自動故障轉移，也無法發生自動故障轉移
• 自動故障轉移目標具有正常運行的同步狀態（這指示故障轉移目標上的每個輔助數據庫都與其相應的主數據庫同步）。
• Windows Server 故障轉移群集 (WSFC) 群集具有仲裁。
• 主副本已變得不可用，並且由靈活的故障轉移策略定義的故障轉移條件級別已得到滿足。

註意：

1.在數據庫級別，諸如因數據文件丟失而使數據庫成為可疑數據庫、刪除數據庫或事務日誌損壞之類的數據庫問題不會導致可用性組進行故障轉移

2. AlwaysOn 可用性組監視自動故障轉移集中兩個副本的運行狀況。 如果任一副本失敗，則該可用性組的運行狀況狀態將設置為“嚴重”。 如果輔助副本失敗，則自動故障轉移將不可行，因為自動故障轉移目標不可用。 如果主副本失敗，則可用性組將故障轉移到輔助副本。 在之前的主副本進入聯機狀態之前，將不存在任何自動故障轉移目標。 在任一情況下，為了在連續出現失敗這種近乎不可能發生的情況下確保可用性，我們建議您將其他輔助副本配置為自動故障轉移目標。

3.要設置故障轉移模式為“自動”的前提是可用性模式是“同步提交”。

4.如果主要副本設置為手動故障轉移，即使次要副本設置為自動故障轉移，也無法發生自動故障轉移。

5.只能設置一個自動故障轉移輔助副本

四、可讀輔助副本

1.輔助角色支持的連接訪問類型

1.無連接
不允許任何用戶連接。 輔助數據庫不可用於讀訪問。 這是輔助角色中的默認行為。

2.僅讀意向連接
輔助數據庫僅適用於其 Application Intent 連接屬性設置為 ReadOnly 的連接（讀意向連接）。

3.允許任何只讀連接
輔助數據庫全部可用於讀訪問連接。 此選項允許較低版本的客戶端進行連接。

2.主角色支持的連接訪問類型

1.允許所有連接
主數據庫同時允許讀寫連接和只讀連接。 這是主角色的默認行為。

2.僅允許讀/寫連接
當 Application Intent 連接屬性設置為 ReadWrite 或未設置時，允許此連接。 不允許其 Application Intent 連接字符串關鍵字設置為 ReadOnly的連接。 僅允許讀寫連接可幫助防止您的客戶錯誤地將讀意向工作負荷連接到主副本。

註意：所有的限制只針對配置了可用性數據庫，非可用性數據庫不受這些連接的限制，配置讀寫分離至少得保證有兩個可讀副本，如果只有一個可讀副本當可讀副本變成了主副本之後會導致只讀意向無副本可連接。

五、alwayson同步原理

1.任何一個SQL Server裏都有個叫Log Writer的線程，當任何一個SQL用戶提交一個數據修改事務時，它會負責把記錄本次修改的日誌信息先記入一段內存中的日誌緩沖區，然後再寫入物理日誌文件（日誌固化）,所以對於任何一個數據庫，日誌文件裏都會有所有數據變化的記錄。

2.對於配置為AlwaysOn主副本的數據庫，SQL Server會為它建立一個叫Log Scanner的工作線程,這個線程專門負責將日誌記錄從日誌緩沖區或者日誌文件裏中讀出，打包成日誌塊，發送給各個輔助副本。由於它的不間斷工作，才使主副本上的數據變化，可以不斷地向輔助副本上傳播。

3.在輔助副本上，同樣會有兩個線程，完成相應的數據更新動作，它們是固化（Harden）和重做（Redo）。固化線程會將主副本Log Scanner所發過來的日誌塊寫入輔助副本的磁盤上的日誌文件裏（這個過程被稱為"固化"）。

而重做線程，則負責從磁盤上讀取日誌塊，將日誌記錄翻譯成數據修改操作，在輔助副本的數據庫上完成。當重做線程完成其工作以後，輔助副本上的數據庫就會跟主副本一致了。AlwaysOn就是通過這種機制，保持副本之間的同步。重做線程每隔固定的時間點，會跟主副本通信，告知它自己的工作進度。主副本就能夠知道兩邊數據的差距有多遠。

這些線程在工作上各自獨立，以達到更高的效率。Log Scanner負責傳送日誌塊，而無須等待Log Writer完成日誌固化；輔助副本完成日誌固化以後就會發送消息到主副本，告知數據已經傳遞完畢，而無須等待重做完成。其設計目標，是盡可能地減少AlwaysOn所帶來的額外操作對正常數據庫操作的性能影響。

同步操作按下列方式維護：

1. 從客戶端收到事務後，主副本會將事務的日誌寫入事務日誌，同時將該日誌記錄發送到輔助副本。
2. 日誌記錄寫入主數據庫的事務日誌後，事務將不能撤消，除非在此時故障轉移到尚未收到該日誌的輔助副本。主副本將等待來自同步提交輔助副本的確認。
3. 輔助副本將強制寫入日誌（固化），並將確認消息返回給主副本。
4. 收到來自輔助副本的確認後，主副本將完成提交處理並向客戶端發送一條確認消息。

六、會話超時機制

由於軟錯誤不能由服務器實例直接檢測到，因此，軟錯誤可能導致一個可用性副本無限期等待會話中另一個可用性副本的響應。 為了防止發生這種情況， Always On 可用性組實施了會話超時機制，此機制基於以下條件：所連接的可用性副本會在每個打開的連接上按固定間隔發送 ping。 在超時期限內收到 ping 指示連接仍是開放的且服務器實例正在通過此連接進行通信。 收到 ping後副本將重置此連接上的超時計數器。主副本和輔助副本相互 ping 以指示它們仍處於活動狀態， 會話超時限制是用戶可配置的副本屬性，默認值為 10 秒。

如果在會話超時期限內沒有收到來自另一個副本的ping，該連接將超時、連接將關閉；超時的副本進入 DISCONNECTED 狀態。 即使為同步提交模式的副本，事務也將不等待該副本重新連接暫時將該輔助副本切換到異步提交模式。在該輔助副本重新與主副本連接後，它們將恢復同步提交模式。

總結

理解掌握這些概念對部署維護AlwaysOn集群非常的有幫助，可以結合測試對概念更深入的理解。

SQL Server Alwayson概念總結