容錯移轉群組概述與最佳實踐（Azure SQL 資料庫）

適用於：Azure SQL 資料庫

• Azure SQL 資料庫
• Azure SQL 受控執行個體

容錯移轉群組功能可讓您管理某個或某些在邏輯伺服器上的資料庫的複寫和容錯移轉，將其移轉至另一個區域的邏輯伺服器。 本文提供容錯移轉群組功能的概觀，其中包含搭配 Azure SQL 資料庫使用此功能的最佳做法和建議。

若要開始使用此功能，請檢閱 設定 Azure SQL Database的故障轉移群組。

請注意

本文介紹 Azure SQL 資料庫的故障轉移群組。 如需 Azure SQL 受控實例，請參閱 故障轉移群組概觀 & 最佳做法 - Azure SQL 受控實例。

欲瞭解其他關於 Azure SQL 資料 災害復原的資訊，請觀看這段影片：

概觀

容錯移轉群組功能可讓您管理資料庫的複寫和容錯移轉至另一個 Azure 區域。 您可以選擇邏輯伺服器中的所有或子集、使用者資料庫，複寫至另一個邏輯伺服器。 其為作用中異地複寫功能上的宣告式抽象概念，旨在簡化異地複寫資料庫的大規模部署和管理。

如需異地容錯移轉的 RPO 和 RTO 資訊，請參閱 [商務持續性概觀]。

端點重新導向

故障轉移群組提供異地故障轉移期間保持不變的讀寫和只讀接聽程式端點。 您不需要在地理失敗轉移之後變更應用程式的連接字串，因為連線會自動路由至目前的主要伺服器。 地理容錯移轉將群組中所有的次要資料庫轉換為主要角色。 異地容錯移轉完成後，DNS 記錄會自動更新以將端點重新導向至新的區域。

卸載唯讀工作負載

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

復原應用程式

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

容錯移轉原則

容錯移轉群組支援兩個容錯移轉原則：

• 客戶管理 (建議) - 當客戶注意到對容錯移轉群組中的一個或多個資料庫造成非預期的中斷影響時，可以執行群組的容錯移轉。 使用 PowerShell、Azure CLI 或 Rest API 等命令列工具時，客戶管理的容錯移轉原則值是 manual。
• Microsoft 受控 - 如果發生影響主要區域的廣泛中斷，Microsoft 會起始 所有 受影響容錯移轉群組的容錯移轉，這些群組的容錯移轉原則設定為 Microsoft 管理。 不會針對區域內的個別容錯移轉群組或一部分的容錯移轉群組啟動 Microsoft 受管的容錯移轉。 使用 PowerShell、Azure CLI 或 Rest API 等命令行工具時，Microsoft 受管的容錯移轉原則值是 automatic。

每個容錯移轉原則都有一組獨特的使用案例，以及容錯移轉範圍和資料遺失的對應預期，如下表摘要所示：

容錯移轉原則	容錯移轉範圍	使用案例	潛在資料遺失
由客戶管理 (建議使用)	容錯移轉群組	容錯移轉群組中的一或多個資料庫發生中斷，並變得無法使用。 您可以選擇執行容錯移轉。	是
Microsoft 管理的	區域中的所有容錯移轉群組	區域中的廣泛中斷會導致資料庫無法使用，而 Microsoft Azure SQL 服務小組決定觸發強制容錯移轉。 只有在您想要將災害復原責任委派給 Microsoft，且應用程式可容忍至少一小時以上的 RTO 時間 (停機時間)，才使用此選項。 Microsoft 受控容錯移轉可能只會在極端情況下執行。 強烈建議使用 客戶管理的故障轉移策略。	是

客戶自行管理

在極少數情況下，內建 可用性或高可用性 不足以緩解中斷，而且容錯移轉群組中的資料庫可能會在使用資料庫之應用程式的服務等級協定 （SLA） 無法接受的持續時間內無法使用。 資料庫可能會因僅影響幾個資料庫的區域性問題而無法使用，或者可能是由於資料中心、可用性區域或地區層級的問題而導致無法使用。 在上述任何一種情況中，若要恢復業務持續性，您可以啟動強制故障轉移。

強烈建議您將容錯移轉原則設定為客戶管理，因為此方式可讓您控制何時起始容錯移轉和還原商務持續性。 當您注意到容錯移轉群組中的一或多個資料庫遇到非預期的中斷影響時，您可以啟動容錯移轉。

