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

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

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

容錯移轉群組功能可讓您管理受控執行個體中的所有使用者資料庫，以複寫和容錯移轉至另一個 Azure 區域。 本文提供容錯移轉群組功能的概觀，其中包含搭配 Azure SQL 受控執行個體使用此功能的最佳做法和建議。

若要開始使用此功能，請檢閱設定 Azure SQL 受控執行個體的容錯移轉群組。

概觀

容錯移轉群組功能可讓您管理受控執行個體中的所有使用者資料庫，以複寫和容錯移轉至另一個 Azure 區域中的受控執行個體。 容錯移轉群組旨在簡化異地複寫資料庫的大規模部署和管理。

如需詳細資訊，請參閱 Azure SQL 受控執行個體的高可用性。 如需異地容錯移轉的 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 區域，以防主要受控執行個體因為主要區域中斷而無法使用。 SQL 受控執行個體的容錯移轉群組包含該執行個體中的所有使用者資料庫，因此在一個執行個體上只能設定一個容錯移轉群組。

  重要

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

• 主要

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

• 次要

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

  重要

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

• 容錯移轉 (無資料遺失)

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

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

• 強制容錯移轉 (潛在資料遺失)

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

• 資料遺失的寬限期

  由於使用非同步複寫會將資料複寫至次要，因此具有 Microsoft 管理的容錯移轉原則的群組的強制容錯移轉可能會導致資料遺失。 您可以自訂容錯移轉原則，以反映應用程式對資料遺失的容錯程度。 藉由設定 GracePeriodWithDataLossHours，您可以控制 Azure SQL 服務在起始強制容錯移轉之前的等候時間，這會導致資料遺失。

• 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 屬性來為唯讀接聽程式啟用容錯移轉。 在該情況下，如果次要資料庫無法使用時，唯讀流量會自動重新導向到主要資料庫。

  注意

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

容錯移轉群組結構

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

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

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

建立異地次要執行個體

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

重要

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

如需在與主要執行個體相同的 DNS 區域中建立次要 SQL 受控執行個體的詳細資訊，請參閱設定 Azure SQL 受控執行個體的容錯移轉群組。

使用配對的區域

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

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

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

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

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

• 全域虛擬網路對等互連
• VPN 閘道
• Azure ExpressRoute

在容錯移轉群組中的兩個執行個體之間建立連線的建議方法，是全域虛擬網路對等互連 (VNet 對等互連)。 其會使用 Microsoft 骨幹基礎結構，在對等互連的虛擬網路之間提供低延遲、高頻寬的私人連線。 對等互連的虛擬網路之間所進行的通訊不需要公用網際網路、閘道或其他加密措施。

初始植入

在受控執行個體之間建立容錯移轉群組時，資料複寫開始之前會有初始植入階段。 初始植入階段這部分是最長且最昂貴的作業。 初始植入完成之後，資料就會進行同步，只複寫後續的資料變更。 初始植入完成所花費的時間取決於資料大小、複寫的資料庫數目、主資料庫上的工作負載強度，以及裝載主要和次要執行個體的虛擬網路之間的連結速度 (主要以連線方式為基礎) 而定。 在一般情況下，以及使用建議的全域虛擬網路對等互連建立連線時，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 服務可能不會受到中斷影響，且其元件可能仍可在該區域中使用。 主要資料庫切換至次要區域之後，相依元件之間的延遲會增加。 請確保次要區域中所有應用程式元件備援，並將應用程式元件與資料庫一起容錯移轉，以確保應用程式執行不會進一步受影響。

強制容錯移轉後資料可能遺失

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

DNS 更新

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

重要

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

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

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

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

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

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

例如，如果您計劃在次要執行個體上使用相同的登入，請務必使用相同的 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 程序呼叫所造成的延遲可能會相當明顯，且取決於呼叫時主要資料庫上尚未傳輸的交易記錄大小。

容錯移轉群組狀態

容錯移轉群組會報告其狀態，說明資料複寫的目前狀態：

