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