[AlwaysOn] AlwaysOn可用性組的可用性模式之間的差異

AlwaysOn 可用性組的可用性模式之間的差異

 

本文內容

在AlwaysOn可用性組中，“可用性模式”是一個副本屬性，該屬性確定某一給定可用性副本是否可在同步提交模式下執行。對於每個可用性副本，必須為同步提交模式、非同步提交模式或僅配置模式配置可用性模式。如果 主要副本配置為“非同步提交模式”，則它 不會等待 任何次要副本將傳入的事務日誌記錄寫入磁碟(以便強制寫入日誌)。如果某一給定的 輔助副本配置為非同步提交模式，則 主副本不會等待該輔助副本強制寫入日誌。如果 主要副本和某一給定次要副本都配置為同步提交模式，則 主要副本將等待次要副本，以便確認它已強制寫入日誌(除非次要副本在主要副本的會話超時期限內未能使用ping命令聯絡上主要副本)。

備註

如果 某一輔助副本超過了主副本的會話超時期限，則主副本將暫時切換到該輔助副本的非同步提交模式。在該輔助副本重新與主副本連線後，它們將恢復同步提交模式。

一、受支援的可用性模式

AlwaysOn 可用性組支援三種可用性模式：非同步提交模式、同步提交模式和僅配置模式，如下所示：

·      非同步提交模式 是一種災難恢復解決方案，適合於可用性副本的分佈距離較遠的情況。如果每個輔助副本都在非同步提交模式下執行，則主副本不會等待任何輔助副本強制寫入日誌，而會在將日誌記錄寫入本地日誌檔案後，立即將事務確認傳送到客戶端。主副本使用與針對非同步提交模式配置的輔助副本相關的最小事務滯後執行。如果為當前主副本配置了非同步提交可用性模式，則它將透過非同步方式為所有輔助副本提交事務，而不管這些副本各自的可用性模式設定如何。

有關詳細資訊，請參閱本主題後面的 。

·      同步提交模式 相對於效能而言更強調高可用性，為此付出的代價是事務滯後時間增加。在同步提交模式下，事務將一直等到輔助副本已將日誌強制寫入到磁碟中才會向客戶端傳送事務確認。當在輔助資料庫上開始資料同步時，輔助副本將開始應用來自相應的主資料庫的傳入日誌記錄。一旦已經強制寫入每個日誌記錄，輔助資料庫就會進入SYNCHRONIZED狀態。此後，在日誌記錄寫入本地日誌檔案之前，輔助副本會先將每個新事務強制寫入。在同步給定輔助副本的所有輔助資料庫時，同步提交模式將支援手動故障轉移和自動故障轉移(可選)。

有關詳細資訊，請參閱本主題後面的 。

·      僅配置模式 適用於不位於Windows Server故障轉移群集的可用性組。僅配置模式中的副本不包含使用者資料。在僅配置模式下，主資料庫副本儲存可用性組配置後設資料。

有關詳細資訊，請參閱 。

下圖顯示具有五個可用性副本的可用性組。主副本和一個輔助副本配置為使用同步提交模式以及自動故障轉移。另一個次要副本配置為僅使用計劃手動故障轉移的同步提交模式，並且兩個次要副本配置為使用非同步提交模式，其僅支援強制手動故障轉移(一般稱為“強制故障轉移”)。

兩個可用性副本之間的同步和故障轉移行為取決於這兩個副本的可用性模式。例如，為進行同步提交，當前主副本和有關的輔助副本必須都配置為同步提交。同樣，為進行自動故障轉移，這兩個副本需要都配置為自動故障轉移。因此，下表總結了上圖闡釋的部署方案的行為，它透過每個可能的主副本說明了該行為：

當前主副本	自動故障轉移目標	具有以下節點的同步提交模式行為	具有以下節點的非同步提交模式行為	能否自動故障轉移
01	02	02 和   03	04	是
02	01	01 和   03	04	是
03		01 和   02	04	否
04			01 、02   和 03	否