Microsoft 管理的

使用 Microsoft 受管的容錯移轉原則，災害復原責任會委派給 Azure SQL 服務。 若要讓 Azure SQL 服務執行強制移轉，需符合以下條件：

• 由自然災害事件、組態變更、軟體錯誤或硬體元件故障所導致的區域層級中斷，以及區域中的許多資料庫都會受到影響。
• 寬限期已過期。 由於驗證中斷的規模以及緩解中斷取決於人為動作，因此寬限期不能設定為低於一小時。

符合這些條件時，Azure SQL 服務會對區域中所有已將容錯移轉原則設定為 Microsoft 管理的容錯移轉群組起始強制容錯移轉。

重要

使用客戶管理的容錯移轉原則來測試和實作您的災難復原計劃。 請勿依賴 Microsoft 管理的容錯移轉，這可能只會在極端情況下被 Microsoft 所執行。 Microsoft 受控容錯移轉會針對區域中所有容錯移轉群組起始，其容錯移轉原則設定為 Microsoft 受控。 無法針對個別容錯移轉群組啟動。 如果您需要選擇性容錯移轉群組容錯移轉，請使用客戶管理的容錯移轉原則。

僅在下列情況下將容錯移轉原則設定為 Microsoft 管理：

• 您想要將災害復原責任委派給 Azure SQL 服務。
• 應用程式可容忍您的資料庫至少一小時以上無法使用。
• 在寬限期到期後一段時間觸發強制容錯移轉是可以接受的，因為強制容錯移轉的實際時間可能會有很大差異。
• 在容錯移轉群組中，無論所有資料庫的區域備援設定或可用性狀態如何，容錯移轉都是可以接受的。 雖然為區域備援配置的資料庫對區域失敗具有彈性，且可能不會受到中斷的影響，但如果資料庫是具有 Microsoft 管理的故障轉移政策的故障轉移群組的一部分，它們仍將進行故障轉移。
• 允許在容錯移轉群組中強制容錯移轉資料庫，而不考慮應用程式對其他 Azure 服務或應用程式使用的元件的相依性，這會導致應用程式的效能降低或無法使用。
• 由於無法控制強制容錯移轉的確切時間，且次要資料庫的同步狀態會被忽略，因此可以接受發生未知數量的資料遺失。
• 容錯移轉群組中的主要和次要複本具有相同的服務層級、計算層和計算大小。

當 Microsoft 觸發容錯移轉時，會將作業名稱為容錯移轉 Azure SQL 容錯移轉群組的項目新增至 Azure 監視器活動記錄。 項目包含 [資源] 底下的容錯移轉群組名稱，而 [事件起始者] 會顯示單一連字號 (-) 以指出容錯移轉是由 Microsoft 起始的。 您也可以在 Azure 入口網站中新主要伺服器或執行個體的 [活動記錄] 頁面上找到此資訊。

術語和功能

• 故障轉移群組 (FOG)

  容錯移轉群組是由 Azure 中單一邏輯伺服器 所管理的資料庫命名群組，如果因為主要區域中斷而導致所有或部分主要資料庫無法使用，則可以將這些資料庫作為一個單位容錯移轉到另一個區域。

  重要

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

• 伺服器

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

• 主要

  容錯移轉群組中託管主要資料庫的邏輯伺服器。

• 次要

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

• 故障轉移（沒有資料遺失）

  故障切換會在主要資料庫和次要資料庫之間執行完整的資料同步處理，然後將次要資料庫切換為主要角色。 這可確保不會遺失資料。 只有在主要資料庫可供存取時，才能進行容錯移轉。 容錯移轉用於以下情境：

  • 在資料遺失不可接受時，在生產環境中執行災害復原 (DR) 演練
  • 將工作負載重新放置到不同的區域
  • 在中斷問題解決（恢復）後，將工作負載返回至主要區域。

• 強制故障轉移 (可能的資料遺失)

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

