適用於 PostgreSQL 的 Azure 資料庫 是一項完全受管理的資料庫服務，能讓你對資料庫管理功能和設定有細緻的控制與彈性。 該服務根據您的需求提供高可用性與災難復原能力。
當您使用 Azure 時， 可靠性是共同的責任。 Microsoft 提供一系列功能來支援韌性和復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作，並選取符合業務目標和正常運作時間目標所需的功能。
本文說明如何讓 適用於 PostgreSQL 的 Azure 資料庫 具備韌性，能應對各種潛在的中斷與問題，包括暫時性故障、可用性區中斷、區域中斷及服務維護。 同時說明如何利用備份來從其他類型的問題中復原，並強調 適用於 PostgreSQL 的 Azure 資料庫 服務水準協議（SLA）的關鍵資訊。
生產部署建議
若想了解如何部署適用於 PostgreSQL 的 Azure 資料庫以支援解決方案的可靠性需求，以及可靠性如何影響架構的其他面向，請參閱 Azure Well-Architected 框架中的 Architect 最佳實務適用於 PostgreSQL 的 Azure 資料庫。
可靠性架構概觀
本節說明服務運作中從可靠性角度來看最為重要的部分。 本節介紹邏輯架構，包含你部署和使用的部分資源與功能。 它還討論了物理架構，其中提供了有關服務如何在幕後工作的詳細信息。
邏輯架構
當你使用 適用於 PostgreSQL 的 Azure 資料庫 時，你會部署一台伺服器，代表支援你部署到伺服器的資料庫所需的運算與儲存資源。
你可以部署多種 運算層級的伺服器：突發型、通用型和記憶體優化型。 每個層級都針對 不同類型的工作負載進行優化。 在某些 Azure 區域，你可以部署使用 Azure Confidential Computing 的伺服器。
欲了解更多一般服務架構與部署模型，請參閱 適用於 PostgreSQL 的 Azure 資料庫 概述。
實體架構
運算與儲存分離： 適用於 PostgreSQL 的 Azure 資料庫 採用運算與儲存分離架構以支援高可用性。 資料庫引擎運行於 Linux 虛擬機（VM），而 Azure 儲存體 則保存資料檔案，並保留三個本地冗餘的同步備份，以確保資料的穩定性。
高可用性： 你可以在伺服器上啟用高可用性設定。 啟用高可用性設定後，服務會提供並維持一個溫備伺服器。 主伺服器會同步將資料變更複製給待機伺服器，以確保主伺服器故障時不會遺失資料。
該架構將運算層與儲存層分開，使服務能適當處理不同類型的故障。 為了提高韌性，你可以將伺服器分散在不同的可用區域。
示意圖，展示 適用於 PostgreSQL 的 Azure 資料庫 的高可用性架構。 兩台伺服器並排存在。 左邊有一個標示為主要伺服器的盒子，裡面有一個虛擬機器和一個磁碟。 右側有一個標示為待機伺服器的相符盒子，裡面同時包含虛擬機和磁碟。 一個水平箭頭從左側的主伺服器指向右側的備用伺服器，箭頭標示為串流複寫，表示資料流從主伺服器到備用伺服器的單向關係。
備用伺服器部署於與主伺服器相同的虛擬機器配置中，包含虛擬核心（vCore）、儲存空間及網路設定。
你可以執行故障轉移來切換伺服器。 故障轉移有兩種： 強制故障轉移，當主要伺服器故障時使用;以及 計劃故障轉移，用於某些維護作業及其他需要減少應用程式停機的情境。
當你執行停止、開始和重新啟動等操作時，這些操作會同時發生在主要與待命的資料庫伺服器上。 像是計算擴展和儲存擴展等計畫性事件，會先在備用伺服器發生，然後再在主伺服器上進行。 目前，伺服器不會因這些已規劃作業而進行容錯移轉。
如需詳細資訊，請參閱 適用於 PostgreSQL 的 Azure 資料庫中的高可用性。
備用： 適用於 PostgreSQL 的 Azure 資料庫 會自動建立伺服器備份。 更多資訊請參見 備份與還原。
對瞬態故障的彈性
暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中，而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤，通常透過重試受影響的請求來進行。
所有雲端託管應用程式在與任何雲端託管的 API、資料庫及其他元件通訊時，都應遵循 Azure 暫態故障處理指引。 如需詳細資訊，請參閱 處理暫時性錯誤的建議。
您的應用程式必須處理可能在維護、擴展作業或網路中斷期間發生的短暫連線錯誤。 請遵循這些建議：
當應用程式遇到暫時性故障時，請使用指數退避策略(exponential backoff)重新嘗試操作。 增加重試間隔並限制嘗試次數。 如果操作在最大重試後仍然失敗，則視為失敗。
如果可能，請使用能自動處理重試的客戶端函式庫（也稱為驅動程式）。
寫入操作中發生的暫時性錯誤需要更謹慎的考量。 請考慮讓您的寫入作業成為冪等，這樣便可以安全地執行多次。
欲了解更多資訊，請參閱 在 適用於 PostgreSQL 的 Azure 資料庫 中處理瞬態連線錯誤。
對可用性區域故障的抵抗力
可用性區域 是 Azure 區域內物理上獨立的資料中心群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。
透過高可用性配置選擇您的可用性區支援類型。 啟用高可用性時，服務會在你的主伺服器旁部署一台備用伺服器。 這種高可用性模型有助於確保已提交的資料在故障時不會遺失。 無論你的伺服器採用哪種高可用性部署模式，它都會同步將資料提交給主要伺服器和備用伺服器。 若主伺服器發生中斷，該伺服器會自動切換至待機伺服器。
每個可用區域將資料檔案與預寫日誌（WAR）儲存在配備本地冗餘儲存（LRS）的高級管理磁碟上，該磁碟會自動在每個區域內儲存三份資料副本。
適用於 PostgreSQL 的 Azure 資料庫 在使用高可用性時，支援兩種可用性區域的配置類型：
區域冗餘高可用性： 區域冗餘透過將主伺服器部署於一個可用性區域，備用伺服器部署於不同可用性區域，提供最高等級的區域韌性。 備用伺服器的運算、儲存和網路配置與主伺服器相似。 區域備援設定可為主要和待命伺服器之間的整體堆疊提供實體隔離。
你可以選擇主伺服器和待機伺服器的可用性區域，或讓 Microsoft 自行選擇。
我們建議對生產伺服器進行區域冗餘部署。
顯示跨多個可用性區域分布的一個區域備援適用於 PostgreSQL 的 Azure 資料庫設定的示意圖。 頂部列出三個區域：可用區 1、可用區 2 和可用區 3。 在可用性區域 1 下有一個標示為主要伺服器的盒子，裡面有一個虛擬機器和一個磁碟，顯示主要伺服器包含運算與儲存。 在可用性區 2 下，有一個標示為待機伺服器的匹配框，裡面也包含虛擬機和磁碟。 在這兩個伺服器盒之間，有一個指向右的箭頭標示為串流複製，顯示資料變更從左側的主伺服器流向右側的備用伺服器。 此配置傳達跨區域韌性：主區與待命區分隔於兩個可用區，而可用區3則未被使用。
寫入操作可能會有少量提交延遲增加，因為服務會同步將資料複製到備用伺服器。 影響會依工作量、所選SKU及地區而異。
區域（同區域）高可用性：主要伺服器與待命伺服器共用相同的可用性區。 如果主伺服器發生中斷，但區域仍正常，伺服器會自動切換到待命伺服器。 區域部署則能在單一可用區域內提供高可用性。 它能保護你免於節點層級故障，並幫助減少計畫內外停機事件中的應用程式停機時間。 不過，它無法防止該區域的停電。
顯示單一可用性區域中的區域性適用於 PostgreSQL 的 Azure 資料庫設定的示意圖。 顯示三個區域：可用性區 1、可用區 2 和可用區 3。 在可用性區域 1 中，有兩個方塊並排。 左邊的盒子標示為主要伺服器，裡面有一個虛擬機器和一個磁碟。 右邊的方框標示為備用伺服器，裡面有一個虛擬機和一個磁碟。 在這兩個伺服器盒之間，有一個指向右的箭頭標示為串流複製，顯示資料變更從左側的主伺服器流向右側的備用伺服器。 兩台伺服器都在同一個可用區。 可用區 2 和可用區 3 未被使用。
區域（同區域）高可用性僅在以下情況下提供：
- 該區域不支援可用性區域。 該區域實際上就像一個區域，所以你唯一能選擇的高可用性配置就是同一區域。
- 若區域容量不足以部署區域冗餘，服務可先將兩台伺服器置於同一可用區，當容量空出時自動遷移至不同區域。 這個選項在你使用 Azure 入口網站或 Azure CLI 部署伺服器時可以使用。 欲了解更多資訊，請參閱 「配置業務關鍵（高可用性）選項」。
將伺服器放在同一區域，可以降低你部署在同一區域內的應用程式的寫入延遲。
當伺服器在同一區域時，部署於同一區域內的應用程式的寫入延遲可以降低。
如果你設定伺服器時沒有高可用性，那麼它就會在單一伺服器上運行。 如果那台伺服器或它的區域當機，你的伺服器就無法使用。 欲了解更多資訊，請參閱 無可用性區的配置。
要求
區域支援：適用於 PostgreSQL 的 Azure 資料庫 在不同 Azure 區域以不同方式支援可用性區域配置。 完整區域清單、可用性區域支援類型及各區域的特定考量，請參見 Azure 區域。
運算層級： 下表列出每種可用性區域支援類型的運算層級支援：
計算層 區域備援 區域性 (同區) 突發性 不支援 不支援 常規用途 支援 支援 記憶體最佳化 支援 支援 服務等級： 這兩種高可用性都需要通用或記憶體優化層級。
考慮事項
區域容量： 若區域容量不足以部署區域冗餘，服務可先將兩台伺服器置於同一可用區，並在容量空出時自動遷移至不同區域。 這個選項在你使用 Azure 入口網站或 Azure CLI 部署伺服器時可以使用。 欲了解更多資訊，請參閱 「配置業務關鍵（高可用性）選項」。
Cost
啟用高可用性後，會建立一個備用伺服器，並以與主伺服器相同的費率計費。 可用性區的配置不會影響成本。 在可用區內或區域間進行資料複製不需收費。 根據備份儲存體磁碟區，您可能也會支付備份儲存體的費用。 欲了解詳細價格資訊，請參閱 Azure 資料庫中的 PostgreSQL 定價資料。
設定可用性區域支援
要設定伺服器的可用性區域支援，請設定高可用性設定。
建立區域冗餘伺服器：想了解如何建立啟用高可用性與區域冗餘的伺服器，請參閱快速入門：為 適用於 PostgreSQL 的 Azure 資料庫 伺服器建立。
更改現有伺服器的可用性區域設定： 透過更改高可用性設定來更改現有伺服器的可用性區域設定。 詳細步驟請參見 「啟用現有伺服器的高可用性」。
你無法更改主伺服器或備用伺服器所使用的區域。 你需要重新建立伺服器。
小提示
我們建議您等到伺服器活動量低時，再更改高可用性設定。
關閉高可用性： 關閉高可用性會移除待機伺服器，因此你的伺服器無法抵抗其可用性區域內的故障。 更多資訊請參見 「停用高可用性」。
所有區域都狀況良好時的行為
本節說明當您配置具備高可用性及支援可用性區域的伺服器時，所有可用性區域均已運作時，會遇到什麼情況。
跨區作業： PostgreSQL 用戶端應用程式透過資料庫伺服器名稱連接主伺服器。 適用於 PostgreSQL 的 Azure 資料庫 採用主動-被動配置，主要可用性區的主伺服器負責所有資料庫連線與查詢。 待命伺服器在正常運作時不會服務客戶端流量。
跨區域資料複寫： 主伺服器會同步將變更複製到備用伺服器。 交易在主伺服器和備用伺服器都確認寫入後才算完成。
當應用程式寫入並提交資料時，PostgreSQL 會先在主伺服器的 WAL 中記錄變更。 主伺服器會透過 PostgreSQL 串流協定，將這些日誌串流到備用伺服器。 待命伺服器持續儲存 WAL 後，主伺服器會確認寫入。 應用程式只有在確認之後才提交交易。 此通知程序不會等候待命伺服器套用記錄。
複製的影響會依伺服器所使用的可用性區域配置而異：
區域冗餘： 由於伺服器位於不同區域，此方法確保區域故障時零資料遺失。 這種情況有時也稱為實現區域故障時零資料遺失的復原點目標 (RPO)。
然而，跨區域複製可能會帶來少量額外的延遲。 延遲的影響取決於應用程式。 對大多數應用來說，額外的延遲可以忽略不計。
區域：由於兩台伺服器位於同一區域，區域間不會有流量重複。
備註
系統會即時將日誌資料複製到備用伺服器。 主伺服器上的任何使用者錯誤，例如資料表意外遺失或資料更新錯誤，都會被複製到備用伺服器。 你無法用待機來從這類錯誤中恢復，必須從備份中進行即時還原。 更多資訊請參見 備份與還原。
區域失敗期間的行為
本節說明當您將伺服器設定為高可用性並支援可用區域，且發生可用區域故障時，可以預期會出現的情況。
偵測與回應： Azure 會定期檢查主要伺服器和待機伺服器的健康狀況。 在多次 Ping 後，如果健康監控偵測到主要伺服器無法連線，服務會自動發起轉移至待命伺服器。 健康監控演算法使用多個資料點來避免誤報情況。
若某個可用區域失效，行為會依據伺服器所使用的可用性區域設定而有所不同：
區域冗餘： 適用於 PostgreSQL 的 Azure 資料庫 會自動偵測可用性區域失效。 欲查看可能的高可用性狀態類型，請參閱 高可用性（HA）健康狀態監控。 當區域故障時，Azure 會啟動強制容錯移轉至待命伺服器，您無需採取任何行動。
分區： 若承載區域伺服器的可用性區域無法使用，主伺服器與待機伺服器皆無法使用。 在這種情況下，服務不會提供自動故障轉移。 你負責偵測區域中斷並執行復原行動，例如將區域冗餘備份還原到另一個可用區域或區域的獨立伺服器。
通知：適用於 PostgreSQL 的 Azure 資料庫 中的高可用性健康狀態監控，提供高可用性啟用實例的健康狀況與準備狀況的持續概覽。 監控功能建立在 Azure 資源健康之上，能偵測並警示任何可能影響資料庫故障轉移準備度或整體可用性的問題。 評估連線狀態、故障切換狀態及資料複製健康等關鍵指標，以促進主動故障排除，並協助維持資料庫的正常運作時間與效能。
關於配置與解讀 HA 健康狀態的詳細指南，請參見 高可用性（HA）健康狀態監控。
目前的請求： 當某個可用區域無法使用時，對受影響區域內伺服器的任何進行中請求可能會被終止。 應用程式必須重新嘗試這些請求。 如果您的用戶端能透過在短暫延遲後重試而適當處理好暫時性錯誤，通常就能避免產生重大影響。
預期資料遺失： 資料遺失的程度取決於伺服器使用的可用性區設定。
區域冗餘：由於不同區域中的主伺服器與備援伺服器間的同步複製，預期在發生區域故障轉移時零資料遺失。
區域： 受影響區域內伺服器上的資料在該區域恢復之前無法存取。
預期的停機時間： 停機時間長短取決於伺服器使用的可用性區設定。
區域冗餘： 備援切換通常在 60 至 120 秒內完成。 如果您的用戶端能透過在短暫延遲後重試而適當處理好暫時性錯誤，通常就能避免產生重大影響。
分區： 受影響區域的伺服器在可用區域恢復前無法使用。
重新劃分： 流量重路由的行為取決於你伺服器使用的可用性區設定。
區域冗餘： 故障切換後，原本的待命伺服器會成為新的主伺服器，並開始接受新的連線。 Azure 會在恢復後自動在原始主區域建立新的備用伺服器。 如需完整細節。請參閱強制容錯移轉。
分區： 當某個分區無法運作時，你的伺服器也無法運作。 如果你在其他可用區域或區域事先建立獨立伺服器，你就要負責將流量重新導向該伺服器。
區域復原
區域恢復的行為取決於伺服器使用的可用性區域設定。
區域冗餘： 當可用性區域恢復時，適用於 PostgreSQL 的 Azure 資料庫 會自動重建已恢復區域內的備用伺服器，並與目前的主要伺服器同步。 回收區域隨後作為待命位置。 為避免不必要的干擾，服務不會自動將主要角色移回原本的區域。 如果您想把主要項目送回原本的區域，您可以手動啟動計畫性容錯移轉。
分區： 當區域恢復健康後，該區域內的伺服器又會重新開放。 您負責工作負載所需的任何區域復原程序和資料同步處理。
測試區域失敗
測試區域失敗的選項取決於您執行個體所使用的可用性區域設定。
區域備援：您可以啟動強制容錯移轉來測試應用程式在進行容錯移轉時的復原力。 強制故障轉移讓你在執行工作負載時模擬意外中斷情境，並觀察應用程式停機時間。 我們建議你在非生產環境或安靜時段執行模擬。 如需詳細資訊，請參閱啟動強制容錯移轉。
區域性：雖然您無法模擬整個區域服務中斷，但您可以模擬伺服器無法使用的情況，方法類似於區域服務中斷的情形。 更多資訊請參閱 停止伺服器運算。
對區域範圍故障的復原能力
適用於 PostgreSQL 的 Azure 資料庫 支援 跨區域讀取副本，你可以用它來維護資料庫在不同區域的同步副本，以加快復原速度。
你也可以在支援的區域使用地理冗餘備份，來提供跨區域的復原。 然而，備份通常比複寫時更長時間停機和資料遺失。 更多資訊請參見 備份與還原。
跨區域讀取副本
你可以部署讀取副本來保護資料庫免於區域層級的故障。 每個讀取複本都是單獨的適用於 PostgreSQL 的 Azure 資料庫伺服器。 當你將讀取副本放在第二個 Azure 區域時，你的資料庫伺服器可以對區域性問題提供韌性。 你可以部署最多五個讀取副本，這些讀取副本可以選擇性地分布在不同的 Azure 區域。 PostgreSQL 的實體複製技術會非同步更新讀取副本，且它們可能會延遲主副本。 跨區域讀取副本可選擇性地提供唯讀工作負載，以降低全球分布應用程式的延遲，或將主伺服器的讀取流量卸載。 如需讀取複本功能和考量事項的詳細資訊，請參閱讀取複本。
虛擬端點提供讀寫和唯讀端點，並在複本升級時自動重新導向流量，有助於將容錯移轉事件中的停機時間降至最短。 我們強烈建議使用具備跨區域讀取副本的虛擬端點，以提升應用程式韌性。 如需詳細資訊，請參閱適用於 PostgreSQL 的 Azure 資料庫中讀取複本的虛擬端點。
頂部有顯示應用程式的示意圖。 正下方有一個標示為讀寫端點的方塊。 從應用程式到端點有一個向下的箭頭，顯示應用程式先將資料庫流量傳送到該端點。 圖的下半部分為兩個大區域。 左側是主要區域。 在該區域內，有一個標示為「主要伺服器」的方塊，而在該方塊內有一項名為 適用於 PostgreSQL 的 Azure 資料庫 伺服器的服務。 右側是次要區域。 在該區域內，有一個相符的伺服器方塊，標示為從讀取複本升級而成的主要伺服器，也標示為適用於 PostgreSQL 的 Azure 資料庫伺服器。 一條箭頭從讀寫端點延伸到主伺服器。 一個標示著「非同步複製」的水平虛線箭頭，從左側的主要伺服器指向右側次要區域中的伺服器，表示資料變更會從主要伺服器複製到複本。
如果你的主要區域失敗，你可以觸發 升遷 ，讓你的次要複製品成為主要區域。 不同類型的容錯移轉可能適合，取決於您如何使用讀取複本。 當您使用讀取複本來提供區域故障時的復原力時，您通常會使用升級至主要伺服器方法，這麼做會更新您的虛擬端點。 在區域故障期間，你需要執行 強制升級，這可能會導致未複製的資料遺失。 在主要區域健康且有計畫的情境下，您可以選擇執行計畫性促銷以避免資料遺失。 如需詳細資訊，請參閱升級適用於 PostgreSQL 的 Azure 資料庫中的讀取複本。
圖示顯示一個應用程式在頂端透過讀寫端點傳送資料。 圖的下半部分為兩個大區域。 左側是主要區域。 在該區域內，有一個標示為「主要伺服器」的方塊，而在該方塊內有一項名為 適用於 PostgreSQL 的 Azure 資料庫 伺服器的服務。 主區域上方有個 x 標記，表示它已經不再活躍。 右側是次要區域。 在該區域內，有一個相符的伺服器方塊，標示為從讀取複本升級而成的主要伺服器，也標示為適用於 PostgreSQL 的 Azure 資料庫伺服器。 一條箭頭從讀寫端點延伸到次要區域。 一個標示為「非同步複寫」的虛線水平箭頭，從主要區域延伸至次要區域，上方有一個 X 覆蓋，表示該複寫已不再啟用。
備註
本節總結了關於已讀複本如何支持對區域性故障韌性的重要資訊。 你也可以使用讀取副本來提升效能並支援大規模分布在地理上的使用者群。 如需更多資訊，請參閱 Read Replicas。
要求
區域支援： 你可以在任何支援 適用於 PostgreSQL 的 Azure 資料庫 的區域建立跨區讀取副本。 你不侷限於 Azure 配對區域。
計算層級： 通用運算層級與記憶體優化運算層級支援讀取複本。 Burstable 層級不支援讀取副本。
考慮事項
配置差異： 讀取副本可能不會繼承主伺服器的所有設定。 計畫在容錯移轉後設定必要設定。 你的主伺服器和副本應該是對 稱的，也就是說它們在某些設定上需要擁有相同的階層、儲存容量和數值。 在區域故障時，強制升級時可以免除對稱伺服器的要求，但盡量保持對稱配置是好做法，以避免意外問題。 欲了解更多資訊，請參閱 組態管理。
監控複製延遲： 非同步複製過程需要複製延遲，且會因多種因素而異。 當複製延遲很高時，你的伺服器可能會遇到問題。 監控複製延遲很重要，這樣才能在問題惡化前加以緩解。 欲了解詳細資訊，請參閱 監控複製。
高可用性：讀取複本無法啟用高可用性，且當它們受到升級時，也不會具有高可用性。 您要負責在升級複本後設定高可用性。
關於晉升過程的其他因素，請參見 「考量事項」。
Cost
讀取副本會產生運算和儲存費用，另需支付複寫所產生的跨區域資料傳輸費用。 欲了解詳細價格資訊，請參閱 Azure 資料庫中的 PostgreSQL 價格 與 頻寬定價。
設定多區域支援
建立一個讀取副本： 想了解如何建立讀取複本，請參見 「建立已讀複本」 你可以在建立主伺服器後設定複本，只要主伺服器在運作且可存取。
要建立虛擬端點，請參見 建立虛擬端點。
刪除已讀複本： 想了解如何刪除讀取副本，請參見 刪除讀取副本。
當所有區域都正常時的行為
本節說明當您的伺服器在另一個區域設置讀取副本和虛擬端點，且所有區域皆正常運作時，可以預期的情況：
區域間流量路由： 在正常操作中，你的虛擬端點會將讀寫端點的流量導向主區域的主伺服器。 如果你也使用虛擬端點的唯讀端點，它會將流量導向你設定的副本。
區域間的資料複製： 跨區域讀取副本使用非同步複寫，以減少對主要伺服器效能的影響。 複製延遲的程度取決於多種因素，包括寫入負載以及主伺服器與副本之間的延遲。 複製延遲通常至少有幾分鐘，但也可能更久。 欲了解詳細資訊，請參閱 監控複製。
區域失敗期間的行為
本節說明當您的伺服器在另一個區域設置讀取副本和虛擬端點，且主區域發生故障時，可以預期的情況：
偵測與回應： 你負責偵測主要區域的故障，並手動將讀取副本升遷成新的主伺服器。 在區域故障期間，您必須執行強制升級，這樣會導致所有未複寫資料的遺失。
這很重要
你要負責觸發升遷。 即使發生區域故障，Azure 也不會自動升級讀取複本。
有關啟動升級的詳細步驟，請參閱將讀取複本切換為主要複本。
通知： Microsoft 不會自動通知你區域失效。 不過，你可以使用 Azure 服務健康狀態 來了解整體服務的健康狀況，包括任何區域故障，並且可以設定 服務健康警示 來通知你問題。
作用中要求：升級過程會中斷所有與主要區域的作用中連線。 升遷過程完成後，應用程式需重新嘗試與升遷副本建立連線。
預期資料遺失： 在區域故障期間，你必須強制升級，導致任何未複製的資料永久遺失。
資料遺失的程度取決於中斷時的複製延遲。 複製延遲通常至少有幾分鐘，但也可能更久。 欲了解詳細資訊，請參閱 監控複製。
預期的停機時間： 強制升級通常在觸發後1到3分鐘內完成。 應用程式也可能需要重新連接到正確的端點。 虛擬端點會作為強制升遷流程的一部分進行更新。 應用程式應尊重端點 DNS 紀錄的存活時間（TTL），以確保升級完成後能迅速重新連接至正確的副本。
流量重導： 伺服器的虛擬端點會自動將應用程式流量重新導向到新的主要抄本。
備註
當讀取複本升級為主要伺服器後，它並未啟用高可用性組態。 你需要手動啟用高可用性設定，或將其加入自己的自動化流程中。
區域復原
當你使用虛擬端點時，主區域恢復後，舊的主伺服器會自動被設定為讀取副本。 你可以再進行一次促銷，將主要業務重新帶回你偏好的主要區域。
區域故障測試
請定期測試讀取複本升級程序以確保您的流程有效，且功能符合您的復原時間目標 (RTO) 及復原點目標 (RPO) 要求。
您可以隨時將讀取複本升級為主要伺服器，即使所有區域均為健全狀態良好。 測試用：
- 你可以進行強制升階測試。 我們建議您在非生產環境下進行這些測試，因為這可能導致資料遺失。 強制升級測試有助於模擬您在區域服務中斷期間會看到的行為。
- 對於計畫性維護或測試場景，避免資料遺失，建議改用計畫性推廣。 然而，計畫性促銷的流程與區域故障時的推廣不同，因此可能無法反映真實區域故障時的行為。
如需逐步指示，請參閱將讀取複本切換為主要複本。
作為災難復原策略的一部分，定期進行完整的復原演練。 這些演練應包含資料驗證、應用程式功能測試及文件化的回滾程序。
備份與還原
適用於 PostgreSQL 的 Azure 資料庫 會自動備份你的資料。 這些備份提供即時復原能力，幫助你防範資料意外損壞與刪除。 Microsoft 完全負責管理備份。 它們不會中斷伺服器的可用性，且包含完整備份和交易日誌備份。
備份儲存： 如果你將伺服器部署在有可用性區域的區域，服務會將備份儲存在區域冗餘儲存（ZRS），不論伺服器的高度可用性設定如何。 對於部署於無可用性區域的伺服器，該服務會將備份儲存在本地冗餘儲存（LRS）。
在 Azure 區域的配對中，你可以在伺服器建立時設定地理冗餘備份儲存，將備份複製到 Azure 配對區域，以加強區域故障的防護。 該服務以非同步方式複製備份。
預設的備用保留期限為七天，但你可以延長最多35天。 你也可以使用 Azure 備份 來長期儲存手動備份，長達 10 年。 所有備份都加密了。
恢復： 點即時復原讓你能將資料庫還原到備份保留期內的任何時刻。 還原過程會建立一個新的資料庫伺服器，並使用使用者提供的伺服器名稱。 你可以使用新的伺服器 as-is 或從中複製資料。
當你還原地理冗餘備份時，你會在配對區域建立一台新伺服器。
此功能有助於從意外資料修改、應用程式錯誤或測試情境中恢復。
針對大部分的解決方案，您不應該只依賴備份。 請改用本指南中所述的其他功能來支持復原需求。 不過，備份可防範其他方法未發生的一些風險。 欲了解更多資訊，請參閱冗餘、複寫與備份是什麼？
欲了解更多資訊，請參閱 PostgreSQL 的 Azure 資料庫備份與還原。
服務維護的韌性
適用於 PostgreSQL 的 Azure 資料庫 自動處理關鍵的維護任務，包括修補底層硬體、作業系統及資料庫引擎。 該服務包含安全更新、軟體更新及小幅版本升級，作為計畫維護的一部分。
為了確保伺服器在維護期間仍能保持可用，請遵循以下建議：
啟用高可用性： 維護期間，伺服器可能需要重新啟動以進行更新。 若啟用高可用性，維護作業通常會使用滾動更新以減少停機時間。 定期維護活動（例如小版本升級）會先在備用複本上進行。 為了減少停機時間，會將待命節點升格為主節點，讓工作負載可在升格後的節點上繼續執行，同時在另一個節點上執行維護作業。 無論你的伺服器使用區域冗餘或區域高可用性，這種排序都適用。
對於未啟用高可用性的伺服器，維護作業期間可能會有短暫停機。 啟用高可用性後，維護作業通常能以極少甚至無停機時間完成。
設定自訂維護視窗： 您可以將維護排程設定為系統管理，或定義自訂維護時段，以將對業務營運的影響降到最低。 在低活動期安排維護，以減少業務影響。 欲了解更多資訊，請參閱 維護時間表。
實作重試邏輯： 確保您的應用程式能承受維護重啟期間可能發生的短暫連線中斷。 為了讓您的應用程式對這類問題具備韌性，請參閱「 對暫態故障的韌性 指引」。
服務等級協定
Azure 服務的服務層級協議（SLA）描述了每項服務的預期可用性，以及您的解決方案必須符合的條件，以達成該可用性預期。 欲了解更多資訊，請參閱線上服務的服務等級協議。
適用於 PostgreSQL 的 Azure 資料庫 根據伺服器配置提供不同的可用性 SLA：
- 設定為區域備援高可用性的伺服器會提供 99.99% 的正常運行時間 SLA。
- 配置為區域性高可用性的伺服器提供的服務等級協議 (SLA) 保證 99.95% 的正常運作時間。
- 未設定高可用性的伺服器可提供 99.9% 的正常運行時間 SLA。