• 正在植入：在建立容錯移轉群組之後，就會進行初始植入，直到在次要執行個體上初始化所有使用者資料庫為止。 當容錯移轉群組處於植入狀態時，無法起始容錯移轉程序，因為使用者資料庫尚未複製到次要執行個體。
• 正在同步處理：容錯移轉群組的一般狀態。 這表示主要執行個體上的資料變更會以非同步方式複寫至次要執行個體。 此狀態不保證資料會隨時完全同步處理。 由於容錯移轉群組中執行個體之間的複寫程序本身為非同步處理，可能會有來自主要執行個體的資料變更仍需要複寫至次要執行個體。 當容錯移轉群組處於同步狀態時，可以起始自動和手動容錯移轉。
• 正在進行容錯移轉：此狀態表示正在進行自動或手動起始的容錯移轉程序。 當容錯移轉群組處於此狀態時，無法起始容錯移轉群組或其他容錯移轉的變更。

容錯回復

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

功能互通性

備份

在下列案例中會進行完整備份：

• 在您建立容錯移轉群組時開始初始植入之前。
• 容錯移轉後。

完整備份是無法略過或延遲的資料操作大小，而且可能需要一些時間才能完成。 完成所需的時間取決於資料大小、資料庫數目，以及主資料庫上的工作負載強度。 完整備份可能會明顯延遲初始植入，而且可以在容錯移轉後不久延遲或防止新實例上的容錯移轉作業。

記錄重新執行服務

在執行完全移轉步驟之前，無法使用記錄重新執行服務（LRS）進行資料庫移轉至 Azure SQL 受控執行個體的資料庫無法新增至容錯移轉群組。 使用 LRS 的資料庫移轉處於還原狀態，直到完全移轉，且還原狀態的資料庫無法新增至容錯移轉群組。 嘗試建立具有還原狀態之資料庫的容錯移轉群組會延遲建立容錯移轉群組，直到資料庫還原完成為止。

異動複寫

支援搭配使用異動複寫與容錯移轉群組中的執行個體。 不過，如果您在將 SQL 受控執行個體新增至容錯移轉群組之前設定複寫，當您開始建立容錯移轉群組時，複寫會暫停，而複寫監視器會顯示 Replicated transactions are waiting for the next log backup or for mirroring partner to catch up 的狀態。 成功建立容錯移轉群組之後，複寫便會繼續。

如果發行者或經銷商 SQL 受控執行個體在容錯移轉群組中，則在發生容錯移轉之後，SQL 受控執行個體系統管理員必須在舊的主要資料庫上清除所有發行集，並在新的主要資料庫上重新設定。 請檢閱異動複寫指南，了解此案例中所需的活動步驟。

權限和限制

在設定容錯移轉群組之前檢閱權限和限制清單。

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

您也可以使用 Azure PowerShell、Azure CLI 和 REST API，以程式設計方式管理容錯移轉群組。 若要深入了解，請檢閱設定容錯移轉群組。

災害復原演練

執行 DR 切入的建議方式是使用手動容錯移轉，如下列教學課程所示：測試容錯移轉。

不建議使用強制容錯移轉執行切入，因為這項作業不會針對資料遺失提供防護。 不過，起始強制容錯移轉之前，確保符合下列條件，即可達到資料不遺失的強制容錯移轉：

• 主要受控執行個體上的工作負載已停止。
• 所有長時間執行的交易都已完成。
• 主要受控執行個體的所有用戶端連線都已中斷連線。
• 容錯移轉群組狀態為「正在同步處理」。

請確定兩個受控執行個體已切換角色，且容錯移轉群組狀態已從「進行中的容錯移轉」切換至「正在同步處理」，然後選擇性建立與新主要受控執行個體的連線，並開始讀寫工作負載。

若要對原始受控執行個體角色執行資料不遺失容錯回復，強烈建議使用手動容錯移轉，而不是強制容錯移轉。 若要繼續進行強制容錯回復：

• 請遵循與資料不遺失容錯移轉相同的步驟。
• 如果在初始強制容錯移轉完成之後不久執行強制容錯回復，容錯回復執行時間預期會比較長，因為它必須等候先前主要受控執行個體上未完成的自動備份作業完成。

相關內容

• 設定容錯移轉群組
• 使用 PowerShell，將受控執行個體新增至容錯移轉群組
• 為 Azure SQL 受控執行個體設定免授權待命複本
• 使用 Azure SQL 受控執行個體的商務持續性概觀 \(部分機器翻譯\)
• Azure SQL 受控執行個體中的自動化備份
• 從 Azure SQL 受控執行個體中的備份還原資料庫