共用方式為

什麼是 Always On 可用性群組？

適用於：SQL Server

此文章介紹在 SQL Server 的 Enterprise 版本中設定及管理一或多個可用性群組的 Always On 可用性群組中心概念。 若為標準版，請檢閱單一資料庫的基本 Always On 可用性群組。

Always On 可用性群組功能是一種高可用性與災害復原的解決方案，提供企業級的資料庫鏡像替代方案。 Always On 可用性群組可最大化企業一組使用者資料庫的可用性。 「可用性群組」 (Availability Group) 支援一組可一起容錯移轉之離散化使用者資料庫的容錯移轉環境，也就是所謂的 「可用性資料庫」(Availability Database)。 可用性群組支援一組讀寫的主要資料庫，以及一到八組對應的次要資料庫。 此外，您可以將次要資料庫用於唯讀存取及/或某些備份作業。

運用 Azure Arc 啟用的 SQL Server，您可以在 Azure 入口網站中檢視可用性群組。

概觀

「可用性群組」 支援一組離散使用者資料庫 (稱為「可用性資料庫」 ) 的複寫環境。 您可以建立可用性群組來實現高可用性 (HA) 或用於讀取擴充。 HA 高可用性群組是一組可一起進行容錯移轉的資料庫。 讀取級別可用性群組是針對唯讀工作負載複製至其他 SQL Server 執行個體的一組資料庫。 可用性群組支援一組主要資料庫，以及一到八組對應的次要資料庫。 次要資料庫並不是備份。 請持續定期備份您的資料庫及其交易記錄。

提示

您可為主要資料庫建立任何類型的備份。 或者，您亦可為次要資料庫建立記錄備份和僅限複製的完整備份。 如需詳細資訊，請參閱將支援的備份卸載至可用性群組次要複本。

每一組可用性資料庫都是由可用性複本裝載。 存在兩種可用性複本：一個主要複本，它託管主要資料庫，以及一至八個次要複本，每個次要複本託管一組次要資料庫，並作為可用性群組的潛在故障移轉目標。 可用性群組會在可用性複本層級容錯移轉。 可用性複本僅會針對某個可用性群組中一組資料庫提供資料庫層級的備援。 障礙轉移不是由資料庫問題引起的，例如資料檔案丟失或交易日誌損壞導致資料庫變得可疑的情況。

主要複本提供主要資料庫，以供用戶端讀寫連接使用。 主要複本會將每個主要資料庫的交易記錄檔記錄傳送到每個次要資料庫。 這個稱為「資料同步處理」 的程序是在資料庫層級發生。 每個次要複本都會快取交易記錄檔記錄 (「強行寫入」 記錄檔)，然後將它們套用到對應的次要資料庫。 資料同步處理在主要資料庫和每個連接的次要資料庫之間發生，與其他資料庫無關。 因此，次要資料庫可以暫停或失敗，而不影響其他次要資料庫，主要資料庫也可以暫停或失敗，而不影響其他主要資料庫。

或者，您可以設定一個或多個次要複本以支援對次要資料庫的唯讀存取，而且您可以設定任何次要複本以允許在次要資料庫上進行備份。

SQL Server 2017 引進兩個不同的可用性群組架構。 AlwaysOn 可用性群組提供高可用性、災害復原和讀取級別平衡。 這些可用性群組需要叢集管理員。 在 Windows 中，容錯叢集功能提供了叢集管理員。 在 Linux 中，您可以使用 Pacemaker。 另一個架構是「讀取級別可用性群組」 。 讀取級別可用性群組針對唯讀工作負載提供複本，但未針對高可用性。 在讀取擴縮可用性群組中，沒有叢集管理員，因為容錯移轉無法自動執行。

在 Windows 上為 HA 部署 Always On 可用性群組需要 Windows Server 容錯移轉叢集 (WSFC)。 給定可用性群組的每個可用性複本都必須位在相同 WSFC 的不同節點上。 唯一的例外狀況是在移轉至另一個 WSFC 叢集期間，可用性群組可以暫時跨兩個叢集。

注意

