自動容錯移轉群組概觀和最佳做法 (Azure SQL Database)

適用于:Azure SQL資料庫

自動容錯移轉群組功能可讓您管理邏輯伺服器上的某個資料庫或所有資料庫,以複寫和容錯移轉至另一個區域。 本文著重在搭配 Azure SQL Database 和一些最佳做法使用自動容錯移轉群組功能。

若要開始使用,請詳閱設定自動容錯移轉群組。 關於端對端體驗,請參閱自動容錯移轉群組教學課程 (英文)。

注意

  • 本文涵蓋 Azure SQL Database 的自動容錯移轉群組。 關於 Azure SQL 受控執行個體,請參閱 Azure SQL 受控執行個體中的自動容錯移轉群組 (英文)。
  • 自動容錯移轉群組支援將群組中的所有資料庫都只異地複寫到不同區域的一部次要伺服器中。 如果您需要針對相同的主要複本建立多個 Azure SQL Database 異地複寫次要複本 (在相同或不同區域中),請使用作用中異地複寫

概觀

透過自動容錯移轉群組功能,您可以管理伺服器上某個資料庫群組或是受控執行個體內的所有使用者資料庫,以複寫和容錯移轉至另一個 Azure 區域。 其為作用中異地複寫功能上的宣告式抽象概念,旨在簡化異地複寫資料庫的大規模部署和管理。

Automatic failover

您可以手動起始異地複寫容錯移轉,或根據使用者定義的原則將其委派給 Azure 服務。 後者可讓您在導致主要區域中完全或部分喪失 SQL Database 或 SQL 受控執行個體可用性的嚴重失敗或其他非計劃事件之後,自動復原次要地區中的多個相關資料庫。 一般來說,內建的高可用性基礎結構無法自動緩解這些中斷。 異地容錯移轉的觸發範例包括自然災害,或是租用戶所造成的事件,抑或因計算節點上的作業系統核心記憶體流失而關閉控制通道的事件。 如需詳細資訊,請參閱 Azure SQL 高可用性 (英文)。

卸載唯讀工作負載

若要減少到主要資料庫的流量,您也可以使用容錯移轉群組中的次要資料庫,以卸載唯讀工作負載。 請使用唯讀接聽程式將唯讀流量導向可讀取的次要資料庫。

端點重新導向

自動容錯移轉群組還提供在異地容錯移轉期間仍保持不變的讀寫和唯讀接聽程式端點。 這表示您不需要在異地容錯移轉之後變更應用程式的連接字串,因為連線會自動路由至目前的主要資料庫。 無論您使用手動或自動啟動容錯移轉,異地複寫容錯移轉都會將群組中所有次要資料庫切換到主要角色。 異地複寫容錯移轉完成後,DNS 記錄會自動更新以將端點重新導向至新的區域。 如需異地複寫容錯移轉的 RPO 和 RTO,請參閱商務持續性概觀

復原應用程式

若要實現完整的商務持續性,新增區域資料庫備援只是解決方案的一部分。 在災難性失敗後要端對端復原應用程式 (服務) 需要復原構成服務的所有元件和任何相依的服務。 這些元件的範例包括用戶端軟體 (例如自訂 JavaScript 的瀏覽器)、web 前端、儲存體和 DNS。 所有元件都必須對相同的失敗具有恢復功能,並且在應用程式的復原時間目標 (RTO) 內可供使用。 因此,您需要識別所有相依服務並了解其提供的保證與功能。 然後,您必須採取適當步驟以確保服務功能在它所依賴的服務容錯移轉期間都正常。