• 資料遺失的寬限期

  由於資料使用非同步複寫技術予以複寫至次要備援系統，對於具有 Microsoft 管理的容錯移轉政策的群組進行強制容錯移轉可能會導致資料遺失。 您可以設定故障轉移策略，以反映應用程式對資料遺失的容忍度。 藉由設定 GracePeriodWithDataLossHours，您可以控制 Azure SQL 服務在開始強制容錯移轉之前的等候時間，這可能會導致資料遺失。

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

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

  重要

  • 請確保次要邏輯伺服器不具有相同名稱的資料庫，除非其為現有的次要資料庫。
  • 如果資料庫包含記憶體內部 OLTP 物件，則主要資料庫和次要異地複本資料庫必須具相符的服務層級，因為記憶體內部 OLTP 物件會在記憶體中凍結。 異地複本資料庫上較低的服務層級可能會導致記憶體不足的問題。 如果發生這種情況，異地複本可能無法復原資料庫，導致次要資料庫與異地次要資料庫上的記憶體內部 OLTP 物件無法使用。 因此，這也會導致容錯移轉失敗。 欲避免這種情況，請確保異地次要資料庫的服務層級符合主要資料庫的服務層級。 服務層級升級可能是涉及大量資料的操作，因此可能需要一段時間才能完成。

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

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

• 容錯移轉群組讀寫監聽器

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

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

  指向目前的次要資料庫的 DNS CNAME 記錄。 其是在容錯移轉群組建立時自動建立，並允許唯讀 SQL 工作負載在容錯移轉之後次要資料庫變更時，以透明的方式連線到次要資料庫。 在伺服器上建立容錯移轉群組時，接聽程式 URL 的 DNS CNAME 記錄格式會是 <fog-name>.secondary.database.windows.net。 根據預設，唯讀接聽程式的容錯移轉會被停用，因為當次要伺服器離線時，這可確保主要伺服器的效能不受影響。 不過，這也表示在次要資料庫復原之前，唯讀工作階段將無法連線。 如果您無法容忍唯讀工作階段的停機時間，並且可以將主要資料庫用於唯讀和讀寫流量，但代價是主要資料庫潛在的效能降低，則可以透過設定 AllowReadOnlyFailoverToPrimary 屬性來為唯讀接聽程式啟用容錯移轉。 在該情況下，如果次要資料庫無法使用時，唯讀流量會自動重新導向到主要資料庫。

  請注意

  只有在已啟用 Microsoft 管理的容錯移轉原則，且已觸發強制容錯移轉時，AllowReadOnlyFailoverToPrimary 屬性才有作用。 在該情況下，如果屬性設定為 True，新的主要伺服器將同時為讀寫和唯讀工作階段提供服務。

• 多個容錯移轉群組

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

容錯移轉群組架構

Azure SQL 資料庫中的容錯移轉群組可包含一或多個資料庫，通常是由相同的應用程式所使用。 容錯移轉群組必須在主要伺服器上設定，並將其連接至不同 Azure 區域中的次要伺服器。 容錯移轉群組可以包括在主要伺服器中的全部或部分資料庫。 下圖說明了使用多個資料庫的故障轉移群組中，異地備援雲端應用程式的一般設定：

在考量到商務持續性的前提下設計服務時，請遵循本文中所述的一般指導方針和最佳做法。 在配置容錯移轉群組時，請確保次要節點上的驗證和網路存取已設定妥當，以便在發生異地容錯移轉後，當異地次要節點成為新的主要節點時，能夠正常運作。 如需詳細資訊，請參閱 針對異地還原或故障轉移設定及管理 Azure SQL Database 的安全性。 如需詳細資訊，請參閱 使用 Azure SQL Database 設計全域可用的服務 和 Azure SQL Database 異地還原。

使用配對區域

在主要和輔助伺服器之間建立容錯移轉群組時，選擇使用配對區域，因為相較於未配對區域，配對區域中的容錯移轉群組效能更佳。

遵循安全部署做法，Azure SQL 資料庫通常不會同時更新配對區域。 不過，這無法預測哪些區域會先升級，因此不能保證部署順序。 有時候，您的主要伺服器會先升級，有時也會後續才升級。

如果您針對與 Azure 區域配對不符的資料庫設定異地複寫或容錯移轉群組，請為主要和次要資料庫使用不同的維護視窗排程。 例如，您可為次要資料庫選取 [工作日] 維護視窗，並為主要資料庫選取 [周末] 維護視窗。

初期播種

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

容錯移轉群組內資料庫的數量

