你可以在與主伺服器相同的區域建立讀取副本，或是在不同的地理區域。 地理複製對於災難復原規劃或將資料更接近使用者等情境非常有幫助。
您可以在任何 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器服務區域中擁有主要伺服器。 主伺服器也可以在支援 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器的 Azure 全球區域設置副本。 此外，該服務支援由 21Vianet 主權雲運作的 Azure Government 與 Microsoft Azure 區域。
用於災害復原目的的配對區域
你可以在任何支援的區域建立副本，但當你選擇位於配對的 Azure 區域中的副本時，會獲得顯著的好處，尤其是在為災害復原進行架構設計時：
區域復原順序：當整個地理區域發生中斷時，會優先復原每組配對中的其中一個區域。 此優先權確保成對區域間的應用程式總有區域被加速恢復。
順序更新：成對區域的更新會按時間錯開進行，降低因更新相關問題而導致的停機風險。
資料駐留：除少數例外，成對集合中的區域位於同一地理範圍內，因此符合資料駐留要求。
效能：雖然配對區域通常提供低網路延遲，提升資料可及性與使用者體驗，但它們不一定是絕對最低延遲的區域。 若主要目標是將資料提供更貼近使用者，而非優先處理災難復原，請評估所有可用區域的延遲情況。 在某些情況下，非配對區域可能會表現出最低的延遲。 如需全面了解，您可以參考 Azure 的來回延遲資料來做出明智的選擇。
如需更深入了解配對區域的優勢，請參閱 Azure 跨區域複寫的文件。
區域性失敗與復甦
不同區域的 Azure 設施都經過精心設計且高度可靠。 然而，在極少數的情況下，由於網路失敗到自然災害等嚴重案例，導致整個區域可能會變得無法存取。 Azure 的功能允許你建立分散在多個區域的應用程式，確保一個區域的故障不會影響其他區域。
為區域災害做準備
為潛在的區域災害做好準備，對於確保應用程式和服務的不間斷作業至關重要。 如果您正在考慮為您的 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器制定完善的應變計畫，請考慮以下關鍵步驟與考量：
- 建立異地複寫的讀取複本：在與主要伺服器不同的區域中設定唯讀複本。 此配置確保在主要區域中斷時保持連續性。
-
確保伺服器對稱性：處理區域性故障最推薦的做法是 升級到主伺服器，但這會要求伺服器 對稱 性。 此要求意味著主伺服器與複本伺服器必須擁有相同的特定設定配置。 使用此動作的優點包括：
- 如果您使用虛擬端點，就不需要修改應用程式連接字串。
- 它提供順暢的復原程序，一旦受影響的區域重新上線，則原始主要伺服器就會自動恢復其功能，但會扮演新的複本角色。
- 設定虛擬端點：如果發生中斷，虛擬端點可讓您順暢地將應用程式轉換至另一個區域。 它們無需對應用程式連接字串進行任何變更。
- 設定讀取複本：並非所有來自主要伺服器的設定都會複寫到讀取複本。 確保您在讀取複本上適當設定所有必要的組態和功能 (例如 PgBouncer)。 如需詳細資訊，請參閱組態管理一節。
- 準備高可用性 (HA)：如果您的設定需要高可用性，升級複本不會自動啟用高可用性。 準備好在提升之後加以啟用。 請考慮自動執行此步驟以將停機時間降到最低。
- 定期測試：定期模擬區域災害案例，以驗證現有的臨界值、目標和設定。 確保應用程式在這些測試案例中如預期般做出回應。
- 遵循 Azure 的一般指引：Azure 提供可靠性和災害準備的完整指引。 請參考這些資源，並將最佳實務融入你的準備計畫中。
主動準備區域災難，能確保應用程式與資料的韌性與可靠性。
當服務中斷影響 SLA 時
若特定區域內適用於 PostgreSQL 的 Azure 資料庫靈活伺服器發生長時間停機，威脅到您的應用程式服務水準協議（SLA），請注意，以下節中討論的兩項行動並非以服務為導向。 這兩種操作都需要使用者介入。 盡可能自動化整個流程，並建立強健的監控。 如需在中斷期間會提供哪些資訊的詳細資訊，請參閱服務中斷頁面。 在發生區域中斷時，只能進行強制提升，這表示資料遺失的數量大致等於複本與主要伺服器之間的目前延隔時間。 因此，監視延隔時間至關重要。 請考慮下列選項：
提升至主要伺服器
只要你設定虛擬端點，這個選項就不需要更新應用程式中的連線字串。 啟用後，寫入端點會重新指向不同區域的新主節點，Azure 入口網站的複寫狀態欄位會顯示「重新配置中」。 一旦受影響區域恢復，原本的主要伺服器會自動恢復，但現在會以副本身份運作。
提升至獨立伺服器並從複寫中移除
在某些情況下，這個選項可能是唯一可行的選擇。 在推廣伺服器後，更新應用程式的連線字串。 還原原始區域之後，舊的主要伺服器可能會再次變成使用中狀態。 請務必將其移除，以避免產生不必要的成本。 如果您想要維護先前的拓撲，請重新建立讀取複本。