SQL Server Alwayson概念總結

標籤：測試   size   原理   資料   readwrite   http   資料保護   有用   ack   

一、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.僅讀意向串連
次要資料庫僅適用於其 ApplicationIntent 串連屬性設定為 ReadOnly 的串連（讀意向串連）。

3.允許任何唯讀串連
次要資料庫全部可用於讀訪問串連。 此選項允許較低版本的用戶端進行串連。

2.主角色支援的串連訪問類型

1.允許所有串連
主要資料庫同時允許讀寫串連和唯讀串連。 這是主角色的預設行為。

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

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

五、alwayson同步原理

1.任何一個SQL Server裡都有個叫Log Writer的線程，當任何一個SQL使用者提交一個資料修改事務時，它會負責把記錄本次修改的日誌資訊先記入一段記憶體中的日誌緩衝區，然後再寫入物理記錄檔（日誌固化）,所以對於任何一個資料庫，記錄檔裡都會有所有資料變化的記錄。

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

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

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

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

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

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

六、會話逾時機制

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

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

總結

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

 

 

 

 

備忘：     pursuer.chen     部落格：http://www.cnblogs.com/chenmh 本網站所有隨筆都是原創，歡迎大家轉載；但轉載時必須註明文章來源，且在文章開頭明顯處給明連結，否則保留追究責任的權利。 《歡迎交流討論》

 

SQL Server Alwayson概念總結