共用方式為

使用中的地理複寫

  • 發行項

適用於： Azure SQL 資料庫

本文提供 Azure SQL 資料庫的作用中異地複寫功能的概觀，該功能可讓您持續將資料從主資料庫複寫至可讀取的次要資料庫。 可讀取的次要資料庫可能與主要資料庫位於同一 Azure 區域，但更常見的情況是，它們位於不同區域。 這種可讀取的次要資料庫也稱為異地次要資料庫或異地複本。

每個資料庫均已設定作用中異地複寫功能。 若要對資料庫群組執行容錯移轉，或如果您的應用程式需要穩定的連線端點，請考慮改用容錯移轉群組。

也可以透過作用中異地複寫移轉 SQL Database。

概觀

作用中異地複寫為商務持續性解決方案。 透過作用中異地複寫，在發生區域災害或大規模中斷時，您可以執行個別資料庫的快速災害復原。 設定異地複寫後，您就可以對不同 Azure 區域中的異地次要資料庫起始異地容錯移轉。 異地容錯移轉可透過應用程式以程式設計方式起始，或由使用者手動起始。

下圖說明使用作用中異地複寫之異地備援雲端應用程式的一般設定。

作用中異地復寫的圖表。

如果主要資料庫因為任何原因而失敗，您可以對其起始異地容錯移轉至次要資料庫。 當次要資料庫升級為主要角色時，所有其他次要資料庫都會自動連結到新的主要資料庫。

您可以使用下列任意方法來管理異地複寫並起始異地容錯移轉：

作用中異地複寫會利用 Always On 可用性群組技術，以非同步方式將主要複本上產生的交易記錄複寫到所有異地複本。 雖然次要資料庫可能會在某個指定時間點稍微落後主要資料庫，但是次要資料庫上的資料保證在交易上是一致的。 換句話說，未提交的交易所做的變更不會顯示。

注意

作用中異地複寫會將資料庫交易記錄檔從主要複本串流到次要複本，以複寫變更。 作用中異地複寫與異動複寫無關，後者會藉由在訂閱者上執行 DML (INSERT、UPDATE、DELETE) 命令來複寫變更。

異地複寫提供區域備援。 區域備援可讓應用程式從天然災害、災難性人為錯誤或惡意行為所造成的全部或部分 Azure 區域永久損失中快速復原。 您可以在Azure SQL 資料庫的商務持續性概觀中找到異地複寫的 RPO。

下圖顯示的作用中異地複寫範例，其設定是以美國西部 2 區域為主要資料庫，而以美國東部區域為異地次要資料庫。

顯示 SQL DB 異地複寫關聯性的 Azure 入口網站的螢幕擷取畫面。

除了災害復原之外，作用中異地複寫還可用於下列案例︰

  • 資料庫移轉：您可以使用作用中異地複寫，以最少的停機時間將資料庫從一部伺服器移轉到另一個伺服器。
  • 應用程式升級：您可以在應用程式升級期間建立額外的次要資料庫做為容錯回復複本。

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

