本文說明適用於 PostgreSQL 的 Azure 資料庫中的高可用性，其中包括 可用性區域 和 跨區域復原和商務持續性。 如需更多關於 Azure 可靠性的詳細概觀，請參閱 Azure 可靠性。
適用於 PostgreSQL 的 Azure 資料庫可提供高可用性，方法是在相同可用性區域 (區域性) 內或跨可用性區域 (區域備援) 佈建實際分隔的主要和待命複本。 此高可用性模型旨在確保提交的資料在故障期間永遠不會遺失。 在高可用性 (HA) 設定中，資料會同步認可到主要和待命伺服器。 此模型已經過設計，讓資料庫不會成為軟體架構中的單一失敗點。 如需高可用性和可用性區域支援的詳細資訊，請參閱可用性區域支援。
可用性區域支援
可用性區域 是每個 Azure 區域內的數據中心實體分隔群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。
適用於 PostgreSQL 的 Azure 資料庫支援 區域備援和區域模型 ，以進行高可用性設定。 這兩種高可用性設定都會啟用自動容錯移轉功能，可在計劃性和非計劃性事件發生期間不遺失任何資料。
區域備援。 區域備援高可用性會在不同的區域中，部署具有自動容錯移轉功能的備用複本。 區域備援提供最高層級的可用性，但您需要跨區域設定應用程式備援。 為此，當您想要避免可用性區域層級的失敗，並且可以接受跨可用性區域的延遲時，請選擇區域備援。 雖然由於同步複寫而對寫入和認可有一些延遲影響，但不會影響讀取查詢。 此影響特定於您的工作負載、您選取的 SKU 類型和區域。
您可以選擇主要和待命伺服器的區域和可用性區域。 待命複本會在與主要伺服器相同區域的所選可用性區域中進行佈建，並具有類似的計算、儲存體和網路設定。 資料檔案和交易記錄檔 （預先寫入記錄，也稱為 WAL） 會儲存在每個可用區域內的本機備援儲存 （LRS） 上，自動儲存 三個 資料複本。 區域備援設定可為主要和待命伺服器之間的整體堆疊提供實體隔離。
[區域備援] 選項僅適用於支援可用性區域的區域。
不支援區域備援：
可高載計算層
具有單一區域可用性的區域
區域性。 當您想要在具有最低網路延遲的單一可用性區域內達到最高層級的可用性時，請選擇區域性部署。 您可以選擇用來部署主要資料庫伺服器的區域和可用性區域。 待命複本會在與主要伺服器相同的可用性區域中自動進行佈建和管理，並具有類似的計算、儲存體和網路設定。 區域性設定可防止資料庫發生節點層級的失敗，並且可協助降低計劃性與非計劃性停機事件發生期間的應用程式停機時間。 主要伺服器中的資料以同步模式複寫到待命複本。 若主要伺服器發生任何中斷，伺服器會自動容錯移轉至待命複本。
區域性部署選項適用於所有可部署彈性伺服器的 Azure 區域。
備註
區域性部署模型和區域備援部署模型在架構上的行為都相同。 除非另有說明，否則下列各節中的各種討論皆適用於這兩者。
在入口網站中設定區域復原
您可以透過兩種方式設定高可用性 （HA）：區域備援 HA，將待命伺服器放置在不同的可用性區域中，以獲得最大的復原能力，或相同區域 HA，將待命伺服器部署在與主要伺服器相同的區域中，以將延遲降到最低。
為了簡化設定並確保區域復原，入口網站提供具有兩個單選按鈕的區域復原選項：已啟用和已停用。 選取 [已啟用] 會嘗試在不同的可用區域 （區域備援 HA 模式） 中建立待命伺服器。 如果區域不支援區域備援 HA，您可以改為選取後援核取方塊 (如下圖中醒目提示) 以啟用相同區域 HA。
當你選擇備援勾選框時，系統會在同一區域建立備用伺服器。 如果區域容量稍後有空，Azure 會通知你，讓你可以選擇使用 PITR 或讀取副本遷移到具區域冗餘的高可用性（HA）配置。 如果您未選取核取方塊，且區域容量無法使用，則 HA 啟用會失敗。 此設計會強制使用區域備援 HA 作為預設值，同時為相同區域 HA 提供受控後援，確保工作負載最終無需手動介入即可實現完整的區域復原能力。
高可用性功能
待命複本會部署在與主要伺服器相同的 VM 組態中，包括虛擬核心、儲存體和網路設定。
您可以為現有資料庫伺服器新增可用性區域支援。
您可以藉由停用高可用性來移除待命複本。
針對區域備援可用性，您可以選擇主要和待命資料庫伺服器的可用性區域。
停止、啟動和重新啟動等作業會在主要和待命資料庫伺服器上同時執行。
在區域備援和區域模型中，主要資料庫伺服器會定期執行自動備份。 同時，備用複本會持續將交易日誌歸檔在備份儲存體中。 如果該區域支援可用性區域，則備份資料會儲存在區域備援儲存體上 (ZRS)。 在不支援可用性區域的區域中，備份資料會儲存在本機備援儲存體 (LRS) 上。
用戶端一律會連線到主要資料庫伺服器的端點主機名稱。
伺服器參數的任何變更也會套用到待命複本。
您可以重新啟動伺服器以挑出任何靜態伺服器參數變更。
定期維護活動 (例如次要版本升級) 會先在待命伺服器上進行。 為了減少停機時間，待命節點會升級為主要節點，以便在進行剩餘節點的維護工作時，負載可以繼續運作。
備註
若要確保高可用性功能正確，請配置 max_replication_slots 和 max_wal_senders 伺服器參數值。 高可用性需要 4 個來處理容錯移轉和無縫升級。 若要建立高可用性架構，包含五個讀取副本和 12 個邏輯複製插槽，將兩者max_replication_slotsmax_wal_senders參數值設為 21。 此設定是必要的，因為每個讀取複本和邏輯複寫位置都需要 1 個，再加上高可用性正常運作所需的 4 個。 如需有關max_replication_slots和max_wal_senders參數的詳細資訊，請參閱文件。
監視高可用性健康情況
適用於 PostgreSQL 的 Azure 資料庫中的高可用性 （HA） 健康情況狀態監視，可讓您持續概觀已啟用 HA 的執行個體的健康情況和整備程度。 此監視功能會套用 Azure 的資源健康情況檢查 （RHC） 架構，以偵測可能影響資料庫容錯移轉整備或整體可用性的任何問題，並發出警示。 透過評估連線狀態、容錯移轉狀態和資料複製健康情況等關鍵指標，HA 健康狀態監控可以主動進行故障排除，並幫助維護資料庫的正常運行時間和效能。
使用 HA 健康狀態監控功能來：
- 即時深入瞭解主要和備用複本的健康情況，並透過狀態指示器顯示潛在問題，例如效能下降或網路封鎖。
- 設定警示，以便及時通知 HA 狀態的任何變更，以便您可以立即採取行動解決潛在的中斷問題。
- 藉由在問題影響資料庫作業之前將其識別並解決，來最佳化容錯移轉整備程度。
如需設定和解譯 HA 健康情況狀態的詳細指南，請參閱適用於 PostgreSQL 的 Azure 資料庫的高可用性 （HA） 健康情況狀態監視。
高可用性限制
由於同步複寫至待命伺服器，尤其是使用區域備援組態，應用程式可能會遇到增加的寫入及提交延遲。
您無法將備援複本用於進行讀取查詢。
視主要伺服器上的工作量及活動而定，故障轉移過程可能需要超過 120 秒的時間，因為待命副本必須先恢復，才能提升其地位。
待命伺服器通常會以每秒 40 MB 的速率復原 WAL 檔案。 對於較大的版本，此速率可以增加到 200 MB/s。 如果您的工作負載超過此限制，在容錯移轉期間或建立新待命複本之後，您完成復原的時間可能會延長。
重新啟動主要資料庫伺服器也會重新啟動待命複本。
您無法設定額外的備用系統。
您無法在受控維維護視窗期間排程客戶起始的管理工作。
計劃的事件，例如擴展計算和擴展儲存體，會先在待命伺服器上發生，然後在主要伺服器上發生。 伺服器目前不會針對這些計劃性作業進行容錯移轉。
如果你在支援 HA 的彈性伺服器上設定邏輯解碼或邏輯複寫：
- 在 PostgreSQL 16 和更早版本中，依預設，故障轉移之後不會保留待命伺服器上的邏輯複寫插槽。
- 若要確保邏輯複寫在容錯移轉後繼續運作，您必須啟用
pg_failover_slots延伸模組並設定支援設定，例如hot_standby_feedback = on。 - 從 PostgreSQL 17 開始，原生支援槽位同步處理。 如果您啟用正確的 PostgreSQL 組態 （
sync_replication_slots，hot_standby_feedback），則邏輯複寫插槽會在容錯移轉後自動保留，而且不需要擴充。 - 如需設定步驟和必要條件，請參閱 PG_Failover_Slots擴充功能 檔案。
不支援使用私人端點在私人 （虛擬網路） 和公用存取之間設定可用性區域。 您必須在虛擬網路內設定可用性區域（橫跨同一區域內的可用性區域），或者透過私人端點實現公用存取。
您只能在單一區域內設定可用性區域。 您無法跨區域設定可用性區域。
SLA
Zonal 模型提供大約 99.95% 的 SLA 可用時間。
區域冗餘模型為SLA提供約99.99%的正常運作時間。
建立已啟用可用性區域的適用於 PostgreSQL 的 Azure 資料庫
若要瞭解如何建立適用於 PostgreSQL 的 Azure 資料庫，以取得可用性區域的高可用性，請參閱 快速入門：在 Azure 入口網站中建立適用於 PostgreSQL 的 Azure 資料庫。
可用性區域重新部署和移轉
若要瞭解如何在區域備援和區域部署模型中啟用或停用彈性伺服器中的高可用性設定，請參閱 在彈性伺服器中管理高可用性。
高可用性元件和工作流程
交易完成
應用程式交易觸發的寫入和認可會先記錄到主要伺服器上的 WAL。 主要伺服器會使用 Postgres 串流通訊協定，將這些日誌串流至待命伺服器。 當待命伺服器儲存體持續記錄時，主要伺服器會確認寫入完成。 應用程式只有在確認之後才提交交易。 這種額外的來回行程會增加應用程式的延遲。 影響百分比取決於應用程式。 此通知程序不會等候待命伺服器套用記錄。 待命伺服器會保持在復原模式，直到升階為止。
健康檢查
彈性伺服器性能監視會定期檢查主要伺服器和待命伺服器的健康情況。 在多次 Ping 後，如果健康監控偵測到主要伺服器無法連線，服務會自動發起轉移至待命伺服器。 健康監控演算法使用多個資料點來避免誤報情況。
容錯移轉模式
彈性伺服器支援兩種容錯移轉模式，分別是計劃性容錯移轉和非計劃性容錯移轉。 在這兩種模式下，一旦複寫中斷，待命伺服器會在升級為主要伺服器前執行復原，並開啟讀寫模式。 當自動 DNS 項目更新為新的主要伺服器端點後，應用程式可以使用相同的端點連接到伺服器。 新的待命伺服器會在背景建立，讓應用程式可以維持連線能力。
高可用性狀態
系統會持續監視主要及待命伺服器的健全狀況。 它會採取適當的動作來修正問題，包括觸發容錯移轉至待命伺服器。 下表列出可能的高可用性狀態：
| 狀態 | 說明 |
|---|---|
| 正在初始化 | 正在建立新的待命伺服器。 |
| 正在複寫資料 | 待命伺服器在建立之後會趕上主要伺服器。 |
| 良好 | 複寫處於穩定狀態且狀況良好。 |
| 正在容錯移轉 | 資料庫伺服器正在容錯移轉至待命伺服器。 |
| 正在移除待命伺服器 | 正在刪除待命伺服器。 |
| 未啟用 | 未啟用高可用性。 |
備註
您可以在建立伺服器期間或稍後啟用高可用性。 如果您在建立後階段啟用或停用高可用性，請在主要伺服器活動較低時執行此動作。
穩定狀態作業
PostgreSQL 用戶端應用程式會使用資料庫伺服器名稱連線至主要伺服器。 主要伺服器直接回應應用程式讀取請求。 同時，應用程式只有在日誌資料在主要伺服器和待命複本上持久化之後才會接收到提交和寫入的確認。 由於此額外的往返，應用程式可以預期寫入和認可的延遲會增加。 您可以在入口網站上監視高可用性的健康情況。
- 用戶端會連線到彈性伺服器並執行寫入作業。
- 變更會複寫至待命站台。
- 主要伺服器接收通知。
- 寫入和認可已確認。
高可用性伺服器的時間點還原
對於配置為高可用性的彈性伺服器，系統會將日誌資料即時抄寫至待命伺服器。 主要伺服器上的任何使用者錯誤（例如意外刪除資料表或不正確的資料更新）都會複製至待命副本。 因此，您無法使用備援系統從此類邏輯錯誤中恢復。 若要從此類錯誤中復原，您必須從備份執行時間點還原。 透過使用彈性伺服器的時間點還原功能，您可以還原至錯誤發生之前的時間。 針對設定了高可用性的資料庫，新的資料庫伺服器會還原為單一區域彈性伺服器，並具有使用者所提供的新伺服器名稱。 您可以將還原的伺服器用於數個使用案例：
使用還原的伺服器進行產品環境運行，並選擇性地在相同區域或同一地區的另一個區域中啟用待命副本以實現高可用性。
如果您想要還原物件，請從還原的資料庫伺服器匯出物件，並將其匯入至生產資料庫伺服器。
如果您想要複製資料庫伺服器以供測試和開發之用，或想要針對任何其他用途進行還原，您可以執行時間點還原。
若要了解如何進行彈性伺服器的時間點還原，請參閱彈性伺服器時間點還原。
容錯移轉支援
計劃性容錯移轉
計劃性停機事件包括由 Azure 排定的定期軟體更新和次要版本升級。 您也可以使用計劃性容錯移轉，讓主要伺服器回到偏好的可用性區域。 當您配置高可用性時，這些作業會先套用至待命抄本，而應用程式會繼續存取主要伺服器。 一旦處理程序更新待命抄本，它就會清空主要伺服器連線，並觸發容錯移轉，以啟動待命抄本作為具有相同資料庫伺服器名稱的主要伺服器。 用戶端應用程式會以相同的資料庫伺服器名稱重新連接至新的主要伺服器，並可以回復其作業。 此程序會在與舊主要伺服器相同的區域中建立新的待命伺服器。
對於其他使用者起始的作業，例如縮放運算或縮放儲存，此程序會先在待命資料庫上套用變更，然後在主要資料庫上套用變更。 目前，服務不會容錯移轉至待命。 因此，當調整作業在主要伺服器上執行時，應用程式會遇到短暫的停機時間。
您也可以使用此功能來容錯移轉至待命伺服器，並縮短停機時間。 例如，您的主要伺服器在非計劃性容錯移轉之後，可能會位於與應用程式不同的可用性區域。 您想要讓主要伺服器回到先前的區域，以與應用程式共置。
當您執行此功能時，該進程首先準備備用伺服器以確保它趕上最近的事務，從而允許應用程式繼續執行讀取和寫入。 程序會促進備援狀態，並切斷與主要系統的連線。 您的應用程式可以繼續寫入主要伺服器，而程序會在背景建立新的待命伺服器。 下表說明計劃性容錯移轉所涉及的步驟：
| Step | 說明 | 應用程式是否預期會停機？ |
|---|---|---|
| 1 | 等待待命伺服器趕上主要伺服器。 | 否 |
| 2 | 內部監視系統會起始容錯移轉工作流程。 | 否 |
| 3 | 當待命伺服器接近主要伺服器的記錄序號 (LSN) 時，會封鎖應用程式寫入。 | Yes |
| 4 | 待命伺服器會升階成為獨立伺服器。 | Yes |
| 5 | DNS 記錄會以新待命伺服器的 IP 位址更新。 | Yes |
| 6 | 應用程式重新連線，並以新的主要伺服器繼續讀取/寫入。 | 否 |
| 7 | 新的待命伺服器會在另一個區域中建立。 | 否 |
| 8 | 待命伺服器會開始從 Azure Blob 復原其在建立期間遺漏的記錄。 | 否 |
| 9 | 主要伺服器與待命伺服器之間的穩定狀態會建立起來。 | 否 |
| 10 | 計劃性容錯移轉程序完成。 | 否 |
應用程式停機從步驟 3 開始，並在步驟 5 之後恢復作業。 其餘步驟會在背景中發生，不會影響應用程式寫入和認可。
小提示
使用彈性伺服器時，您可以選擇性地排程 Azure 主動進行的維護活動，方法是選擇一個您偏好的日子，在資料庫活動預期較少時，設定一個 60 分鐘的時段。 Azure 維護工作 （例如修補或次要版本升級） 會在該時段期間發生。 如果您未選擇自訂視窗，系統會為您的伺服器配置當地時間晚上 11 點到早上 7 點之間的一小時視窗。 針對設定了可用性區域的彈性伺服器，待命複本上也會執行這些 Azure 起始的維護活動。
如需可能的計劃性停機事件清單，請參閱計劃性停機事件。
非計劃性容錯移轉
由於底層硬體故障、網路問題和軟體錯誤等不可預見的中斷，可能會發生計劃外停機。 如果配置為高可用性的資料庫伺服器意外關閉，則處理程序會啟動待命抄本，用戶端可以回復其作業。 如果您未設定高可用性 （HA） ，且重新啟動嘗試失敗，則程序會自動佈建新的資料庫伺服器。 雖然無法避免計劃外停機，但彈性伺服器可自動執行復原作業，而不需要人工介入，以協助減輕停機時間。
如需非計劃性容錯移轉和停機的相關資訊，包括可能的案例，請參閱非計劃性停機風險降低。
容錯移轉測試 (強制容錯移轉)
透過強制容錯移轉，您可以模擬非計劃性中斷案例，同時執行生產工作負載，並觀察應用程式的停機時間。 當您的主要伺服器沒有回應時，您也可以使用強制容錯移轉。
強制容錯移轉會將主要伺服器關閉，並起始執行待命伺服器升階作業的容錯移轉工作流程。 一旦待命伺服器完成復原程序至上次認可的資料，待命伺服器就會升階為主要伺服器。 DNS 記錄會更新，而且您的應用程式可以連線到升階的主要伺服器。 您的應用程式可以在新的待命伺服器於背景建立時繼續寫入主要伺服器，不會影響到運作時間。
下表說明在強制故障移轉中所需執行的步驟：
| Step | 說明 | 應用程式是否預期會停機？ |
|---|---|---|
| 1 | 主要伺服器在收到切換請求後不久就停止。 | Yes |
| 2 | 由於主要伺服器關閉，應用程式會經歷停機時間。 | Yes |
| 3 | 內部監視系統偵測到失敗，並起始容錯移轉至待命伺服器。 | Yes |
| 4 | 待命伺服器會在完全升階為獨立伺服器之前進入復原模式。 | Yes |
| 5 | 容錯移轉程序會等候待命復原作業完成。 | Yes |
| 6 | 伺服器啟動後，該程序會更新 DNS 記錄，保留相同的主機名稱，但使用待命資料庫的 IP 位址。 | Yes |
| 7 | 應用程式可以重新連線到新的主要伺服器，並繼續作業。 | 否 |
| 8 | 系統會建立慣用區域中的待命伺服器。 | 否 |
| 9 | 待命伺服器會開始從 Azure Blob 復原其在建立期間遺漏的記錄。 | 否 |
| 10 | 主要伺服器與待命伺服器之間的穩定狀態會建立起來。 | 否 |
| 11 | 強制容錯移轉程序完成。 | 否 |
應用程式停機會在步驟 1 之後開始，一直持續到步驟 6 完成為止。 其餘步驟在會背景執行，不會影響應用程式寫入和認可。
這很重要
端對端容錯移轉流程包括 (a) 主要伺服器失敗後容錯移轉至待命伺服器和 (b) 建立處於穩定狀態的新待命伺服器。 由於在容錯移轉至待命伺服器的作業完成之前，您的應用程式都會停機，因此請從您的應用程式/用戶端視角衡量停機時間，而不是從整體的端對端容錯移轉流程來衡量。
執行強制故障轉移時的注意事項
整體端對端作業時間可能比應用程式實際經歷的停機時間更長。
這很重要
請一律從應用程式的觀點觀察停機時間！
請勿執行立即、連續的容錯移轉。 在兩次故障轉移之間至少等待 15-20 分鐘，以確保新的備援伺服器能夠完全建立。
在低活動期間執行強制容錯移轉，以減少停機時間。
容錯移轉後 PostgreSQL 統計資料的最佳做法
PostgreSQL 容錯移轉之後，維持最佳資料庫效能需要了解 pg_statistic 和 pg_stat_* 資料表的不同角色。 此 pg_statistic 表格會儲存最佳化工具統計資料，這對查詢規劃器至關重要。 這些統計資料包括資料內中的資料分佈，並在容錯移轉後保持不變，確保查詢規劃工具可以根據精確的歷程記錄資料分佈資訊，繼續有效地最佳化查詢執行。
相反地，記錄活動統計資料 (例如掃描數目、Tuple 讀取，以及更新) 的 pg_stat_* 資料表會在容錯移轉時重設。 這類資料表的範例是 pg_stat_user_tables，它其追蹤使用者定義資料表的活動。 此重設會準確反映新主要伺服器運行狀態，但也意味著會遺失可協助自動清空程式和其他作業效率的歷史活動指標。
考量這一區別，在 PostgreSQL 故障轉移後執行 ANALYZE 。 此動作會使用全新的活動統計資料來更新 pg_stat_* 資料表 (例如 pg_stat_user_tables)，協助自動資料清理流程並確保資料庫效能在其新角色中保持最佳狀態。 此主動式步驟彌合了保留基本最佳化工具統計資料與重新整理活動計量之間的差距，以符合資料庫的目前狀態。
區域關閉體驗
區域性：若要從區域層級失敗中復原，您可以使用備份執行時間點還原 (部分內容可能是機器或 AI 翻譯)。 您可以選擇時間最新的自訂還原點來還原最新資料。 新的彈性伺服器會部署在另一個未受影響的區域中。 還原所花費的時間取決於先前的備份，以及要復原的交易記錄量。
如需時間點還原的詳細資訊，請參閱適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器中的備份與還原。
區域冗餘：彈性伺服器會在 60-120 秒內自動容錯移轉至備用伺服器，且資料遺失為零。
沒有可用性區域的設定
您可以設定不啟用高可用性的彈性伺服器，但不建議這麼做。 對於配置無高可用性的彈性伺服器，此服務提供本地備援儲存，其中包含三份資料複本、在支援的區域內的區域備援備份，以及內建伺服器恢復能力，能自動重啟遭遇故障的伺服器，並將伺服器轉移至另一個實體節點。 此配置提供 99.9% 的正常運行時間服務等級協議。 在計劃性或非計劃性容錯移轉事件期間，如果伺服器關閉，服務會使用下列自動化程序來維護伺服器的可用性：
- 佈建新的計算 Linux VM。
- 將具有資料檔案的儲存體對應到新的虛擬機器。
- PostgreSQL 資料庫引擎會在新的虛擬機器上上線。
下圖顯示 VM 與儲存體故障之間的轉換。
跨區域災害復原和商務持續性
若發生區域性災難，Azure 可透過利用其他區域進行災難復原，提供區域性或大型地理災害的防護。 如需 Azure 災害復原架構的詳細資訊，請參閱 Azure 至 Azure 災害復原架構。
彈性伺服器提供的功能，可在計劃性和非計劃性停機事件期間保護關鍵任務資料庫的資料並減少停機時間。 建置在會提供強固恢復能力與可用性的 Azure 基礎結構之上，彈性伺服器可提供商務持續性功能，以提供錯誤保護、解決復原時間需求，以及降低資料外洩暴露風險。 當您架構應用程式時，請考慮停機容錯 - 復原時間目標 （RTO），以及資料遺失暴露 - 復原點目標 （RPO）。 例如，相較於測試資料庫，業務關鍵資料庫需要更嚴格的運作時間。
多區域地理的災害復原
異地備援備份和還原
異地備援備份和還原可讓您在發生災害時還原不同區域的伺服器。 這也提供在一年中至少 99.99999999999999% (16 個 9) 的備份物件持久性。
您只能在建立伺服器時設定異地備援備份。 當您使用異地備援備份來設定伺服器時，備份資料和交易記錄會透過儲存體複寫以非同步方式複製到配對區域。
如需異地備援備份和還原的詳細資訊，請參閱異地備援備份和還原。
讀取複本
您可以部署跨區域只讀複本以保護資料庫免受區域層級故障的影響。 讀取複本會使用 PostgreSQL 的實體複寫技術以非同步方式更新，而且可能會延遲主要複本。 一般用途和記憶體最佳化運算層支援讀取複本。
如需讀取複本功能和考量事項的詳細資訊，請參閱讀取複本。
中斷偵測、通知和管理
如果您使用異地備援備份來設定伺服器，則可以在配對區域中執行異地還原。 新伺服器會佈建並復原到最後一個複製到此區域的資料。
您也可以使用跨區域讀取複本。 如果發生區域故障，您可以將僅供讀取的複本提升為可獨立操作的讀寫伺服器，以執行災難復原作業。 RPO 預計最多為 5 分鐘（可能發生資料遺失），但若發生嚴重區域性故障，此時的 RPO 可能接近故障發生時的複寫延遲。
如需區域性災害後的非計劃性停機風險降低和復原詳細資訊，請參閱非計劃性停機風險降低。