術語和功能

  • 容錯移轉群組 (FOG)

    容錯移轉群組是由單一伺服器所管理的一組指定資料庫,如果由於主要區域中斷而導致所有或某些主要資料庫無法使用,則可以將這些資料庫作為容錯移轉到另一個區域的一個單位。

    重要

    容錯移轉群組的名稱在 .database.windows.net 網域內必須是全域唯一的。

  • 伺服器

    可以將邏輯伺服器上的部分或所有使用者資料庫放在容錯移轉群組中。 此外,伺服器在單一伺服器上會支援多個容錯移轉群組。

  • 主要

    容錯移轉群組中裝載主要資料庫的伺服器。

  • 次要

    容錯移轉群組中裝載次要資料庫的伺服器。 次要資料庫和主要資料庫不能位於相同的 Azure 區域。

  • 將單一資料庫新增至容錯移轉群組

    您可以將多個在相同伺服器上的單一資料庫放入相同的容錯移轉群組。 如果您在容錯移轉群組中新增單一資料庫,它會使用相同的版本自動建立次要資料庫,並在次要伺服器上計算大小。 當建立容錯移轉群組時,您會指定該伺服器。 如果您新增在次要伺服器中已經有次要資料庫的資料庫,群組就會繼承該異地複寫連結。 當您新增在伺服器中已經有次要資料庫但不屬於容錯移轉群組一部分的資料庫時,會在次要伺服器中建立新的次要資料庫。

    重要

    確定次要伺服器沒有具有相同名稱的資料庫,除非其是現有的次要資料庫。

  • 將彈性集區中的資料庫新增到容錯移轉群組

    您可以將彈性集區中的所有或多個資料庫放入相同的容錯移轉群組。 如果主要資料庫在彈性集區中,則會使用相同名稱在該彈性集區中建立次要資料庫 (次要集區)。 您必須確保次要伺服器包含名稱完全相同的彈性集區,且有足夠的可用容量裝載容錯移轉群組將建立的次要資料庫。 如果您在集區中新增在次要集區中已經有次要資料庫的資料庫,群組就會繼承該異地複寫連結。 當您新增的資料庫在伺服器中已經有次要資料庫且不屬於容錯移轉群組一部分時,系統會在次要集區中建立新的次要資料庫。

  • 容錯移轉群組讀寫接聽程式

    指向目前的主要資料庫的 DNS CNAME 記錄。 系統會在建立容錯移轉群組時自動建立,並允許讀寫工作負載在容錯移轉之後變更時,以透明的方式重新連線至主要資料庫。 在伺服器上建立容錯移轉群組時,接聽程式 URL 的 DNS CNAME 記錄格式會是 <fog-name>.database.windows.net

  • 容錯移轉群組唯讀接聽程式

    指向目前的次要資料庫的 DNS CNAME 記錄。 其是在容錯移轉群組建立時自動建立,並允許唯讀 SQL 工作負載在容錯移轉之後次要資料庫變更時,以透明的方式連線到次要資料庫。 在伺服器上建立容錯移轉群組時,接聽程式 URL 的 DNS CNAME 記錄格式會是 <fog-name>.secondary.database.windows.net

  • 多個容錯移轉群組

    您可以為相同的兩部伺服器設定多個容錯移轉群組來控制異地複寫容錯移轉的範圍。 每個群組分別進行容錯移轉。 如果您租用戶的每個資料庫應用程式部署在多個區域,並使用彈性集區,則您可以使用此功能來混合每個集區中的主要和次要資料庫。 以此方式,您就可以將中斷的影響減少為僅限某些租用戶資料庫。

  • 自動容錯移轉原則

    容錯移轉群組預設是利用自動容錯移轉原則設定。 系統在偵測到失敗且寬限期已過期之後,會觸發異地複寫容錯移轉。 系統必須驗證中斷情況無法藉由內建的高可用性基礎結構來緩解,例如,由於影響的規模。 如果您想要從應用程式或手動控制異地複寫容錯移轉工作流程,可以關閉自動容錯移轉原則。

    注意

    因為中斷規模的驗證,以及緩解風險的速度會牽涉到人為的動作,因此寬限期不能設定為低於一小時。 此限制適用於容錯移轉群組中的所有資料庫,無論其資料同步狀態為何。

  • 唯讀的容錯移轉原則

    根據預設,唯讀接聽程式的容錯移轉已停用。 它可確保在次要伺服器離線時不會影響主要伺服器的性能。 不過,這也表示在次要伺服器恢復之前,唯讀的工作階段將無法連線。 如果您無法容忍唯讀工作階段的停機時間,並且可以將主要伺服器用於唯讀和讀寫流量,但代價是主要伺服器潛在的效能降低,則可以透過設定 AllowReadOnlyFailoverToPrimary 屬性來為唯讀接聽程式啟用容錯移轉。 在該情況下,如果次要伺服器無法使用時,唯讀流量將自動重新導向到主要伺服器。

    注意

    只有在已啟用自動容錯移轉原則,且已觸發自動異地複寫容錯移轉時,AllowReadOnlyFailoverToPrimary 屬性才有作用。 在該情況下,如果屬性設定為 True,新的主要資料庫將同時為讀寫和唯讀工作階段提供服務。

  • 計劃性容錯移轉

    計劃性容錯移轉會在主要資料庫和次要資料庫之間執行完整資料同步處理,然後將次要資料庫切換為主要角色。 這可確保不會遺失資料。 計劃性容錯移轉會用於下列案例:

    • 在資料遺失不可接受時,在生產環境中執行災害復原 (DR) 演練
    • 將資料庫重新放置到不同的區域
    • 在中斷情況趨緩 (容錯回復) 後,將資料庫傳回到主要區域

    注意

    如果資料庫包含記憶體內部 OLTP 物件,則主資料庫和目標次要異地複本資料庫應該具有相符的服務層級,因為記憶體內部 OLTP 物件一律會在記憶體中凍結。 目標異地複本資料庫的較低服務層級可能會導致記憶體不足問題。 如果發生這種情況,受影響的異地次要資料庫複本可能會進入稱為僅限 記憶體中 OLTP 檢查點模式 的有限唯讀模式。 允許唯讀資料表查詢,但受影響的異地次要資料庫複本不允許唯讀記憶體內部 OLTP 資料表查詢。 如果異地次要資料庫中的所有複本都處於僅檢查點模式,則會封鎖計劃性容錯移轉。 非計劃性容錯移轉可能會因為記憶體不足問題而失敗。 若要避免這種情況,請升級次要資料庫的服務層級,以符合計劃性容錯移轉期間的主資料庫,或鑽研。 服務層級升級可以是資料大小作業,而且可能需要一段時間才能完成。

  • 未規劃的容錯移轉

    非計劃性或強制容錯移轉會立即將次要資料庫切換為主要角色,而不會等待從主要資料庫傳播最近的變更。 此作業可能會導致資料遺失。 非計劃性容錯移轉是主要資料庫無法存取時,用來作為中斷期間的復原方法。 中斷緩解時,舊的主要資料庫會自動重新連接,並成為新的次要資料庫。 您可以執行計劃性容錯移轉來進行容錯回復,並讓複本回到至其原始的主要和次要角色。

  • 手動容錯移轉

    無論自動容錯移轉設定為何,您都可以在任何時候手動起始異地複寫容錯移轉。 在影響主要資料庫的中斷期間,如果未設定自動容錯移轉原則,就需要手動容錯移轉,才能將次要資料庫升階為主要角色。 您可以起始強制 (未規劃的) 或友善的 (規劃的) 容錯移轉。 只有在舊的主要資料庫可供存取時,易用的容錯移轉才可供使用,而且可以用來將主要資料庫重新放置到次要區域,而不會遺失資料。 容錯移轉完成時,DNS 記錄會自動更新以確保能連線到新的主要伺服器。

  • 資料遺失的寬限期

    因為資料是非同步複寫至次要資料庫,自動異地複寫容錯移轉可能會導致資料遺失。 您可以自訂自動容錯移轉原則,以反映應用程式對資料遺失的容錯程度。 藉由設定 GracePeriodWithDataLossHours,您可以控制系統在起始強制容錯移轉之前的等候時間,這可能會導致資料遺失。

