自動容錯移轉群組概觀和最佳做法 (Azure SQL 受控執行個體)

  • 發行項

適用於：Azure SQL 受控執行個體

自動容錯移轉群組功能可讓您管理受控執行個體中的所有使用者資料庫，以複寫和容錯移轉至另一個 Azure 區域。 本文著重在搭配 Azure SQL 受控執行個體和一些最佳做法使用自動容錯移轉群組功能。

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

注意

本文涵蓋 Azure SQL 受控執行個體的自動容錯移轉群組。 關於 Azure SQL Database，請參閱 SQL Database 的自動容錯移轉群組 (英文)。

概觀

自動容錯移轉群組功能可讓您管理受控實例中使用者資料庫的複寫和容錯移轉至另一個 Azure 區域中的受控實例。 自動容錯移轉群組的設計是為了簡化大規模異地複寫資料庫的部署和管理。

Automatic failover

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

卸載唯讀工作負載

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

端點重新導向

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

復原應用程式

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

如需詳細資訊，請參閱 Azure SQL 受控執行個體高可用性 。

術語和功能

  • 容錯移轉群組 (FOG)

    容錯移轉群組可讓受控執行個體內的所有使用者資料庫做為一個單位容錯移轉至另一個 Azure 區域，以防主要受控執行個體因為主要區域中斷而無法使用。 SQL 受控執行個體的容錯移轉群組包含該執行個體中的所有使用者資料庫，因此在一個執行個體上只能設定一個容錯移轉群組。

    重要

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

  • 主要

    容錯移轉群組中裝載主要資料庫的受控執行個體。

  • 次要

    容錯移轉群組中裝載次要資料庫的受控執行個體。 次要資料庫和主要資料庫不能位於相同的 Azure 區域。

  • DNS 區域

    建立新的 SQL 受控執行個體時自動產生的唯一識別碼。 系統會佈建此執行個體的多網域 (SAN) 憑證，用來向相同 DNS 區域中任何執行個體的用戶端連線進行驗證。 相同容錯移轉群組中的兩個受控執行個體必須共用 DNS 區域。

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

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

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

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

  • 自動容錯移轉原則

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

    注意

    由於驗證中斷規模以及降低其速度的方式牽涉到人為動作，因此寬限期不能設定為低於一小時，而且容錯移轉的確切時間可能會與設定的寬限期稍有不同。 此限制適用於容錯移轉群組中的所有資料庫，無論其資料同步狀態為何。

  • 唯讀的容錯移轉原則

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

    注意

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

  • 計劃性容錯移轉

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

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

    注意

    如果資料庫包含記憶體內部 OLTP 物件，主資料庫和次要異地複本資料庫必須具有相符的服務層級，因為記憶體內部 OLTP 物件位於記憶體中。 異地複本資料庫的較低服務層級可能會導致記憶體不足的問題。 如果發生這種情況，異地複本可能無法復原資料庫，導致次要資料庫與異地次要資料庫上的記憶體內部 OLTP 物件無法使用。 這反過來又可能導致容錯移轉失敗。 若要避免這種情況，請確定異地次要資料庫的服務層級符合主資料庫的服務層級。 服務層級升級可以是資料大小作業，可能需要一段時間才能完成。

  • 未規劃的容錯移轉

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

  • 手動容錯移轉

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

  • 資料遺失的寬限期

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

容錯移轉群組結構

自動容錯移轉群組必須在主要執行個體上設定，並將其連接至不同 Azure 區域中的次要執行個體。 執行個體中的所有使用者資料庫都將複寫至次要執行個體。 將不會複寫 master 和 msdb 之類的系統資料庫。

下圖說明使用受控執行個體和自動容錯移轉群組的異地備援雲端應用程式一般設定：

Auto-failover group diagram for SQL MI

如果您的應用程式使用 SQL 受控執行個體作為資料層，請在設計業務持續性時遵循本文中概述的一般指導和最佳做法。

建立異地次要執行個體

若要確保容錯移轉之後與主要 SQL 受控執行個體的連線不會中斷，主要和次要執行個體必須位於相同的 DNS 區域。 其將保證相同的多網域 (SAN) 憑證可以用來將用戶端連線向容錯移轉群組中的兩個執行個體驗證。 當您的應用程式準備好進行生產環境部署時，請在不同區域中建立次要 SQL 受控執行個體，並確保其與主要 SQL 受控執行個體共用 DNS 區域。 您可以在建立期間指定選擇性參數來執行。 如果您使用 PowerShell 或 REST API，則選擇性參數的名稱是 DNSZonePartner。 Azure 入口網站中對應的選擇性欄位名稱是主要受控執行個體。

重要

在子網路中建立的第一個受控執行個體會決定相同子網路中所有後續執行個體的 DNS 區域。 這表示來自相同子網路的兩個執行個體不能屬於不同的 DNS 區域。

