容錯移轉群組概觀和最佳做法（Azure SQL 資料資料庫）

適用於：Azure SQL 資料庫

• Azure SQL Database
• Azure SQL 受控執行個體

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

欲開始使用此功能，請詳閱 設定容錯移轉群組。

請注意

本文涵蓋了 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 時間 (停機時間)，才使用此選項。	Yes

客戶管理的

在少數情況下，內建的可用性或高可用性不足以緩解中斷，而且容錯移轉群組中的資料庫可能在使用資料庫的應用程式的服務等級協定 (SLA) 無法接受的持續時間內無法使用。 資料庫可能因僅會影響幾個資料庫的區域性問題而無法使用，或者也可能因為位於資料中心、可用性區域或區域層級而無法使用。 在上述任何一種情況中，若要還原商務持續性，您可以起始強制容錯移轉。

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

Microsoft 管理的

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

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

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

重要

您可以使用客戶自控的容錯移轉政策來測試及實作災害復原方案。 請勿依賴 Microsoft 管理的容錯移轉，這可能只會在極端情況下被 Microsoft 所執行。 Microsoft受控容錯移轉會針對已將容錯移轉原則設定為Microsoft受控區域中的所有容錯移轉群組起始。 無法針對個人容錯移轉群組起始它。 如果您需要選擇性容錯移轉容錯移轉群組的能力，請使用客戶管理的容錯移轉原則。

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

• 您想要將災害復原責任委派給 Azure SQL 服務。
• 應用程式可容忍您的資料庫至少一小時以上無法使用。
• 在寬限期到期一段時間後觸發強制容錯移轉是可接受的，因為強制容錯移轉的實際時間可能會有很大的差異。
• 無論容錯移轉群組中的所有資料庫的區域備援或可用性狀態為何，都可以接受容錯移轉。 雖然針對區域備援設定的資料庫能夠從區域性失敗中復原，而且可能不會受中斷影響，但如果資料庫是具有 Microsoft 管理的容錯移轉原則的容錯移轉群組一部分，則其仍然可以容錯移轉。
• 可以接受在容錯移轉群組中強制容錯移轉資料庫，而不考慮應用程式與其他 Azure 服務或應用程式使用的元件的相依性，這可能會導致應用程式效能降低或無法使用。
• 因為無法控制強制容錯移轉的確切時間，因此可以接受產生未知的資料遺失量，並忽略次要資料庫的同步處理狀態。
• 容錯移轉群組中的所有主要和次要資料庫，以及任何異地複寫關聯，都有相同的服務層級、計算層級 (已佈建或無伺服器) 和計算大小 (DTU 或虛擬核心)。 如果所有資料庫的服務等級目標 (SLO) 不相符，則透過 Azure SQL 服務，容錯移轉原則最終會從 Microsoft 管理更新為客戶管理。

當 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 區域中的次要伺服器。 容錯移轉群組可以包括這些在主要伺服器中的所有或部分資料庫。 下圖說明了在容錯移轉群組中使用多個資料庫之異地備援雲端應用程式的一般設定：

在考量到商務持續性的前提下設計服務時，請遵循本文中所述的一般指導方針和最佳做法。 設定容錯移轉群組時，請確保次要資料庫上的驗證和網路存取已設定，可在異地複寫容錯移轉之後，當異地複寫次要資料庫成為新的主要複本之後正常運作。 如需詳細資訊，請參閱 災害復原後的 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 或虛擬核心，或減少集區中異地複寫的資料庫數目。

容錯回復

當容錯移轉群組以 Microsoft 管理的容錯移轉原則設定時，將根據定義的寬限期在災害案例期間起始強制容錯移轉至異地次要伺服器。 容錯回復至舊的主要複本，將需要以手動開始。

權限和限制

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

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

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

相關內容

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