適用於：
SQL Server
在 Always On 可用性群組中，「可用性模式」為複本屬性，可判斷給定可用性複本是否可以在同步認可模式下執行。 您必須將每個可用性複本的可用性模式設定為同步認可模式、非同步認可模式或僅限設定模式。
如果主要複本設定為 異步認可模式，就不會等待任何次要複本將傳入的事務日誌記錄寫入磁碟（以 加密日誌）。
如果指定的次要複本設定為異步認可模式，主要複本不會等候該次要複本強化記錄。 如果主要複本與指定的次要複本都配置為「同步認可模式」，則主要複本會等待次要複本確認已硬化日志，除非次要複本在主要複本的「工作階段逾時期間」未能 Ping 主要複本。
注意
如果同步認可次要複本超過主要複本的工作階段逾時期間（預設值為 10 秒），則主要複本會暫時將此次要複本上的每個資料庫同步處理狀態標示為 NOT SYNCHRONIZING ，並將複本狀態標示為 NOT_HEALTHY。 當次要複本與主要複本重新連接時，會恢復為同步提交模式。
支援的可用性模式
AlwaysOn 可用性群組支援三種可用性模式：
- 異步提交模式
- 同步提交模式
- 僅限設定模式
「非同步認可模式」 是一種當可用性複本分散距離相當遠時仍可正常運作的災害復原解決方案。 如果每個次要複本都以異步認可模式執行，則主要復本不會等候任何次要復本強化記錄。 而是，將記錄檔記錄寫入本機記錄檔之後，主要複本會立即將交易確認傳送至用戶端。 主要複本相對於設定為非同步提交模式的次要複本，以最低的交易延遲運行。
如果目前的主複本設定為異步提交可用性模式，則不論次要複本各自的可用性模式設定為何，主複本都會以異步方式提交所有次要複本的交易。
如需詳細資訊，請參閱本文稍後 Asynchronous-Commit 可用性模式。
「同步提交模式」強調的是系統高可用性而非運行效能，這樣會導致交易延遲的增加。 在同步認可模式下，交易會等候將交易確認傳送至用戶端，直到次要複本將日誌堅決寫入磁碟為止。 當資料同步處理開始在次要資料庫上執行時，次要複本就會開始套用對應主要資料庫中的內送記錄檔記錄。 一旦強化每個記錄檔記錄，輔助資料庫就會進入 SYNCHRONIZED 狀態。 此後，每筆新交易在記錄檔記錄寫入本機日誌檔案之前，會由次要副本進行強化處理。 當給定次要複本的所有次要資料庫都已同步處理時，同步認可模式就會支援手動容錯移轉，並且選擇性地支援自動容錯移轉。
如需詳細資訊，請參閱本文稍後 Synchronous-Commit 可用性模式。
僅限設定模式 適用於不在 Windows Server 故障轉移叢集上的可用性群組。 僅限設定模式中的複本不包含用戶數據。 在僅限設定模式中，複本 master 資料庫會儲存可用性群組組態元數據。 如需詳細資訊，請參閱可用性群組組態的高可用性和資料保護。
下列插圖顯示包含五個可用性複本的可用性群組。 主要複本和一個副本被配置為同步提交模式，並具有自動容錯移轉功能。 另一個次要複本則設定為僅包含規劃的手動容錯移轉的同步認可模式，而且兩個次要複本設定為非同步認可模式 (僅支援強制手動容錯移轉，一般稱為「強制容錯移轉」 )。
兩個可用性復本之間的同步處理和故障轉移行為取決於兩個複本的可用性模式。 例如，若要進行同步認可，主要復本和次要複本都必須設定為同步認可。 同樣地，為了實現自動故障轉移，兩個副本都需要設定為自動故障轉移。 因此，下表摘要說明先前說明之部署案例的行為，其會探索每個潛在主要複本的行為：
| 目前的主要副本 | 自動故障轉移目標 | 使用同步提交模式的行為 | 異步認可模式的行為特性 | 自動故障轉移可行 |
|---|---|---|---|---|
| 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 狀態。 故障轉移目標必須是其角色處於SECONDARY 或RESOLVING狀態的複本。 故障轉移目標會轉變為主要角色，其資料庫副本則成為主要資料庫。 當剩餘的次要資料庫與先前的主要資料庫恢復其可用性時，系統會暫停這些資料庫，直到您手動一一回復為止。 在異步認可模式下，原始主要複本未傳送至先前次要複本的任何交易日誌都會遺失。 這表示有部分或全部新主要資料庫可能缺乏最近認可的交易。 如需瞭解強制容錯移轉的運作方式及最佳實踐，請參閱容錯移轉及容錯移轉模式 (Always On 可用性群組)的詳細資訊。
同步提交可用性模式
在同步認可可用性模式（同步認可模式）下，聯結至可用性群組之後，輔助資料庫會趕上對應的主資料庫並進入 SYNCHRONIZED 狀態。 只要數據同步處理繼續，輔助資料庫就會 SYNCHRONIZED 維持不變。 這可確保指定主資料庫上認可的每個交易都會在對應的輔助資料庫上認可。 當給定的次要副本上的每個次要資料庫已同步時，整個次要副本的同步健康狀態為 HEALTHY。
在本節中：
中斷數據同步處理的因素
一旦其所有資料庫同步後，次要復本就會進入 HEALTHY 模式。 除非發生下列其中一項，否則同步處理的次要複本會保持狀況良好：
網路延遲或電腦故障導致次要複本和主要複本之間的會話逾時。
注意
如需可用性複本會話時間屬性的相關資訊，請參閱什麼是 Always On 可用性群組？
您暫停了次要副本上的次要資料庫。 次要複本停止同步，其同步處理的健全狀態被標記為 NOT_HEALTHY。 除非暫停的輔助資料庫已繼續運作並重新同步，否則從可用性群組中移除之前，次要複本無法再次恢復至健康狀態。
您將主要資料庫加入至可用性群組。 先前同步的次要複本會進入
NOT_HEALTHY同步健康狀態。 此狀態表示至少有一個資料庫處於NOT SYNCHRONIZING同步處理狀態。 指定的次要複本必須HEALTHY等到復本上備妥對應的輔助資料庫、已聯結至可用性群組，且已與新的主資料庫同步處理之後，才能再次出現。您將主要複本或次要複本變更為非同步提交的可用性模式。 更改為非同步提交模式後，只要數據同步持續進行，次要副本就會維持在
HEALTHY同步健康狀態中。 不過，如果只有主復本變更為非同步-提交模式，同步-提交次要復本將會進入PARTIALLY_HEALTHY同步健康狀態。 此狀態表示至少有一個資料庫處於SYNCHRONIZING同步處理狀態，但沒有任何資料庫處於NOT SYNCHRONIZING狀態。您將任何次要複本變更為同步提交的可用性組態。 這會導致次要複本被標示為
PARTIALLY_HEALTHY同步健康狀態，直到其所有資料庫都處於SYNCHRONIZED同步狀態。
提示
若要檢視可用性群組、可用性複本或可用性資料庫的同步處理健康情況，請分別查詢 synchronization_health、synchronization_health_desc 或 sys.dm_hadr_database_replica_states的 或 列。
同步處理在次要複本上的運作方式
在同步提交模式中，次要副本聯結可用性群組之後，並與主要副本建立連線：
- 次要復本會將連入記錄檔記錄寫入磁碟（強化記錄檔）。
- 次要複本會將確認訊息傳送至主要複本。
在輔助資料庫上強化的記錄檔趕到主資料庫的記錄結尾之後，輔助資料庫的狀態會設定為 SYNCHRONIZED。
同步處理所需的時間取決於輔助資料庫在會話開始時落後主資料庫的時間。 此差異是透過最初從主要副本接收的日誌記錄數量、主資料庫的工作負載，以及次要復本實例主機的速度來測量。
交易程式
在同步提交模式中，交易會依此順序提交到這兩個複本：
主要複本會從用戶端接收交易。
主要複本會將記錄寫入事務日志，並同時將日志記錄傳送至次要複本。
將記錄檔記錄寫入主資料庫的事務歷史記錄之後，只有在故障轉移至未接收記錄的輔助資料庫時，才能復原交易。
主要複本會等候同步提交次要複本的確認。
次要複本會將日誌固化，並將確認傳送回主要複本。
主要副本完成提交程序後，向用戶端發送確認訊息。
同步提交逾時
如果同步提交的次要複本逾時，且未確認其已硬化記錄檔，則可用性群組中會發生下列動作：
- 主要複本會將次要複本標記為失敗的複本。
- 次要復本狀態會變更為
DISCONNECTED。 - 主要停靠站等候確認。
- 可用性群組會將同步處理狀態標示為
NOT SYNCHRONIZING，並將複本狀態標示為NOT_HEALTHY。
此行為可確保失敗的同步提交次要複本不會阻止主要複本上的日誌加固。
當次要複本重新上線時：
- 次要復本狀態會變更為
CONNECTED。 - 次要複本會處理主要複本的日誌傳送佇列。
- 同步狀態轉變為
SYNCHRONIZING，並且副本健康狀況轉變為PARTIALLY_HEALTHY。
處理記錄傳送佇列之後，同步處理狀態會 SYNCHRONIZED變成 ，複本健全狀況會 HEALTHY變成 。
同步提交模式會藉由要求在兩個位置之間同步數據來保護資料，但會稍微增加交易的延遲。
只有手動故障轉移的同步提交模式
當這些複本都已連接而且資料庫已同步處理時，就會支援手動容錯移轉。 如果次要副本發生故障，主要副本將不受影響。 如果沒有任何 SYNCHRONIZED 複本存在，則主要複本會運行在無保護的狀態（也就是說，不將數據傳送至任何次要複本）。 如果主要複本遺失，次要複本會進入 RESOLVING 狀態，但資料庫擁有者可以強制故障轉移至次要複本（可能遺失數據）。 如需詳細資訊，請參閱故障移轉及故障移轉模式 (Always On 高可用性群組)。
具有自動故障轉移的同步提交模式
自動故障轉移透過確保在主要複本遺失後能迅速使資料庫重新可用，來提供高可用性。 若要將可用性群組設定為自動容錯移轉，您必須將目前的主要複本和至少一個次要複本都設定為包含自動容錯移轉的同步認可模式。 SQL Server 2019 (15.x) 會將同步複本的數量上限，從 SQL Server 2017 (14.x) 中最多為 3 的狀態增加至 5。 您可以設定這五個複本的群組，使其在群組內具備自動容錯移轉。 有一個主要複本，再加上四個同步的次要複本。
此外，為了能夠在特定時間點進行自動移轉，這個次要複本必須與主要複本同步處理（亦即，次要資料庫都會同步處理），而且 Windows Server 容錯移轉叢集（WSFC）叢集必須達成仲裁。 如果主要複本在這些條件下變得無法使用，就會進行自動容錯移轉。 次要副本會切換成主要角色，並將其資料庫作為主要資料庫提供。 如需詳細資訊，請參閱 故障移轉和移轉模式（Always On 可用性群組） 文章中的「自動故障移轉」一節。
注意
若要了解有關 WSFC 仲裁和 Always On 可用性群組的資訊，請參閱 WSFC 仲裁模式和投票組態 (SQL Server)。
次要複本上的資料延遲
如果您的唯讀工作負載可以容忍某些資料延遲時，實作次要複本的唯讀存取會很有用。 在無法接受資料延遲的狀況下，請考慮針對主要複本執行唯讀工作負載。
主要副本會將主要資料庫變更的記錄傳送到次要副本。 在每個次要資料庫上，專用的重做執行緒會套用日誌記錄。 在讀取存取輔助資料庫上，指定的數據變更不會出現在查詢結果中，直到包含變更的記錄檔記錄已套用至輔助資料庫，而且主資料庫上已認可交易為止。
這表示主要和次要複本之間通常會有一些延遲，通常只有幾秒鐘的時間。 但在很少見的情況下 (例如網路問題減少輸送量的狀況下)，延遲可能會比較長。 在發生 I/O 瓶頸和資料移動暫停時，會增加延遲。 若要監視暫停的資料移動，您可以使用 Always On 可用性群組儀表板（SQL Server Management Studio） 或 sys.dm_hadr_database_replica_states 動態管理檢視表。
為了降低 SQL Server 2025（17.x）及更新版本的延遲，你可以縮短主副本向次要副本提交交易所需的時間（以毫秒為單位）。 如需詳細資訊，請參閱 伺服器組態：可用性群組認可時間（ms）。
若要更改可用性模式及故障轉移模式
若要調整法定人數票數
執行手動故障切換
- 執行 SQL Server 的 Always On 可用性群組之手動已規劃故障轉移
- 執行 Always On 可用性群組的強制手動故障移轉 (SQL Server)
- 使用容錯移轉可用性群組精靈 (SQL Server Management Studio)
若要檢視可用性群組、可用性複本和資料庫狀態
- sys.dm_hadr_availability_group_states
- sys.dm_hadr_availability_replica_states
- sys.dm_hadr_database_replica_states