如需在與主要執行個體相同的 DNS 區域中建立次要 SQL 受控執行個體的詳細資訊，請參閱建立次要受控執行個體。

使用配對的區域

基於效能考慮，這兩個受控執行個體都會部署到配對區域。 相較於未配對的區域，配對區域中的 SQL 受控執行個體容錯移轉群組會有更好的效能。

Azure SQL 受控執行個體遵循安全部署做法，其中 Azure 配對區域通常不會同時部署到其中。 不過，無法預測哪些區域會先升級，因此不保證部署順序。 有時候，您的主要實例會先升級，有時會是次要實例。

如果Azure SQL 受控執行個體屬於自動容錯移轉群組的一 部分，且群組中的實例不在 Azure 配對區域中 ，請為您的主要和次要資料庫選取不同的維護時段排 程。 例如，為異地次要資料庫選取 [工作日 維護] 視窗，並為 異地主資料庫選取 [週末 維護] 視窗。

啟用和最佳化執行個體之間的異地複寫流量流程

必須在裝載主要和次要執行個體的虛擬網路子網路之間建立並維護連線，才能讓異地複寫流量不會中斷。 根據根據網路拓撲和原則，您可透過許多方式在執行個體之間提供連線能力：

重要

在容錯移轉群組中的兩個執行個體之間建立連線的建議方法，是全域虛擬網路對等互連 (VNet 對等互連)。 其會使用 Microsoft 骨幹基礎結構，在對等互連的虛擬網路之間提供低延遲、高頻寬的私人連線。 對等互連的虛擬網路之間所進行的通訊不需要公用網際網路、閘道或其他加密措施。 在 2020 年 9 月 22 日之後所建立的子網路中裝載的執行個體，都支援全域虛擬網路對等互連。 若要能夠對在 2020 年 9 月 22 日之前建立的子網路中裝載的 SQL 受控執行個體使用全域虛擬網路對等互連，請考慮在執行個體上設定非預設維護期間，因為這會將執行個體移至支援全域虛擬網路對等互連的新虛擬叢集。

無論連線機制為何，都必須符合特定需求，異地複寫流量才能流動：

  • 指派給受控實例子網的路由表和網路安全性群組不會在兩個對等互連虛擬網路之間共用。
  • 裝載主要 實例之子網 上的網路安全性群組 （NSG） 規則允許：
    • 連接埠 5022 和連接埠範圍 11000-11999 上來自次要執行個體裝載所在子網路的輸入流量。
    • 連接埠 5022 和連接埠範圍 11000-11999 上送往次要執行個體裝載所在子網路的輸出流量。
  • 裝載次要 實例的子網 上的網路安全性群組 （NSG） 規則允許：
    • 連接埠 5022 和連接埠範圍 11000-11999 上來自主要執行個體裝載所在子網路的輸入流量。
    • 連接埠 5022 和連接埠範圍 11000-11999 上送往主要執行個體裝載所在子網路的輸出流量。
  • 裝載主要和次要執行個體之 VNet 的 IP 位址範圍不可重疊。
  • 裝載主要和次要實例的 VNet 之間，或透過本機虛擬網路對等互連或其他方式與其他 VNet 之間，IP 位址範圍沒有間接重迭。

此外，如果您使用其他機制來提供執行個體之間的連線能力，而不使用建議的全域虛擬網路對等互連，您必須確定下列事項：

  • 所使用的任何網路裝置，例如防火牆或網路虛擬設備 (NVA)，都不會封鎖上述流量。
  • 路由已正確設定，並且避免非對稱式路由。
  • 如果您在跨區域的中樞和輪輻網路拓撲中部署自動容錯移轉群組，則複寫流量應該直接在兩個受控執行個體子網路之間進行，而不是透過中樞網路導向。 這有助於避免發生連線和複寫速度問題。

重要

涉及其他網路裝置的執行個體之間提供連線的替代方式，可能會在連線或複寫速度非常困難的情況下進行疑難排解程序，而且需要網路系統管理員主動介入，並大幅延長解決時間。

初始植入

在受控執行個體之間建立容錯移轉群組時，資料複寫開始之前會有初始植入階段。 初始植入階段這部分是最長且最昂貴的作業。 初始植入完成之後，資料就會進行同步，只複寫後續的資料變更。 初始植入完成所花費的時間取決於資料大小、複寫的資料庫數目、主資料庫上的工作負載強度，以及裝載主要和次要執行個體的虛擬網路之間的連結速度 (主要以連線方式為基礎) 而定。 在一般情況下，以及使用建議的全域虛擬網路對等互連建立連線時，SQL 受控執行個體一小時最多可達 360 GB 的植入速度。 植入是平行執行一批使用者資料庫，不一定會同時針對所有資料庫執行。 如果執行個體上裝載多個資料庫，可能需要以多個批次進行。