容錯移轉群組內資料庫的數量，直接影響容錯移轉以及強制容錯移轉作業的持續時間。

• 容錯移轉（也稱為規劃的容錯移轉）期間，我們可以確保所有主要資料庫都與其次要資料庫充分同步，並進入準備就緒的狀態。 資料庫以批次方式準備，以免控制平面不堪負荷。 因此，強烈建議限制容錯移轉群組內資料庫的數量。
• 若為強制故障切換，由於不會啟動資料同步，因此準備階段會加快。 若要讓容錯移轉持續時間更快且可預測，不妨儘量減少容錯移轉群組內資料庫的數量。

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

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

使用讀寫監聽器（主要）

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

使用唯讀監聽器（次要）

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

在進階、商務關鍵和超大規模服務層級中，SQL 資料庫支援使用唯讀複本來卸載唯讀查詢工作負載（在連接字串中使用 ApplicationIntent=ReadOnly 參數）。 當您配置異地次要位置時，可以使用此功能來連接到主要位置或異地次要位置中的唯讀複本：

要連線到次要位置的唯讀複本，請使用 ApplicationIntent=ReadOnly 和 <fog-name>.secondary.database.windows.net。

容錯移轉後效能可能降低

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

強制切換失敗後可能會發生資料遺失

如果主要區域發生中斷，最近的交易可能尚未複寫至地理次要資料庫，而且在執行強制故障轉移時可能會遺失資料。

重要

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

故障回復

當容錯移轉群組使用 Microsoft 管理的容錯移轉原則進行設定時，一旦發生災害事件，將在定義的緩衝期內強制的容錯移轉至異地次要伺服器。 回退至舊的主要伺服器必須手動進行。

權限和限制

檢閱設定容錯移轉群組指南，取得權限和限制的清單。

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

您也可以使用 Azure PowerShell、Azure CLI 和 REST API，以程式設計方式管理容錯移轉群組。 如需詳細資訊，請檢閱 設定 Azure SQL Database的故障轉移群組。

開啟高可用性 （區域備援）

通過冗餘提高可用性 進一步增強了復原能力，因為它可以防止區域內可用性區域因中斷而無法使用。

建立包含一或多個資料庫的故障轉移群組時，不論主資料庫的高可用性設定為何，都無法啟用輔助資料庫的高可用性。

非超大規模資料庫的區域備援

透過故障轉移群組建立的輔助資料庫 預設不會 啟用高可用性。 建立故障轉移群組之後，請在群組中包含的資料庫上啟用高可用性。 如果您先建立 Active Geo-Replication，然後選擇性將資料庫新增至故障移轉群組，此行為也會適用。

使用超大規模資料庫的區域冗餘

透過故障轉移群組建立的輔助資料庫將會繼承其對應主資料庫的高可用性設定。 因此，如果主資料庫已啟用高可用性，輔助資料庫也會啟用它。 相反地，如果主資料庫未啟用高可用性，輔助資料庫也不會啟用它。

可用性區域的區域支援

在主資料庫上啟用高可用性，且所新增的輔助資料庫位於尚不支援可用性區域的區域中，工作流程將會失敗，並出現錯誤訊息，其代碼為 45122：「建立或更新故障轉移群組作業已順利完成;不過，某些資料庫無法新增至故障轉移群組或從故障轉移群組中移除。 您目前的請求不支援布建區域冗餘資料庫/集區。若要解決此問題，請在建立輔助資料庫時，使用 作用中異地複寫 以啟用或停用高可用性。 然後，您可以選擇性地將這些資料庫新增至故障轉移群組。

相關內容

• 如需範例指令，請參閱：
  • 使用 PowerShell 為 Azure SQL 資料庫設定主動式異地複寫
  • 使用 PowerShell 為 Azure SQL 資料庫中的集區資料庫設定啟用異地複寫
  • 使用 PowerShell 將 Azure SQL 資料庫新增至容錯移轉群組
• 如需商務持續性概觀和案例，請參閱 商務持續性概觀
• 若要了解 Azure SQL 資料庫自動備份，請參閱 SQL Database 自動備份。
• 若要了解如何使用自動備份進行復原，請參閱 從由服務啟動的備份中還原資料庫。
• 若要深入了解新的主要伺服器和資料庫的驗證需求，請參閱 災害復原後的 SQL Database 安全性。