如需了解 Linux 上的可用性群組，請參閱適用於 Linux 的 SQL Server 可用性群組。

在 HA 組態中，對於您建立的每個可用性群組，系統都會建立一個叢集角色。 WSFC 叢集會監視此角色，以評估主要複本的健全狀況。 Always On 可用性群組的仲裁是以 WSFC 叢集中的所有節點為基礎，不論某個叢集節點是否承載任何可用性複本。 與資料庫鏡像相反，Always On 可用性群組中沒有見證角色。

注意

若需瞭解 SQL Server Always On 功能元件與 WSFC 叢集之間的關聯性，請參閱 SQL Server 的 Windows Server 容錯移轉叢集 (WSFC)。

下圖顯示可用性群組，其中包含一個主要複本和四個次要複本。 最多可支援八個次要複本，包括一個主要複本與四個同步認可次要複本。

具有五個複本的可用性群組的圖表

設定 TLS 1.3 加密

SQL Server 2025（17.x）引入了 Tabular Data Stream 8.0 支援，允許你強制執行 TLS 1.3 加密，以控制 Windows Server 故障轉移叢集與 Always On 可用性群組副本之間的通訊。 若要開始使用，請檢閱使用 嚴格加密的連線。

詞彙和定義

術語 描述
可用性群組 一組一起容錯移轉之資料庫 (「可用性資料庫」) 的容器。
可用性資料庫 屬於可用性群組的資料庫。 對於每個可用性資料庫而言，可用性群組會維護單一讀寫複本 (「主要資料庫」) 以及一到八個唯讀複本 (「次要資料庫」)。
主要資料庫 具備讀寫功能的可用性資料庫複本。
次要資料庫 可用性資料庫的唯讀複本。
可用性複本 可用性群組的具現化，其特定 SQL Server 執行個體裝載並維護屬於可用性群組之每個可用性資料庫的本機複本。 有兩種類型的可用性複本存在：單一 「主要複本」 以及一到八個 「次要複本」。
主要複本 可用性複本，該複本可讓主要資料庫用於用戶端的讀寫連接，同時也將每個主要資料庫的交易記錄檔記錄傳送到每個次要複本。
次要複本 可用性副本，該副本會維護每個可用性資料庫的次要副本，並作為可用性群組的潛在容錯移轉目標。 視需要，次要複本可以支援以唯讀方式存取次要資料庫，或者支援在次要資料庫上建立備份。
可用性群組接聽程式 用戶端可連接的伺服器名稱，以便存取可用性群組之主要或次要複本中的資料庫。 可用性群組接聽程式會將內送連接導向至主要複本或唯讀次要複本。

可用性資料庫

若要將資料庫加入可用性群組，該資料庫必須是存在於裝載主要複本之伺服器執行個體的線上讀寫資料庫。 當您加入資料庫時，該資料庫會加入可用性群組做為主要資料庫，同時仍然可以供用戶端使用。 在您將新主要資料庫的備份還原至裝載次要複本的伺服器執行個體 （使用 RESTORE WITH NORECOVERY） 之前，不會存在對應的次要資料庫。 新的次要資料庫在加入可用性群組之前，處於 RESTORING 狀態。 如需詳細資訊，請參閱在 Always On 次要資料庫上啟動資料移動 (SQL Server)。

加入時，會將次要資料庫置於 ONLINE 狀態，並起始對應主要資料庫的資料同步處理。 「資料同步處理」 (Data Synchronization) 是將主要資料庫的變更重現在次要資料庫上的程序。 資料同步處理涉及主要資料庫將交易記錄檔記錄傳送到次要資料庫。

重要

可用性資料庫有時候在 Transact-SQL、PowerShell 與 SQL Server 管理物件 (SMO) 名稱中會稱為「資料庫複本」。 例如，「資料庫複本」一詞已在 Always On 動態管理檢視的名稱中使用，這些檢視會傳回關於可用性資料庫的資訊：sys.dm_hadr_database_replica_states 和 sys.dm_hadr_database_replica_cluster_states。 但在《SQL Server 線上叢書》中，「複本」一詞通常是指可用性複本。 例如「主要複本」與「次要複本」一律指可用性複本。