術語和功能

  • 自動非同步複寫

    您只能為現有資料庫建立異地次要資料庫。 除了含有主要資料庫的伺服器以外，您可以在任何邏輯伺服器上建立異地次要資料庫。 一旦建立之後，就會使用主要資料庫的資料填入異地次要複本。 這個程序稱為植入。 建立並植入異地次要複本之後，主要資料庫的更新會以非同步方式自動複寫到異地次要複本。 非同步複寫表示交易要先在主要資料庫上提交後才能複寫。

  • 可讀取的異地次要複本

    應用程式可以存取異地次要複本，利用存取主要資料庫所用的相同安全性主體或不同安全性主體來執行唯讀查詢。 如需詳細資訊，請參閱使用唯讀複本對唯讀查詢工作負載進行卸載。

    重要

    您可以使用異地複寫在主要複本的相同區域中建立次要複本。 您可以使用這些次要複本來滿足相同區域中的讀取縮放案例。 不過，相同區域中的次要複本並無法提供嚴重故障或大規模中斷的額外復原能力，因此不適合用於災害復原用途的容錯移轉目標。 它也無法保證可用性區域隔離。 若要達成可用性區域隔離，請使用商務關鍵或進階服務層級的區域備援設定，或一般用途服務層級的區域備援設定。

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

    容錯移轉會在完成完整資料同步處理之後，切換主要資料庫和異地次要資料庫的角色。 計畫性異地容錯移轉的持續時間，取決於主要資料庫上需要同步處理至異地次要資料庫的交易記錄大小。 容錯移轉是針對下列案例所設計：

    • 在不容許資料遺失的情況下，於實際執行中執行 DR 演練
    • 將資料庫重新放置到不同的區域
    • 在中斷情況趨緩 (亦即容錯回復) 後，將資料庫傳回到主要區域。

  • 強制容錯移轉 (資料可能遺失)

    強制異地容錯移轉會立即將異地次要資料庫切換為主要角色，無需等待與主要資料庫進行任何同步處理。 主要資料庫上已認可但尚未複寫至次要資料庫的任何交易都會遺失。 當無法存取主要資料庫但仍必須快速還原資料庫可用性時，這項作業就是針對這類中斷的復原方法。 當原始的主要資料庫重新上線時，系統便會自動重新連線、使用主要資料庫中的最新資料重新植入，並成為新的異地次要資料庫。

    重要

    容錯移轉或強制容錯移轉完成之後，新的主要資料庫的連線端點會變更，因為新的主要資料庫現已位於不同的邏輯伺服器上。

  • 多個可讀取的異地次要資料庫

    一個主要資料庫最多可以建立四個異地次要資料庫。 如果只有一個次要資料庫，而該資料庫出現故障，在新的次要資料庫建立之前，應用程式會暴露在更高的風險中。 如果有多個次要資料庫存在，即使其中一個次要資料庫故障，應用程式仍會受到保護。 其他的次要資料庫也可用來縮放唯讀工作負載。

    提示

    如果您使用作用中異地複寫建置分散在世界各地的應用程式，而且必須在四個以上區域中提供資料的唯讀存取，則可以建立次要資料庫的次要資料庫 (亦即鏈結程序) 來建立額外的異地複本。 相較於直接連線至主要資料庫的異地複本，鏈結的異地複本複寫延遲可能會較高。 僅支援以程式設計的方式設定鏈結異地複寫拓撲，而不能透過 Azure 入口網站進行。

  • 彈性集區中的資料庫異地複寫

    每個異地次要資料庫可以是單一資料庫或彈性集區中的資料庫。 每個異地次要資料庫的彈性集區選擇都是分開的，而且不會依賴拓撲中任何其他複本的設定 (不論主要或次要)。 每個彈性集區都包含在單一邏輯伺服器內。 由於邏輯伺服器上的資料庫名稱必須是唯一，因此同一個主要資料庫的多個異地次要資料庫絕對不會共用彈性集區。

  • 使用者控制的異地容錯移轉和容錯回復

    一旦異地次要資料庫已完成初始植入，即可隨時由應用程式或使用者明確切換至主要角色 (容錯移轉)。 在中斷並無法存取主要複本期間，只能使用強制容錯移轉，這會立即將異地次要資料庫升階為新的主要資料庫。 當中斷緩解時，系統會自動將復原的主要資料庫設為異地次要資料庫，並使用新的主要資料庫來保持其最新狀態。 由於異地複寫的非同步本質，如果主要資料庫故障，而最近的交易尚未複寫到異地次要資料庫，則這些交易可能會在強制容錯移轉期間遺失。 當具有多個異地次要資料庫的主要資料庫容錯移轉時，系統會自動重新設定複寫關聯性，並且將剩餘的異地次要資料庫連結至新升級的主要資料庫，而不需要任何使用者介入。 緩解造成異地容錯移轉的中斷之後，可以讓主要資料庫回到其原始區域。 為此，請執行手動容錯移轉。

  • 待命複本

    如果您的次要複本僅用於災害復原 (DR)，而且沒有任何讀取或寫入工作負載，您可以將複本指定為待命，從而節省授權成本。

準備進行異地容錯移轉

為確保應用程式可以在異地容錯移轉之後立即存取新的主要資料庫，請驗證是否已正確設定次要伺服器的驗證和網路存取。 如需詳細資訊，請參閱建立和管理 Azure SQL Database 安全性以供異地還原或容錯移轉使用。 此外，也請確認次要資料庫上的備份保留原則與主要資料庫的備份保留原則相符。 這項設定不是資料庫的一部分，因此不會從主要資料庫複寫。 根據預設，異地次要資料庫會將 PITR 的保留期限預設為 7 天。 如需詳細資訊，請參閱Azure SQL 資料庫中的自動備份。

重要

如果資料庫是容錯移轉群組的成員，則無法使用異地複寫容錯移轉命令起始其容錯移轉。 請使用群組的容錯移轉命令。 如果需要容錯移轉個別的資料庫，您必須先將它從容錯移轉群組中移除。 如需詳細資料，請參閱容錯移轉群組。

