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

適用于:Azure SQL 受控執行個體

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

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

注意

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

概觀

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

Automatic failover

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

卸載唯讀工作負載

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

端點重新導向

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

復原應用程式

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

術語和功能

  • 容錯移轉群組 (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 檢查點專用 模式。 允許唯讀資料表查詢,但受影響的異地次要資料庫複本上不允許唯讀的記憶體內部 OLTP 資料表查詢。 如果異地次要資料庫中的所有複本都處於僅檢查點模式,則會封鎖計劃性容錯移轉。 非計劃性容錯移轉可能會因為記憶體不足問題而失敗。 若要避免這種情況,請升級次要資料庫的服務層級,以在計劃性容錯移轉期間比對主資料庫,或鑽研。 服務層級升級可以是資料大小作業,可能需要一段時間才能完成。

  • 未規劃的容錯移轉

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

  • 手動容錯移轉

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

  • 資料遺失的寬限期

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

容錯移轉群組結構

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

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

SQL MI 的自動容錯移轉群組圖表

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

建立異地次要執行個體

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

重要

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

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

使用配對的區域

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

啟用和優化實例之間的異地複寫流量流程

必須建立並維護裝載主要和次要實例之虛擬網路子網之間的連線能力,以便進行不中斷的異地複寫流量。 有多種方式可讓您根據網路拓撲和原則,在實例之間提供連線能力:

重要

全域虛擬網路對等互連 是建立容錯移轉群組中兩個實例間連線的建議方式。 它會使用 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 與透過本機虛擬網路對等互連或其他任何方式,不會間接重迭 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輪詢機制來監視完成。

重要

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

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

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

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

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

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

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

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

調整實例

您可以將主要和次要實例相應增加或相應減少到相同服務層級內的不同計算大小。 擴大時,建議先擴大異地次要資料庫,再擴大主要資料庫。 縮小時,則反轉順序:先縮小主要資料庫,再縮小次要資料庫。 當您將實例調整為不同的服務層級時,會強制執行此建議。

建議特別避免在較低 SKU 的異地次要複寫時發生問題,而且必須在升級或降級程式期間重新植入。

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

如果您使用虛擬網路服務端點和規則來限制對SQL 受管理執行個體的存取,請注意,每個虛擬網路服務端點僅適用于一個 Azure 區域。 端點無法讓其他區域接受來自子網路的通訊。 因此,只有部署到相同區域中的用戶端應用程式可以連線到主要資料庫。

防止重要資料遺失

由於廣域網路有高度延遲情況,因此異地複寫會採用非同步複寫機制。 如果主要資料庫故障,則非同步複寫無可避免會遺失一些資料。 若要保護重要交易資料不要遺失,應用程式開發人員可以在認可交易後立即呼叫 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 區域中的兩個實例之間建立容錯移轉群組。
  • 無法重新命名容錯移轉群組。 您將需要刪除群組,並使用不同的名稱重新建立。
  • 容錯移轉群組只包含兩個受控實例。 不支援將其他實例新增至容錯移轉群組。
  • 實例隨時只能參與一個容錯移轉群組。
  • 容錯移轉群組中的資料庫不支援資料庫重新命名。 您將需要暫時刪除容錯移轉群組,才能重新命名資料庫。
  • 系統資料庫不會複寫到容錯移轉群組中的次要實例。 因此,相依於系統資料庫 (例如伺服器登入和代理程式作業) 中物件的案例需要在次要執行個體上手動建立物件,並在主要執行個體上進行任何變更之後,手動保持同步。 唯一的例外是服務主要金鑰 (SMK) ,用於在建立容錯移轉群組期間自動複寫至次要實例的SQL 受管理執行個體。 不過,主要執行個體上的任何後續 SMK 變更都不會複寫至次要執行個體。 若要深入了解,請參閱如何啟用相依於系統資料庫中物件的案例
  • 如果其中任何一個群組位於實例集區中,就無法在實例之間建立容錯移轉群組。

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

您也可以使用 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-AzSqlDatabaseInstanceFailoverGroup 此命令會建立容錯移轉群組,並同時在主要和次要執行個體上註冊
Set-AzSqlDatabaseInstanceFailoverGroup 修改容錯移轉群組的設定
Get-AzSqlDatabaseInstanceFailoverGroup 擷取容錯移轉群組的設定
Switch-AzSqlDatabaseInstanceFailoverGroup 觸發容錯移轉群組容錯移轉至次要執行個體
Remove-AzSqlDatabaseInstanceFailoverGroup 移除容錯移轉群組

後續步驟