如果兩個執行個體之間的連結速度低於所需的速度，則植入的時間可能會受到明顯的影響。 您可以使用所述的植入速度、資料庫數目、資料大小總計及連結速度，以估計在資料複寫開始之前，初始植入階段將耗費的時間長度。 例如，針對一個 100-GB 的資料庫，如果連結可以每小時推送 84 GB，且沒有植入其他資料庫，則初始植入階段大約需要 1.2 小時的時間。 如果連結每小時只能傳送 10 GB，則植入一個 100-GB 的資料庫，大約需要 10 小時。 如果有多個要複寫的資料庫，則會以平行方式執行植入，並在結合緩慢的連結速度時，初始植入階段可能需要更長的時間，特別是當從所有資料庫平行植入的資料超過可用的連結頻寬時。

重要

如果因極低的速度或忙碌連結，讓初始植入階段需要幾天的時間進行，建立容錯移轉群組可能會逾時。建立程序會在 6 天后自動取消。

管理對異地複寫次要執行個體的異地複寫容錯移轉

容錯移轉群組將管理主要受控執行個體上所有資料庫的異地複寫容錯移轉。 建立群組時，執行個體中的每個資料庫將會自動異地複寫到異地複寫次要執行個體。 您無法使用容錯移轉群組來起始資料庫子集的部分容錯移轉。

重要

如果在主要受控執行個體上卸除資料庫，也會自動在異地複寫次要受控執行個體上卸除。

使用讀寫接聽程式 (主要受控執行個體)

針對讀寫工作負載，請使用 <fog-name>.zone_id.database.windows.net 作為伺服器名稱。 連線將自動導向至主要資料庫。 在容錯移轉之後，此名稱不會變更。 異地複寫容錯移轉牽涉到更新 DNS 記錄，因此只有在重新整理用戶端 DNS 快取之後，才會將用新戶端連線路由至新的主要伺服器。 因為次要執行個體與主要執行個體共用 DNS 區域，因此用戶端應用程式將能夠使用相同的伺服器端 SAN 憑證重新連線到該區域。 必須先終止現有的用戶端連線，才能重新建立以路由傳送至新的主要複本。 無法透過該受控執行個體的公用端點連線到讀寫接聽程式和唯讀接聽程式。

使用唯讀接聽程式 (次要受控執行個體)

如果您有以邏輯方式隔離可容忍資料延遲的唯讀工作負載，則可以在異地複寫次要資料庫上執行這些工作負載。 若要直接連線至異地複寫次要資料庫，請使用 <fog-name>.secondary.<zone_id>.database.windows.net 作為伺服器名稱。

在業務關鍵層中，SQL 受控執行個體支援在連接字串中使用 ApplicationIntent=ReadOnly 參數，來卸載唯讀查詢複本。 當您已設定異地複寫的次要執行個體時，可以使用此功能連接至主要位置或異地複寫位置中的唯讀複本：

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

無法透過受控執行個體的公用端點連線到讀寫接聽程式和唯讀接聽程式。

容錯移轉後效能可能降低

一般的 Azure 應用程式會使用多個 Azure 服務，並由多個元件組成。 容錯移轉群組的自動異地複寫容錯移轉會根據 Azure SQL 元件的狀態而觸發。 主要區域中的其他 Azure 服務可能不會受到中斷影響，且其元件可能仍可在該區域中使用。 主要資料庫切換至次要區域之後，相依元件之間的延遲可能會增加。 請確保次要區域中所有應用程式元件備援，並將應用程式元件與資料庫一起容錯移轉，以確保應用程式執行不會進一步受影響。

容錯移轉後資料可能遺失

如果主要區域發生中斷的情況，最近的交易可能無法複寫至異地次要資料庫。 會使用 GracePeriodWithDataLossHours 延遲指定期間的容錯移轉。 如果您已設定自動容錯移轉原則，請為資料遺失做好準備。 服務中斷期間，Azure 一般會傾向維持可用性。 將 GracePeriodWithDataLossHours 設定為較大的數值 (例如 24 小時)，或停用自動異地複寫容錯移轉可讓您降低資料遺失的可能性，但會犧牲資料庫可用性。

DNS 更新

在起始容錯移轉之後，將立即發生讀寫接聽程式的 DNS 更新。 這項作業將不會導致資料遺失。 但是，在正常情況下，切換資料庫角色的程序最多可能需要 5 分鐘的時間。 在完成之前，新的主要執行個體中的某些資料庫仍會處於唯讀模式。 如果是使用 PowerShell 起始容錯移轉，則切換主要複本角色的作業會是同步的。 如果是使用 Azure 入口網站來起始，UI 將指出完成狀態。 如果使用 REST API 來起始，請使用標準 Azure Resource Manager 的輪詢機制來監視完成情況。

