本文提供 Azure SQL Database 的作用中異地復寫功能概觀，可讓您持續將數據從主資料庫複寫至可讀取的輔助資料庫。 可讀取的次要資料庫可能與主要資料庫位於同一 Azure 區域，但更常見的情況是，它們位於不同區域。 這種可讀取的次要資料庫也稱為異地次要資料庫或異地複本。
每個資料庫均已設定作用中異地複寫功能。 若要故障轉移資料庫群組，或如果您的應用程式需要穩定的連線端點，請考慮改用 故障轉移群組 。
您也可以 使用主動式異地複寫來移轉 SQL 資料庫。
概觀
作用中異地複寫為商務持續性解決方案。 透過作用中異地複寫，在發生區域災害或大規模中斷時，您可以執行個別資料庫的快速災害復原。 設定異地複寫後，您就可以對不同 Azure 區域中的異地次要資料庫起始異地容錯移轉。 異地容錯移轉可透過應用程式以程式設計方式起始，或由使用者手動起始。
下圖說明使用作用中異地複寫之異地備援雲端應用程式的一般設定。
如果主要資料庫因為任何原因而失敗，您可以對其起始異地容錯移轉至次要資料庫。 當次要資料庫升級為主要角色時，所有其他次要資料庫都會自動連結到新的主要資料庫。
您可以使用下列任意方法來管理異地複寫並起始異地容錯移轉：
主動式異地復寫會使用 Always On 可用性群組 技術，以異步方式將主要複本上產生的事務歷史記錄複寫到所有異地複本。 雖然次要資料庫可能會在某個指定時間點稍微落後主要資料庫，但是次要資料庫上的資料保證在交易上是一致的。 換句話說，未提交的交易所做的變更不會顯示。
注意
作用中異地複寫會將資料庫交易記錄檔從主要複本串流到次要複本，以複寫變更。 這與 事務複製無關，它會藉由在訂閱者上執行 DML （INSERT、UPDATE、DELETE） 命令來復寫變更。
異地複寫提供區域備援。 區域備援可讓應用程式從天然災害、災難性人為錯誤或惡意行為所造成的全部或部分 Azure 區域永久損失中快速復原。 異地復寫 RPO 可在 使用 Azure SQL Database 的商務持續性總覽中找到。
下圖顯示的作用中異地複寫範例，其設定是以美國西部 2 區域為主要資料庫，而以美國東部區域為異地次要資料庫。
除了災害復原之外，作用中異地複寫還可用於下列案例︰
- 資料庫移轉：您可以使用主動式異地複寫，將資料庫從一部伺服器移轉至另一部伺服器，並縮短停機時間。
- 應用程式升級：您可以在應用程式升級期間建立額外的次要複本作為容錯回復複本。
若要實現完整的商務持續性，新增資料庫區域備援只是解決方案的一部分。 在災難性失敗後要端對端復原應用程式 (服務) 需要復原構成服務的所有元件和任何相依的服務。 這些元件的範例包括用戶端軟體 (例如自訂 JavaScript 的瀏覽器)、web 前端、儲存體和 DNS。 所有元件都必須對相同的失敗具有恢復功能，並且在應用程式的復原時間目標 (RTO) 內可供使用。 因此，您需要識別所有相依服務並了解其提供的保證與功能。 然後，您必須採取適當步驟以確保服務功能在它所依賴的服務容錯移轉期間都正常。 如需設計災害復原解決方案的詳細資訊，請參閱 使用 Azure SQL Database 設計全域可用的服務。
術語和功能
自動異步複寫
您只能為現有資料庫建立異地次要資料庫。 除了含有主要資料庫的伺服器以外，您可以在任何邏輯伺服器上建立異地次要資料庫。 一旦建立之後，就會使用主要資料庫的資料填入異地次要複本。 這個程序稱為植入。 建立並植入異地次要複本之後，主要資料庫的更新會以非同步方式自動複寫到異地次要複本。 非同步複寫表示交易要先在主要資料庫上提交後才能複寫。
可讀取的地理次要副本
應用程式可以存取異地次要複本，利用存取主要資料庫所用的相同安全性主體或不同安全性主體來執行唯讀查詢。 如需詳細資訊，請參閱 使用只讀複本卸除只讀查詢工作負載。
容錯轉移（沒有資料遺失）
容錯移轉會在完成完整資料同步處理之後，切換主要資料庫和異地次要資料庫的角色。 計畫性異地容錯移轉的持續時間，取決於主要資料庫上需要同步處理至異地次要資料庫的交易記錄大小。 容錯移轉是針對下列案例所設計：
- 在不容許資料遺失的情況下，於實際執行中執行 DR 演練
- 將資料庫重新放置到不同的區域
- 在中斷情況趨緩 (亦即容錯回復) 後，將資料庫傳回到主要區域。
強制切換（可能資料遺失）
強制異地容錯移轉會立即將異地次要資料庫切換為主要角色，無需等待與主要資料庫進行任何同步處理。 主要資料庫上已認可但尚未複寫至次要資料庫的任何交易都會遺失。 當無法存取主要資料庫但仍必須快速還原資料庫可用性時，這項作業就是針對這類中斷的復原方法。 當原始的主要資料庫重新上線時，系統便會自動重新連線、使用主要資料庫中的最新資料重新植入，並成為新的異地次要資料庫。
重要
容錯移轉或強制容錯移轉完成之後，新的主要資料庫的連線端點會變更，因為新的主要資料庫現已位於不同的邏輯伺服器上。
多個可讀取的地理備援次節點
一個主要資料庫最多可以建立四個異地次要資料庫。 如果只有一個次要資料庫，而該資料庫出現故障，在新的次要資料庫建立之前，應用程式會暴露在更高的風險中。 如果有多個次要資料庫存在，即使其中一個次要資料庫故障，應用程式仍會受到保護。 其他的次要資料庫也可用來縮放唯讀工作負載。
提示
如果您使用作用中異地複寫建置分散在世界各地的應用程式，而且必須在四個以上區域中提供資料的唯讀存取，則可以建立次要資料庫的次要資料庫 (亦即鏈結程序) 來建立額外的異地複本。 相較於直接連線至主要資料庫的異地複本，鏈結的異地複本複寫延遲可能會較高。 僅支援以程式設計的方式設定鏈結異地複寫拓撲，而不能透過 Azure 入口網站進行。
彈性集區中資料庫的異地複寫
每個異地次要資料庫可以是單一資料庫或彈性集區中的資料庫。 每個異地次要資料庫的彈性集區選擇都是分開的，而且不會依賴拓撲中任何其他複本的設定 (不論主要或次要)。 每個彈性集區都包含在單一邏輯伺服器內。 由於邏輯伺服器上的資料庫名稱必須是唯一，因此同一個主要資料庫的多個異地次要資料庫絕對不會共用彈性集區。
使用者控制的異地故障轉移和復原
一旦異地次要資料庫已完成初始植入，即可隨時由應用程式或使用者明確切換至主要角色 (容錯移轉)。 在中斷並無法存取主要複本期間，只能使用強制容錯移轉，這會立即將異地次要資料庫升階為新的主要資料庫。 當中斷緩解時，系統會自動將復原的主要資料庫設為異地次要資料庫，並使用新的主要資料庫來保持其最新狀態。 由於異地複寫的非同步本質，如果主要資料庫故障，而最近的交易尚未複寫到異地次要資料庫，則這些交易可能會在強制容錯移轉期間遺失。 當具有多個異地次要資料庫的主要資料庫容錯移轉時，系統會自動重新設定複寫關聯性，並且將剩餘的異地次要資料庫連結至新升級的主要資料庫，而不需要任何使用者介入。 緩解造成異地容錯移轉的中斷之後，可以讓主要資料庫回到其原始區域。 為此，請執行手動容錯移轉。
待命複本
如果您的次要複本 僅用於 災害復原（DR），而且沒有任何讀取或寫入工作負載，您可以將複本指定為 待命 複本，以節省授權成本。
準備進行異地容錯移轉
為確保應用程式可以在異地容錯移轉之後立即存取新的主要資料庫，請驗證是否已正確設定次要伺服器的驗證和網路存取。 如需詳細資訊，請參閱 設定及管理異地還原或故障轉移的 Azure SQL Database 安全性。 此外，也請確認次要資料庫上的備份保留原則與主要資料庫的備份保留原則相符。 這項設定不是資料庫的一部分，因此不會從主要資料庫複寫。 根據預設，異地次要資料庫會將 PITR 的保留期限預設為 7 天。 如需詳細資訊，請參閱 Azure SQL Database 中的自動備份。
重要
如果資料庫是容錯移轉群組的成員，則無法使用異地複寫容錯移轉命令起始其容錯移轉。 請使用群組的容錯移轉命令。 如果需要容錯移轉個別的資料庫，您必須先將它從容錯移轉群組中移除。 如需詳細資訊，請參閱 故障轉移群組 。
設定異地次要資料庫
主要資料庫和異地次要資料庫必須有相同的服務層級。 也強烈建議地理輔助設定為與主要資料庫相同的備援存儲冗餘、計算層（已布建或伺服器無需）及計算大小（資料庫事務單元或虛擬核心）。 如果主要資料庫遇到大量寫入工作負載，則計算大小較低的異地次要資料庫可能會跟不上。 這會導致異地次要資料庫的複寫延隔時間，最後可能會導致異地次要資料庫無法使用。 為了緩解這些風險，作用中異地複寫會在必要時降低 (節流) 主要資料庫的交易記錄速率，以讓其次要資料庫跟上速度。
如果異地次要資料庫的設定不平衡，還有一個後果，就是在容錯移轉之後，應用程式效能可能會因為新的主要資料庫計算容量不足而受到影響。 在此情況下，必須相應擴展資料庫以確保擁有足夠的資源，這可能會耗費大量時間，而且在相應增加的過程結束時需要進行高可用性故障轉移，這可能會中斷應用程式的工作負載。
如果您決定以不同的設定建立異地次要資料庫，應該花一段時間監視主要資料庫的記錄 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 驗證，且嘗試由 Microsoft Entra ID 使用者進行建立，則不支援建立跨訂用帳戶的異地次要伺服器。
如需方法和逐步指示，請參閱教學課程：設定作用中的異地復寫和故障轉移（Azure SQL Database）。
私人端點
透過 私人端點連線到主伺服器時，無法使用 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_statusreplication_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 Database REST API 和 Azure PowerShell Cmdlet。 這些 API 支援 Azure 角色型存取控制 (Azure RBAC)。 如需如何實作存取角色的詳細資訊，請參閱 Azure 角色型訪問控制（Azure RBAC）。
重要
這些 T-SQL 命令僅適用於作用中異地複寫，不適用於容錯移轉群組。
| 指令 | 描述 |
|---|---|
| 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 | 讓應用程式等候，直到所有認可的交易都強行寫入異地次要資料庫的交易記錄為止。 |
相關內容
設定作用中異地複寫
其他商務持續性內容：