SQL Server Alwayson概念總結

1、alwayson概念

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

每組可用性數據庫都由一個「可用性副本」 承載。 有兩種類型的可用性副本：一個「主副本」 和一到四個「輔助副本」。 它承載主數據庫和一至八個「輔助副本」 ，其中每一個副本承載一組輔助數據庫，並用做可用性組的潛在故障轉移目標。 可用性組在可用性副本級別進行故障轉移。 可用性副本僅在數據庫級別提供冗餘 － 針對一個可用性組中的該組數據庫。 故障轉移不是由諸如因數據文件丟失或事務日誌損壞而使數據庫成爲可疑數據庫等數據庫問題致使的。

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

或者，您能夠配置一個或多個輔助副本以支持對輔助數據庫進行只讀訪問，而且能夠將任何輔助副本配置爲容許對輔助數據庫進行備份。

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

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

2、可用性模式

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

1.異步提交模式

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

在「異步提交模式」下，輔助副本永遠不會與主副本同步。 雖然給定的輔助數據庫可能會遇上對應的主數據庫，但任何輔助數據庫在任什麼時候點均可能會落後。 對於主副本和輔助副本相隔很遠並且您不但願小錯誤影響主副本的災難恢復方案的狀況，或性能比同步數據保護更重要的狀況，異步提交模式將會頗有用。 並且，因爲主副本不會等待來自輔助副本的確認，於是輔助副本上的問題從不會影響主副本。

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

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

2.同步提交模式

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

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

注意：

1. 若是爲當前主副本配置了異步提交可用性模式，那麼對全部的輔助副本都採集異步方式提交事務，無論這些副本各自的可用性模式，因此要保證同步提交模式那麼主副本和輔助副本都須要配置同步提交模式。

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

3、故障轉移模式

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

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

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

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

注意：

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

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

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

4.若是主要副本設置爲手動故障轉移，即便次要副本設置爲自動故障轉移，也沒法發生自動故障轉移。

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

4、可讀輔助副本

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

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

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

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

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

1.容許全部鏈接
主數據庫同時容許讀寫鏈接和只讀鏈接。 這是主角色的默認行爲。

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

注意：全部的限制只針對配置了可用性數據庫，非可用性數據庫不受這些鏈接的限制，配置讀寫分離至少得保證有兩個可讀副本，若是隻有一個可讀副本當可讀副本變成了主副本以後會致使只讀意向無副本可鏈接。

5、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. 收到來自輔助副本的確認後，主副本將完成提交處理並向客戶端發送一條確認消息。

6、會話超時機制

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

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

總結

理解掌握這些概念對部署維護AlwaysOn集羣很是的有幫助，能夠結合測試對概念更深刻的理解。

 

注意： 域服務器宕機了也不影響使用SQLServer身份驗證鏈接副本或者監聽器，Windows身份驗證會受影響。因此只要不故障切換AD宕機了也不影響AlwaysOn羣集的鏈接。這個功能減小了AlwaysON對AD的依賴，同時也減小建雙域控的成本。

 

針對AlwaysON可用性組的先決條件和限制：https://msdn.microsoft.com/zh-cn/library/ff878487(v=sql.120).aspx

搭建和加入域參考：http://www.cnblogs.com/chenmh/p/4444168.html

搭建故障轉移羣集參考：http://www.cnblogs.com/chenmh/p/4479304.html

Alwayson搭建參考：http://www.cnblogs.com/chenmh/p/4484176.html

Alwayson配置兩個節點加共享文件夾仲裁見證：http://www.cnblogs.com/chenmh/p/7156719.html

Alwayson讀寫分離參考：http://www.cnblogs.com/chenmh/p/7000236.html

 

備註：     做者：pursuer.chen     博客：http://www.cnblogs.com/chenmh 本站點全部隨筆都是原創，歡迎你們轉載；但轉載時必須註明文章來源，且在文章開頭明顯處給明連接，不然保留追究責任的權利。 《歡迎交流討論》