容錯移轉群組結構

Azure SQL Database 中的容錯移轉群組可包含一或多個資料庫,通常是由相同的應用程式所使用。 使用自動容錯移轉群組搭配自動容錯移轉原則時,影響群組中一或多個資料庫的任何中斷,都會導致自動異地複寫容錯移轉。

自動容錯移轉群組必須在主要伺服器上設定,並將其連接至不同 Azure 區域中的次要伺服器。 群組可以包含這些伺服器中的所有或部分資料庫。 下圖說明使用多個資料庫和自動容錯移轉群組之異地備援雲端應用程式的一般設定。

圖表顯示使用多個資料庫和自動容錯移轉群組之異地備援雲端應用程式的一般設定。

在考量到商務持續性的前提下設計服務時,請遵循本文中所述的一般指導方針和最佳做法。 設定容錯移轉群組時,請確保次要資料庫上的驗證和網路存取已設定,可在異地複寫容錯移轉之後,當異地複寫次要資料庫成為新的主要複本之後正常運作。 如需詳細資訊,請參閱 災害復原後的 SQL Database 安全性。 如需有關設計災害復原解決方案的詳細資訊,請參閱使用主動式異地複寫設計災害復原的雲端解決方案

如需使用容錯移轉群組中的時間點還原的相關資訊,請參閱時間點復原 (PITR)