設定異地次要資料庫

主要資料庫和異地次要資料庫必須有相同的服務層級。 此外，強烈建議您將異地次要資料庫設為與主要資料庫使用相同的備份儲存體備援、計算層級 (已佈建或無伺服器) 和計算大小 (DTU 或虛擬核心)。 如果主要資料庫遇到大量寫入工作負載，則計算大小較低的異地次要資料庫可能會跟不上。 這會導致異地次要資料庫的複寫延隔時間，最後可能會導致異地次要資料庫無法使用。 為了緩解這些風險，作用中異地複寫會在必要時降低 (節流) 主要資料庫的交易記錄速率，以讓其次要資料庫跟上速度。

如果異地次要資料庫的設定不平衡，還有一個後果，就是在容錯移轉之後，應用程式效能可能會因為新的主要資料庫計算容量不足而受到影響。 在這種情況下，您必須將資料庫擴大為具有足夠的資源，過程可能需要很長的時間，而在擴大程序結束時還必須進行高可用性容錯移轉，其可能會中斷應用程式工作負載。

如果您決定以不同的設定建立異地次要資料庫，應該花一段時間監視主要資料庫的記錄 IO 速率。 這可讓您估計維持複寫負載所需的異地次要資料庫最小計算大小。 例如，如果主要資料庫是 P6 (1000 DTU)，而其記錄 IO 百分比維持在 50%，則異地次要資料庫必須至少是 P4 (500 DTU)。 若要擷取歷程記錄 IO 資料，請使用 sys.resource_stats 檢視。 若要以較高細微性擷取最近的記錄 IO 資料，以更精確反映短期尖峰，請使用 sys.dm_db_resource_stats 檢視。

提示

在下列情況下，可能會發生交易記錄 IO 節流：

  • 如果異地次要資料庫的計算大小低於主要資料庫。 在 sys.dm_exec_requests 和 sys.dm_os_wait_stats 資料庫檢視中尋找 HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO 等候類型。
  • 與計算大小無關的原因。 如需詳細資料，包括不同類型記錄 IO 節流的等候類型，請參閱交易記錄速率控管。

根據預設，異地次要資料庫的備份儲存體備援會與主要資料庫相同。 您可以選擇使用不同的備份儲存體備援設定異地次要資料庫。 備份一律會在主要資料庫上執行。 如果次要資料庫設定了不同的備份儲存體備援，則在異地容錯移轉之後，當異地次要資料庫升級為主要資料庫時，新備份將會根據新主要資料庫 (先前的次要資料庫) 上選取的儲存體類型 (RA-GRS、ZRS、LRS) 來儲存和計費。

使用待命複本節省成本

如果您的次要複本僅用於災害復原 (DR)，而且沒有任何讀取或寫入工作負載，您可以在設定新的作用中異地複寫關聯圖時指定待命資料庫，從而節省授權成本。

更多相關資訊，請檢閱無授權待命複本。

跨訂閱異地複寫

  • 只要兩個訂用帳戶都位於相同的 Microsoft Entra 租用戶中，您就可以使用 Azure 入口網站來設定訂用帳戶之間的作用中異地複寫。

    • 若要在不同的 Microsoft Entra 租用戶中，在不同於主要複本的訂用帳戶的訂用帳戶中建立異地次要複本，請使用 SQL 驗證和 T-SQL。 當邏輯伺服器位於不同的 Azure 租用戶中時，不支援跨訂用帳戶異地複寫的 Microsoft Entra 驗證
    • 跨訂用帳戶異地複寫作業 (包括設定與異地容錯移轉) 也支援使用資料庫建立或更新 REST API。

  • 如果主要或次要邏輯伺服器上啟用僅限 Microsoft Entra 驗證並使用 Microsoft Entra ID 使用者嘗試建立，則不支援在相同或不同的 Azure 租用戶的邏輯伺服器上建立跨訂用帳戶異地次要資料庫。

如需方法和逐步指示，請參閱教學課程：設定作用中異地複寫和容錯移轉 (Azure SQL 資料庫)。

私人端點

透過私人端點連接到主要伺服器時，則不支援使用 T-SQL 新增異地次要資料庫。

  • 如果已設定私人端點，但允許公用網路存取，即可支援在透過公用 IP 位址連線到主要伺服器的情況下新增異地次要資料庫。
  • 一旦新增異地次要資料庫，就可拒絕公用網路存取。