可用性複本

每個可用性群組都會定義一組由兩個或更多容錯夥伴組成的可用性複本。 「可用性複本」 (Availability Replica) 是可用性群組的元件。 每個可用性複本都會在可用性群組中裝載一個可用性資料庫的副本。 針對指定的可用性群組，位於 WSFC 叢集不同節點上的個別 SQL Server 執行個體必須裝載可用性複本。 這些伺服器執行個體每一個都必須啟用 AlwaysOn。

SQL Server 2019 (15.x) 會將同步複本的數量上限，從 SQL Server 2017 (14.x) 中最多為 3 的狀態增加至 5。 您可以設定這五個複本的群組，使其在群組內具備自動容錯移轉。 有一個主要複本，再加上四個同步的次要複本。

給定的執行個體只能承載每一個可用性群組的一個可用性複本。 不過，您可以將每個執行個體用於多個可用性集群。 給定的執行個體可以是獨立執行個體或 SQL Server 容錯移轉叢集執行個體 (FCI)。 如果您需要伺服器層級的備援性，請使用容錯叢集。

每個可用性複本都會指派初始角色 - 主要角色 或 次要角色，該複本的可用性資料庫會繼承這些角色。 給定複本所擔任的角色決定其負責的是讀寫資料庫還是唯讀資料庫。 其中一個複本 (也就是所謂的「主要複本」 ) 會獲指派主要角色並裝載讀寫資料庫，也就是「主要資料庫」 。 至少有一個其他複本 (也就是所謂的 「次要複本」 ) 會獲指派次要角色。 次要複本會裝載唯讀資料庫，也就是次要資料庫。

注意

當可用性複本的角色不確定（例如在故障切換期間）時，其資料庫會暫時處於 NOT SYNCHRONIZING（未同步化）狀態。 其角色被設定為 RESOLVING，直到可用性複本的角色完成解析為止。 如果可用性複本解析為主要角色，其資料庫會變成主要資料庫。 如果可用性複本解析為次要角色，其資料庫會變成次要資料庫。

可用性模式

每個可用性複本都有可用性模式屬性。 可用性模式決定主副本是否等候交易的提交，直到指定的次副本把交易日志記錄寫入磁碟以使日志持久化。 Always On 可用性群組支援兩種可用性模式：「非同步認可模式」與「同步認可模式」。

  • 非同步認可模式

    使用此可用性模式的可用性複本稱為「非同步提交複本」。 在異步認可模式下，主要副本會提交交易，而不等候來自異步認可次要副本的確認以強化其交易記錄。 非同步提交模式會將次要資料庫的交易延遲降至最低，但允許它們相對於主要資料庫有所滯後，從而可能導致資料遺失。

  • 同步認可模式

    使用此可用性模式的可用性複本就是所謂的「同步認可複本」 。 在同步認可模式下，在認可交易之前，同步認可主要複本會等候同步認可次要複本，以確認它已完成強化記錄。 同步認可模式可確定，一旦給定次要資料庫與主要資料庫同步處理之後，認可的交易就會受到完整保護。 這種保護是以增加交易延遲做為代價。 (選擇性地) SQL Server 2017 引進「必要的同步次要複本」功能，以在需要時以延遲為代價來進一步提高安全性。 您可以啟用 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 功能，以要求指定數目的同步複本先認可交易，才能允許認可主要複本。

更多資訊，查閱 Always On 可用性群組之可用性模式間的差異。

容錯移轉的類型

在主要複本與次要複本之間的工作階段中，主要角色和次要角色可以在一個稱為 容錯移轉的程序中互換。 在故障轉移期間，目標之次要複本會轉變至主要角色，並成為新的主要複本。 新的主要複本將其資料庫上線並作為主要資料庫，客戶端應用程式可以連接到這些資料庫。 當前主複本可用時，它會轉換為次要角色並成為次要複本。 先前的主要資料庫就會變成次要資料庫，而且資料同步處理會繼續。

可用性群組會在可用性複本層級容錯移轉。 容錯移轉不會因資料庫問題而觸發，例如資料庫因資料檔案遺失、資料庫刪除或交易記錄損毀而進入可疑狀態。