初始植入

將資料庫或彈性集區新增至容錯移轉群組時,在資料複寫開始之前會有初始植入階段。 初始植入階段是最長且最昂貴的作業。 初始植入完成之後,資料就會進行同步,然後只複寫後續的資料變更。 完成初始植入所需的時間,取決於您的資料大小、複寫的資料庫數目、主要資料庫上的負載,以及主要和次要資料庫之間的連結速度。 在正常情況下,SQL Database 的可能植入速度為每小時最高 500 GB。 植入將對所有資料庫並行執行。

使用多個容錯移轉群組將多個資料庫容錯移轉

可以在不同區域 (主要和次要伺服器) 的兩部伺服器之間建立一或多個容錯移轉群組。 每個群組可包含一或多個作為復原單位的資料庫,以防所有或部分的主要資料庫因為主要區域服務中斷而變成無法使用。 建立容錯移轉群組會使用和主要資料庫相同的服務目標,來建立異地複寫次要資料庫。 如果您在容錯移轉群組中新增現有的異地複寫關聯性,請確定異地複寫次要資料庫所設定的服務層級與計算大小和主要資料庫相同。

使用讀寫接聽程式 (主要資料庫)

對於讀寫工作負載,請使用 <fog-name>.database.windows.net 作為連接字串中的伺服器名稱。 連線將自動導向至主要資料庫。 在容錯移轉之後,此名稱不會變更。 請注意,容錯移轉牽涉到更新 DNS 記錄,因此只有在重新整理用戶端 DNS 快取之後,才會將用戶端連線重新導向至新的主要伺服器。 主要和次要接聽程式 DNS 記錄的存留時間 (TTL) 為 30 秒。

使用唯讀接聽程式 (次要資料庫)

如果您有以邏輯方式隔離可容忍資料延遲的唯讀工作負載,則可以在異地複寫次要資料庫上執行這些工作負載。 對於唯讀工作階段,請使用 <fog-name>.secondary.database.windows.net 作為連接字串中的伺服器名稱。 連線將會自動導向至異地複寫次要資料庫。 也建議您使用 ApplicationIntent=ReadOnly,在連接字串中表讀取意圖。

在進階、業務關鍵和超大規模資料庫服務層級中,SQL Database 支援在連接字串中使用 參數,以使用唯讀複本ApplicationIntent=ReadOnly來卸載唯讀查詢工作負載。 當您已設定異地複寫的次要資料庫時,可以使用此功能連線至主要位置或異地複寫位置中的唯讀複本:

  • 若要連線至次要位置的唯讀複本,請使用 ApplicationIntent=ReadOnly<fog-name>.secondary.database.windows.net

容錯移轉後效能可能降低

一般的 Azure 應用程式會使用多個 Azure 服務,並由多個元件組成。 容錯移轉群組的自動異地複寫容錯移轉會根據 Azure SQL 元件的狀態而觸發。 主要區域中的其他 Azure 服務可能不會受到中斷影響,且其元件可能仍可在該區域中使用。 主要資料庫切換至次要 (DR) 區域之後,相依元件之間的延遲可能會增加。 若要避免應用程式效能較高延遲的影響,請確保 DR 區域中所有應用程式元件的備援,遵循這些網路安全性指導,並將相關應用程式元件的異地複寫容錯移轉與資料庫協調在一起。

容錯移轉後資料可能遺失

