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