通常，節點04作為非同步提交副本，部署在災難恢復站點中。在故障轉移到節點04後節點01、02和03保持在非同步提交模式，這一情況有助於避免因兩個站點之間網路延遲較長而導致您的可用性組中的效能下降。

二、非同步提交可用性模式

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

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

非同步提交模式所支援的唯一故障轉移形式為強制故障轉移(可能造成資料丟失)。強制故障轉移是一種最後手段，僅可用於當前主要副本長時間保持不可用狀態並且主資料庫的即時可用性比可能丟失資料的風險更為重要的情況。故障轉移目標必須是其角色處於SECONDARY或RESOLVING狀態的副本。故障轉移目標將轉換為主角色，並且其資料庫副本將成為主資料庫。任何剩餘的輔助資料庫以及變得可用後的以前的主資料庫都將被掛起，直到您手動單獨恢復它們。在非同步提交模式下，原始主副本尚未傳送到以前的輔助副本的任何事務日誌都將丟失。這意味著，某些或全部新的主資料庫可能會缺少最近提交的事務。有關強制故障轉移的工作原理及其最佳使用方法的詳細資訊，請參閱 。

三、同步提交可用性模式

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

3.1 、破壞資料同步的因素

一旦其所有資料庫均已同步，輔助副本即進入HEALTHY狀態。除非發生下列情況之一，否則，同步的輔助副本將會保持正常：

·      網路/計算機的延遲或故障導致 輔助副本與主副本之間的會話超時。

備註

有關可用性副本的會話時間屬性的資訊，請參閱 。

·      掛起了輔助副本上的輔助資料庫 。輔助副本停止同步，其同步執行狀態標記為NOT_HEALTHY。輔助副本將無法恢復正常，除非恢復並重新同步掛起的輔助資料庫或從可用性組中刪除它。

·      向可用性組新增了一個主資料庫 。以前同步的輔助副本進入NOT_HEALTHY同步執行狀態。這種狀態表示至少一個資料庫處於SYNCHRONIZING同步狀態。給定的輔助副本將無法恢復HEALTHY狀態，除非已在該輔助副本上準備了對應的輔助資料庫並將其聯接到可用性組，而且其與新的主資料庫已經同步。

·      將主副本或輔助副本的模式改為非同步提交可用性模式 。更改為非同步提交模式之後，只要還在進行資料同步，輔助副本就會一直保持HEALTHY同步執行狀態。但是，如果只有主副本更改為非同步提交模式，同步提交的輔助副本將進入PARTIALLY_HEALTHY同步執行狀態。這種狀態表示至少一個資料庫處於SYNCHRONIZING同步狀態，但沒有任何資料庫處於NOT SYNCHRONIZING狀態。

·      將任何輔助副本更改為同步提交可用性模式 。這將導致輔助副本被標記為處於PARTIALLY_HEALTHY同步執行狀態，直到其所有資料庫都處於SYNCHRONIZED同步狀態。

提示

若要檢視可用性組、可用性副本或可用性資料庫的同步執行狀況，請分別查詢 sys.dm_hadr_availability_group_states、 sys.dm_hadr_availability_replica_states或 的 或 列。

3.2 、輔助副本的同步工作原理

在同步提交模式下，在次要副本聯接可用性組並與主要副本建立會話之後，次要副本會將傳入日誌記錄寫入到磁碟(強制寫入日誌)並向主要副本傳送確認訊息。一旦輔助資料庫上已經強制寫入的日誌趕上主資料庫的日誌末尾，輔助資料庫的狀態就會設定為SYNCHRONIZED。同步所需的時間實質上取決於會話開始時輔助資料庫滯後於主資料庫的程度(按最初從主副本收到的日誌記錄數計量)、主資料庫的工作負荷和承載輔助副本的伺服器例項的計算機的速度。

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