如果主要區域發生中斷的情況,最近的交易可能無法複寫至異地次要資料庫。 如果已設定自動容錯移轉原則,則系統會等到您以 GracePeriodWithDataLossHours 指定的期間經過後,再起始自動異地複寫容錯移轉。 預設值為 1 小時。 此時會著重於資料庫可用性,而非不遺失資料。 將 GracePeriodWithDataLossHours 設定為較大的數值 (例如 24 小時),或停用自動異地複寫容錯移轉可讓您降低資料遺失的可能性,但會犧牲資料庫可用性。

重要

具有 800 個或更少 DTU 或 8 個或更少個虛擬核心,且資料庫超過 250 個的彈性集區,可能會遇到的問題包括規劃的異地複寫容錯移轉時間較久與效能降低。 當異地複寫依地理位置廣泛相隔,或當每個資料庫使用多個次要異地複寫端點時,較可能會發生這些寫入大量工作負載的問題。 這些問題的徵兆是異地複寫的延隔時間會隨著時間增加,可能導致在中斷時更廣泛的資料遺失。 您可以使用 sys.dm_geo_replication_link_status 來監視這個延遲。 如果發生這些問題,則緩解措施包括相應增加集區以產生更多 DTU 或虛擬核心,或減少集區中異地複寫的資料庫數目。

容錯移轉群組和網路安全性

針對某些應用程式,需要資料層網路存取的安全性規則會限制為特定元件或元件 (例如 VM、Web 服務等)。此需求代表的是對商務持續性設計和容錯移轉群組的使用帶來一些挑戰。 實作這類限制的存取權時,請考慮下列選項。

使用容錯移轉群組和虛擬網路服務端點

如果您使用虛擬網路服務端點和規則來限制存取您位於 SQL 資料庫中的資料庫,請留意每個虛擬網路服務端點只適用於一個 Azure 區域。 端點無法讓其他區域接受來自子網路的通訊。 因此,只有部署到相同區域中的用戶端應用程式可以連線到主要資料庫。 因為異地複寫容錯移轉會導致 SQL Database 用戶端工作階段重新路由至不同 (次要) 區域中的伺服器,所以如果這些工作階段是來自該區域外的用戶端,就會失敗。 基於這個理由,如果參與的伺服器或執行個體包含在虛擬網路規則中,則無法啟用自動容錯移轉原則。 若要支援手動容錯移轉,請遵循下列步驟:

  1. 在次要區域中佈建您應用程式 (Web 服務、虛擬機器等) 前端元件的備援複本。
  2. 分別設定主要和次要伺服器的虛擬網路規則
  3. 啟用使用流量管理員設定的前端容錯移轉
  4. 偵測到中斷情況時,起始手動異地複寫容錯移轉。 這個選項最適合用於在前端和資料層之間需要一致延遲的應用程式,且支援當前端、資料層或兩者受到中斷影響時進行復原。

注意

如果您使用唯讀接聽程式對唯讀工作負載進行負載平衡,請確保此工作負載會在 VM 或是次要地區的其他資源中執行,使其得以連線到次要資料庫。

使用容錯移轉群組和防火牆規則

如果您的商務持續性計劃需要使用具有自動容錯移轉的群組,可以使用公用 IP 防火牆規則,來限制對您 SQL Database 中資料庫的存取。 若要支援自動容錯移轉,請遵循下列步驟:

  1. 建立公用 IP
  2. 建立公用負載平衡器並為其指派公用 IP。
  3. 建立虛擬網路和虛擬機器以用於前端元件。
  4. 建立網路安全性群組並設定輸入連線。
  5. 使用 Sql.<Region>服務標籤,確保輸出連線對區域中的 Azure SQL Database 開啟。
  6. 建立 SQL Database 防火牆規則以允許您在步驟 1 中所建立公用 IP 位址的輸入流量。

如需如何設定輸出存取,以及在防火牆規則中使用哪些 IP 的相關詳細資訊,請參閱負載平衡器輸出連線

上述設定可確保自動異地複寫容錯移轉不會封鎖來自前端元件的連線,並假設應用程式可以容忍前端與資料層之間較長的延遲。

重要

若要保證區域性中斷期間的商務持續性,您必須確定前端元件與資料庫的異地備援。