重要

使用手動規劃的容錯移轉，在導致異地複寫容錯移轉的中斷緩解時，將主要資料庫移回原始位置。

使用免授權災害復原複本節省成本

您可以將次要受控執行個體設定為僅用於災害復原 (DR)，以節省 SQL Server 授權成本。 若要進行這項設定，請參閱設定免費的災害復原複本。

只要次要執行個體未用於讀取工作負載，Microsoft 就會提供任意數目的虛擬核心，以配合主要執行個體。 您仍須支付次要執行個體所使用的計算和儲存體。 自動容錯移轉群組僅支援一個複本，複本必須是可讀取的複本，或指定為僅限災害復原的複本。

啟用相依於系統資料庫中物件的案例

系統資料庫不會複寫到容錯移轉群組中的次要執行個體。 若要啟用相依於系統資料庫中物件的案例，請務必在次要執行個體上建立相同的物件，並將其與主要執行個體保持同步。

例如，如果您計劃在次要執行個體上使用相同的登入，請務必使用相同的 SID 來建立。

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

若要深入瞭解，請參閱登入和代理程式作業的複寫。

同步執行個體之間的執行個體屬性和保留原則

容錯移轉群組中的執行個體會保留不同的 Azure 資源，而對主要執行個體的設定所做的任何變更將會自動複寫至次要執行個體。 請務必在主要和次要執行個體上執行所有相關的變更。 例如，如果您在主要執行個體上變更備份儲存體備援或長期備份保留原則，也請務必在次要執行個體上變更。

調整執行個體

您可以將主要和次要執行個體在相同的服務層級內擴大或縮小至不同的計算大小，或擴大或縮小至不同的服務層級。 在相同的服務層級內相應增加時，建議您先相應增加異地次要，然後再相應增加主要複本。 在相同服務層級內相應減少時，請反轉順序：先相應減少主要複本，然後相應減少次要複本。 當您將執行個體擴展到不同的服務層級時，會強制執行這項建議。 調整服務層級和虛擬核心以及儲存體時，會強制執行作業順序。

建議您特別注意該順序，以避免較低 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 受控執行個體參與者具有管理容錯移轉群組所需的所有必要權限。

關於特定權限範圍，請詳閱如何在 Azure SQL 受控執行個體中設定自動容錯移轉群組。

限制

請留意以下限制：

  • 無法在相同 Azure 區域中的兩個執行個體之間建立容錯移轉群組。
  • 無法重新命名容錯移轉群組。 您將需要刪除群組，並使用不同的名稱重新建立。
  • 容錯移轉群組只包含兩個受控執行個體。 不支援將其他執行個體新增至容錯移轉群組。
  • 無論何時執行個體只能參與一個容錯移轉群組。
  • 無法在屬於不同 Azure 租用戶的兩個執行個體之間建立容錯移轉群組。
  • 您無法使用 Azure 入口網站 或 Azure CLI 在屬於不同 Azure 訂用帳戶的兩個執行個體之間建立容錯移轉群組。 請改用 Azure PowerShell 或 REST API 來建立這類容錯移轉群組。 建立之後，跨訂用帳戶容錯移轉群組會在Azure 入口網站中定期顯示，而且所有後續的作業，包括容錯移轉都可以從 Azure 入口網站 或 Azure CLI 起始。
  • 容錯移轉群組中的資料庫不支援資料庫重新命名。 您將需要暫時刪除容錯移轉群組，才能重新命名資料庫。
  • 系統資料庫不會複寫至容錯移轉群組中的次要執行個體。 因此，相依於系統資料庫 (例如伺服器登入和代理程式作業) 中物件的案例需要在次要執行個體上手動建立物件，並在主要執行個體上進行任何變更之後，手動保持同步。 唯一的例外是 SQL 受控執行個體的服務主要金鑰 (SMK)，其會在建立容錯移轉群組期間自動複寫至次要執行個體。 不過，主要執行個體上的任何後續 SMK 變更都不會複寫至次要執行個體。 若要深入了解，請參閱如何啟用相依於系統資料庫中物件的案例。
  • 如果任何容錯移轉群組在執行個體集區中，就無法在執行個體之間建立。

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

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

Cmdlet 描述
New-AzSqlDatabaseInstanceFailoverGroup 此命令會建立容錯移轉群組，並同時在主要和次要執行個體上註冊
Set-AzSqlDatabaseInstanceFailoverGroup 修改容錯移轉群組的設定
Get-AzSqlDatabaseInstanceFailoverGroup 擷取容錯移轉群組的設定
Switch-AzSqlDatabaseInstanceFailoverGroup 觸發容錯移轉群組容錯移轉至次要執行個體
Remove-AzSqlDatabaseInstanceFailoverGroup 移除容錯移轉群組

後續步驟