存在三種形式的故障轉移：自動、手動和強制（可能會丟失數據）。 次要複本所支援的容錯移轉類型取決於其可用性模式。 針對同步提交模式，這還取決於主要副本和目標次要副本上的故障转移模式，具體如下。

  • 同步提交模式支援兩種形式的容錯移轉：計劃性手動容錯移轉 和 自動容錯移轉，如果目標次要複本目前與主要複本同步。 容錯移轉夥伴上的 容錯移轉模式屬性 設定會決定這些形式的容錯移轉的支援。 如果您在主要或次要複本上將容錯移轉模式設定為 手動 ，則次要複本僅支援手動容錯移轉。 如果您在主要和次要複本上將容錯移轉模式設定為 自動 ，則次要複本會同時支援自動和手動容錯移轉。

    • 已規劃的手動故障轉移 (無資料遺失)

    在資料庫管理員執行故障轉移指令後，會發生手動故障轉移。 它會導致同步處理的次要複本轉換成主要角色 （具有保證的資料保護），而主要複本會變更為次要角色。 手動故障切換要求主要複本和目標次要複本都在同步認可模式下運行，且次要複本必須已經完成同步。

    • 自動故障轉移（無資料遺失）

    自動容錯移轉會發生以回應失敗。 它會導致同步處理的次要複本轉換至主要角色 （並保證資料保護）。 當先前的主要複本變成可用時，它會變更為次要角色。 自動容錯移轉需要主要副本和目標次要副本都在同步認可模式下運行，並將容錯移轉模式設為自動。 此外，次要複本必須已經過同步處理、擁有 WSFC 仲裁，而且符合可用性群組之彈性容錯移轉原則所指定的條件。

  • 在非同步提交模式下，容錯移轉的唯一形式是強制手動容錯移轉（可能會有資料遺失），通常稱為「強制容錯移轉」。 強制容錯移轉是手動容錯移轉的一種形式，因為您必須手動啟動它。 強制故障切換是一個災難復原選項。 這是當目標次要複本未與主要複本同步處理時，唯一可能的容錯移轉形式。

如需進一步資訊，請參閱故障移轉及故障移轉模式 (Always On 高可用性群組)。

重要

  • SQL Server 容錯移轉叢集執行個體 （FCI） 不支援依可用性群組自動容錯移轉，因此您只能針對 FCI 裝載的任何可用性複本設定手動容錯移轉。
  • 如果您在已同步處理的次要複本上發出強制容錯移轉命令，次要複本的行為會與規劃的手動容錯移轉相同。

福利

Always On 可用性群組提供了一組豐富的選項，可改善資料庫可用性並改善資源的使用方式。 關鍵元件如下：

用戶端連接

您可以透過建立可用性群組接聽程式，為指定的可用性群組的主要複本提供用戶端連線能力。 「可用性群組接聽程式」 提供一組附加至給定可用性群組的資源，用於將用戶端連線導向至適當的可用性複本。

可用性群組接聽程式與當做虛擬網路名稱 (VNN)、一個或多個虛擬 IP 位址 (VIP)，以及 TCP 通訊埠編號的唯一 DNS 名稱相關聯。 如需詳細資訊，請參閱連線至 Always On 可用性群組接聽程式。

如果可用性群組只有兩個可用性複本，且未設定為允許次要複本的讀取存取，則用戶端可以使用 資料庫鏡像連接字串連線到主要複本。 在您將資料庫從資料庫鏡像移轉到 Always On 可用性群組之後，這個方法可能暫時很實用。 新增次要複本之前，您必須先建立可用性群組接聽程式，並更新應用程式以使用接聽程式的網路名稱。

注意

SQL Server 2025（17.x）引入了 TDS 8.0 支援，允許對 Always On 可用性群組副本和監聽器的連線強制執行嚴格的 TLS 1.3 加密。