縮放主要資料庫

您可以將主要資料庫擴大或縮小至不同的計算大小 (在相同的服務層級內),而不需要中斷任何異地次要資料庫的連線。 擴大時,建議先擴大異地次要資料庫,再擴大主要資料庫。 縮小時,則反轉順序:先縮小主要資料庫,再縮小次要資料庫。 當您將資料庫擴展到不同的服務層級時,會強制執行這項建議。

建議您特別注意此順序,以避免較低 SKU 的異地複寫次要資料庫發生超載,而必須在升級或降級程序期間重新植入的問題。 您也可以將主要資料庫狀態設為唯讀,以此方式影響對主要資料庫的所有讀寫工作負載,來避免此問題。

注意

如果您的異地複寫次要資料庫是在容錯移轉群組設定時建立,則不建議您縮小異地複寫次要資料庫。 這是為了確保您的資料層在異地複寫容錯移轉啟動之後,有足夠的容量來處理一般工作負載。

防止重要資料遺失

由於廣域網路有高度延遲情況,因此異地複寫會採用非同步複寫機制。 如果主要資料庫故障,則非同步複寫無可避免會遺失一些資料。 若要保護重要交易資料不要遺失,應用程式開發人員可以在認可交易後立即呼叫 sp_wait_for_database_copy_sync 預存程序。 呼叫 sp_wait_for_database_copy_sync 會封鎖呼叫執行緒,直到最後認可的交易已傳輸和強行寫入次要資料庫交易記錄為止。 不過,此動作不會等候次要資料庫上已傳輸的交易重新執行 (重做)。 sp_wait_for_database_copy_sync 的範圍限定為特定異地複寫連結。 任何具備主要資料庫連接權限的使用者都可以呼叫此程序。

注意

sp_wait_for_database_copy_sync 可防止特定交易在異地容錯移轉之後資料遺失,但是不保證讀取權限的完整同步處理。 sp_wait_for_database_copy_sync 程序呼叫所造成的延遲可能會相當明顯,且取決於呼叫時主要資料庫上尚未傳輸的交易記錄大小。

權限

容錯移轉群組的權限是透過 Azure 角色型存取控制 (Azure RBAC) 來管理

必須有 Azure RBAC 寫入存取權限,才能建立和管理容錯移轉群組。 SQL Server 參與者角色具有管理容錯移轉群組所需的所有必要權限。

關於特定權限範圍,請詳閱如何在 Azure SQL Database 中設定自動容錯移轉群組

限制

請留意以下限制:

  • 無法在相同 Azure 區域中的兩個伺服器之間建立容錯移轉群組。
  • 無法重新命名容錯移轉群組。 您將需要刪除群組,並使用不同的名稱重新建立。
  • 容錯移轉群組中的資料庫不支援資料庫重新命名。 您將需要暫時刪除容錯移轉群組,才能重新命名資料庫,或從容錯移轉群組中移除資料庫。

以程式設計方式管理容錯移轉群組

如先前所述,您也可以使用 Azure PowerShell、Azure CLI 和 REST API,以程式設計方式管理自動容錯移轉群組。 下表描述可用的命令集。 主動式異地複寫包含一組可管理的 Azure Resource Manager API,包括 Azure SQL Database REST APIAzure PowerShell Cmdlet。 這些 API 需要使用資源群組,並支援 Azure 角色型存取控制 (Azure RBAC)。 如需如何實作存取角色的詳細資訊,請參閱 Azure 角色型存取控制 (Azure RBAC)

Cmdlet 描述
New-AzSqlDatabaseFailoverGroup 此命令會建立容錯移轉群組,並同時在主要和次要伺服器上註冊
Remove-AzSqlDatabaseFailoverGroup 從伺服器移除容錯移轉群組
Get-AzSqlDatabaseFailoverGroup 擷取容錯移轉群組的設定
Set-AzSqlDatabaseFailoverGroup 修改容錯移轉群組的設定
Switch-AzSqlDatabaseFailoverGroup 觸發容錯移轉群組容錯移轉至次要伺服器
Add-AzSqlDatabaseToFailoverGroup 將一或多個資料庫新增至容錯移轉群組

後續步驟