保持認證和防火牆規則同步

使用公用網路存取來連接資料庫時，建議針對異地複寫資料庫使用資料庫層級 IP 防火牆規則。 這些規則會與資料庫一起複寫，以確保所有異地次要資料庫都有與主要資料庫相同的 IP 防火牆規則。 使用此方法時，客戶不需要針對裝載主要和次要資料庫的伺服器，手動設定及維護其中的防火牆規則。 同樣地，使用自主資料庫使用者進行資料存取時，可確保主要和次要資料庫兩者一律具有相同的驗證認證。 如此一來，在異地容錯移轉之後，就不會因為驗證認證不符合而中斷。 如果您正在使用登入和使用者 (而非自主使用者) 方式，則必須採取額外步驟以確保次要資料庫中有相同的登入。 如需設定的詳細資訊，請參閱建立和管理 Azure SQL Database 安全性以供異地還原或容錯移轉使用。

縮放主要資料庫

您可以將主要資料庫擴大或縮小至不同的計算大小 (在相同的服務層級內)，而不需要中斷任何異地次要資料庫的連線。 擴大時，建議先擴大異地次要資料庫，再擴大主要資料庫。 縮小時，則反轉順序：先縮小主要資料庫，再縮小次要資料庫。

如需容錯移轉群組的相關資訊，請檢閱在容錯移轉群組中調整複本。

防止重要資料遺失

由於廣域網路有高度延遲情況，因此異地複寫會採用非同步複寫機制。 如果主要資料庫故障，則非同步複寫無可避免會遺失一些資料。 若要保護重要交易資料不要遺失，應用程式開發人員可以在認可交易後立即呼叫 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 程序呼叫所造成的延遲可能會相當明顯，且取決於呼叫時主要資料庫上尚未傳輸的交易記錄大小。

監視異地複寫延隔時間

若要監視 RPO 相關的延隔時間，請使用主要資料庫上 sys.dm_geo_replication_link_status 的 replication_lag_sec 資料行。 它會顯示主要資料庫上認可交易之間的延隔時間 (以秒為單位)，並將其強行寫入次要資料庫上的交易記錄。 例如，如果延隔時間是一秒，這表示如果主要資料庫在這段時間受到中斷的影響並起始異地容錯移轉，則在上一秒認可的交易將會遺失。

若要測量已強行寫入異地次要資料庫上的主要資料庫變更延隔時間，請將異地次要資料庫上的 last_commit 時間與主要資料庫上的相同值進行比較。

提示

如果主要資料庫上的 replication_lag_sec 為 Null，則表示主要資料庫目前不知道異地次要資料庫落後的情況。 這通常會在程序重新啟動後發生，而且應該是暫時性狀況。 如果 replication_lag_sec 在一段較長的時間傳回 Null，請考慮傳送警示。 這可能表示異地次要資料庫因為連線失敗，而無法與主要資料庫通訊。

此外，有些情況可能也會造成異地次要資料庫上的 last_commit 時間與主要資料庫之間的差異變大。 例如，如果主要資料庫在很長一段時間未變更的情況下做出認可，則差異會先跳到較大值之後才會快速歸零。 如果這兩個值之間的差異一直都很大，請考慮傳送警示。

以程式設計方式管理作用中異地複寫

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

重要

這些 T-SQL 命令僅適用於作用中異地複寫，不適用於容錯移轉群組。

Command 描述
ALTER DATABASE 使用 ADD SECONDARY ON SERVER 引數，為現有資料庫建立次要資料庫並開始資料複寫
ALTER DATABASE 使用 FAILOVER 或 FORCE_FAILOVER_ALLOW_DATA_LOSS，將次要資料庫切換為主要資料庫以起始容錯移轉
ALTER DATABASE 使用 REMOVE SECONDARY ON SERVER 來終止 SQL Database 和指定次要資料庫之間的資料複寫。
sys.geo_replication_links 針對伺服器上的每個資料庫，傳回所有現有複寫連結的資訊。
sys.dm_geo_replication_link_status 針對指定的資料庫，取得上次複寫時間、上次複寫延隔時間，以及複寫連結的其他資訊。
sys.dm_operation_status 顯示所有資料庫作業的狀態，包括複寫連結的變更。
sys.sp_wait_for_database_copy_sync 讓應用程式等候，直到所有認可的交易都強行寫入異地次要資料庫的交易記錄為止。

相關內容

設定作用中異地複寫

其他商務持續性內容：