配置要求：

  • 新增可用性群組：在條款Encrypt=Strict中建立 AGCLUSTER_CONNECTION_OPTIONS，並啟用故障轉移以套用設定。
  • 現有可用性群組：修改 AG 以設定 CLUSTER_CONNECTION_OPTIONS 和 Encrypt=Strict，然後故障轉移來套用設定。
  • 強制嚴格加密：在 SQL Server 組態管理員中，為每個副本設為「是」，並重新啟動 SQL Server 副本。
  • 證書要求：一旦 Encrypt=Strict 設定， TrustServerCertificate 將被忽略。

若要開始使用，請檢閱使用 嚴格加密的連線。

使用中次要複本

Always On 可用性群組支援可作業的次要複本。 目前啟用的次要功能支援包括：

  • 對次要複本執行備份作業

    次要複本支援執行日誌備份及完整資料庫、檔案或檔案群組的 僅複製 備份。 您可以設定可用性群組來指定應該執行備份之處的喜好設定。 請務必瞭解 SQL Server 不會強制執行喜好設定，因此不會影響臨機操作備份。 此偏好的解釋依賴於您在特定的可用性群組中為每個資料庫的備份作業所撰寫的邏輯（如果有的話）。 針對單一的可用性複本，您可以指定此複本的備份執行優先權，使其相對於同一個可用性群組中的其他複本更具優先。 如需詳細資訊，請參閱將支援的備份卸載至可用性群組次要複本。

  • 對一個或多個次要複本進行唯讀存取 (可讀取的次要複本)

    您可以將任何次要可用性複本設定為只允許對其本機資料庫進行唯讀存取，但不完全支援某些作業。 此組態可防止嘗試讀取/寫入連線至次要複本。 您也可以只允許讀寫存取以防止主要複本上的唯讀工作負載。 此組態可防止與主要複本建立唯讀連線。 如需詳細資訊，請參閱將唯讀工作負載卸載至 Always On 可用性群組的次要複本。

    如果可用性群組目前具有可用性群組聆聽器，並且包含一個或多個可讀取的次要複本，SQL Server 可以將讀取意圖連線要求路由傳送至其中一個複本（唯讀路由）。 如需詳細資訊，請參閱連線至 Always On 可用性群組接聽程式。

工作階段逾時期限

工作階段逾時時間是一個可用性複本的屬性，用於決定在連線關閉之前，與另一個可用性複本的連線可以保持非活動狀態的最長時間。 主要與次要複本會彼此發送訊號，以表示它們仍然處於運作狀態。 在逾時期限內從另一個複本接收到 Ping，表示連線仍為開啟狀態，且伺服器執行個體正在進行通訊。 接收到 Ping 時，可用性複本會重設它在該連接上的會話逾時計數器。

工作階段超時期限用於防止任一複本無限期地等待來自另一個複本的 Ping。 如果在會話逾時期間內未收到來自另一個複本的 Ping，則該複本會逾時。其連線將會關閉，逾時的複本進入 DISCONNECTED 狀態。 即使中斷連線的複本設定成同步認可模式，交易仍不會等候該複本重新連線及重新同步處理。

每個可用性複本的預設工作階段逾時期限為 10 秒。 您可以設定此值，至少為 5 秒。 一般而言，將逾時期間保持在 10 秒或更長。 將這個值設定為小於 10 秒，可能會使負荷重的系統宣告假性失敗。

注意

在解析角色中，工作階段逾時期限不適用，因為不會發生 Ping。

自動修復頁面

每個可用性複本都會嘗試解決阻止讀取資料頁面的特定類型錯誤，以便從本機資料庫上的損毀頁面自動復原。 如果次要複本無法讀取某個頁面，此複本會向主要複本要求一個全新頁面副本。 如果主要複本無法讀取某個頁面，主要複本會向所有次要複本廣播一份副本的請求，並從最先回應的次要複本取得該頁面。 如果這個要求成功，無法讀取的頁面就會使用副本取代，這通常會解決錯誤。

如需詳細資訊，請參閱自動修復頁面 (可用性群組：資料庫鏡像)。

與其他 Database Engine 功能的互通性和共存性

Always On 可用性群組可與下列 SQL Server 功能或元件搭配使用：

後續步驟

開始使用 Always On 可用性群組

  • Last updated on