1. 從客戶端收到事務後，主副本會將事務的日誌寫入事務日誌，同時將該日誌記錄傳送到輔助副本。

2. 日誌記錄寫入主資料庫的事務日誌後，事務將不能撤消，除非在此時故障轉移到尚未收到該日誌的輔助副本。主副本將等待來自同步提交輔助副本的確認。

3. 輔助副本將強制寫入日誌，並將確認訊息返回給主副本。

4. 收到來自輔助副本的確認後，主副本將完成提交處理並向客戶端傳送一條確認訊息。

備註

如果同步提交輔助副本未能確認其已強制寫入日誌即超時，則主副本會將該輔助副本標記為失敗。輔助副本的連線狀態更改為DISCONNECTED，主副本停止等待輔助副本的確認。此行為確保失敗的同步提交輔助副本不會阻止在主副本上強制寫入事務日誌。

同步提交模式透過要求在兩個位置之間同步資料來保護您的資料，但代價是使事務的滯後時間有所增加。

3.3 、僅使用手動故障轉移的同步提交模式

當這些副本連線在一起並且資料庫已同步時，將支援手動故障轉移。如果輔助副本關閉，則主副本將不受影響。如果不存在任何SYNCHRONIZED副本(即，不會將資料傳送到任何輔助副本)，則主副本將會暴露在風險之中。如果主副本丟失，輔助副本將進入RESOLVING狀態，但資料庫所有者可強制故障轉移到輔助副本(可能造成資料丟失)。有關詳細資訊，請參閱本主題後面的 。

3.4 、使用自動故障轉移的同步提交模式

透過確保在丟失主副本之後快速使資料庫再次變為可用，自動故障轉移可提供高可用性。 若要為可用性組配置自動故障轉移，你需要將當前的主要副本和至少一個次要副本設定為使用同步提交模式自動故障轉移。你最多可以有三個自動故障轉移副本。

此外，為了在特定時間自動執行故障轉移，此輔助副本必須與主副本同步(即，輔助資料庫全部同步)，並且Windows Server故障轉移群集(WSFC)群集必須具有仲裁。如果主副本在這些條件下變得不可用，則將發生自動故障轉移。輔助副本將切換為主副本角色，並提供其資料庫作為主資料庫。有關詳細資訊，請參閱 主題的“自動故障轉移”一節。

備註

有關WSFC仲裁模式和AlwaysOn可用性組 Always On availability groups的詳細資訊，請參閱 。

四、次要副本上的資料滯後

如果您的只讀工作負荷可以容忍一定程度的資料滯後，則實現對輔助副本的只讀訪問很有用。在資料滯後不可接受的情況下，請考慮對主副本執行只讀工作負荷。

主副本將主資料庫上的更改日誌記錄傳送到輔助副本。在每個輔助資料庫上，專用重做執行緒應用這些日誌記錄。在讀訪問許可權的輔助資料庫上，給定的資料更改不顯示在查詢結果中，直到包含更改的日誌記錄已應用到輔助資料庫並且已在主資料庫上提交事務。

這意味著在主副本和輔助副本之間將會存在一定程度的滯後時間，通常只需幾秒鐘。但是，在極少數情況下，例如在網路問題降低了網路吞吐量的情況下，滯後時間可能會較長。在存在I/O瓶頸和資料移動操作處於掛起狀態時，將增加滯後時間。若要監視掛起的資料移動，可以使用 或 動態管理檢視。

有關調查次要副本上的重做延遲的詳細資訊，請參閱 。

五、相關任務

5.1 、更改可用性模式和故障轉移模式

·     

·     

5.2 、調整仲裁投票

·     

·     

·     

5.3 、執行手動故障轉移

·     

·     

·     

5.4 、檢視可用性組、可用性副本和資料庫狀態

·     

·     

·     

六、相關內容

·     

·      SQL Server Always On 團隊部落格：SQL Server Always On 團隊官方部落格

七、另請參閱