如果主伺服器發生故障，則備用伺服器應開始故障轉移過程。

如果備用伺服器發生故障，則無需進行故障轉移。如果備用伺服器可以重新啟動，即使過一段時間也可以，那麼恢復過程也可以立即重新啟動，從而利用可恢復的恢復。如果備用伺服器無法重新啟動，則應建立一個全新的備用伺服器例項。

如果主伺服器發生故障，備用伺服器成為新的主伺服器，然後舊的主伺服器重新啟動，則必須有一個機制來通知舊的主伺服器它不再是主伺服器。這有時被稱為STONITH（Shoot The Other Node In The Head，即“槍斃另一個節點”），這是為了避免兩個系統都認為自己是主伺服器的情況，這會導致混亂並最終導致資料丟失。

許多故障轉移系統僅使用兩個系統：主伺服器和備用伺服器，它們透過某種心跳機制連線，以持續驗證兩者之間的連線以及主伺服器的可用性。也可以使用第三個系統（稱為見證伺服器）來防止某些不當故障轉移的情況，但除非經過仔細設定和嚴格測試，否則額外的複雜性可能不值得。

PostgreSQL 不提供識別主伺服器故障並通知備用資料庫伺服器所需的系統軟體。許多此類工具都存在，並且與成功故障轉移所需的作業系統功能（如 IP 地址遷移）整合良好。

一旦發生故障轉移到備用伺服器，就只有一個伺服器在執行。這被稱為退化狀態。前備用伺服器現在是主伺服器，但前主伺服器已關閉，並且可能會保持關閉狀態。要恢復正常執行，必須重新建立備用伺服器，可以在舊主伺服器重新啟動時在其上進行，或者在第三個，可能是新的，系統上進行。 pg_rewind 實用程式可用於加速大型叢集上的此過程。完成後，主伺服器和備用伺服器可以被視為已切換角色。有些人選擇使用第三臺伺服器為新主伺服器提供備份，直到重新建立新備用伺服器，儘管這顯然會使系統配置和操作過程複雜化。

因此，從主伺服器切換到備用伺服器可能很快，但需要一些時間來重新準備故障轉移叢集。主伺服器到備用伺服器的定期切換很有用，因為它允許每個系統進行定期的停機維護。這還可以作為故障轉移機制的測試，以確保在需要時它確實有效。建議制定書面的管理程式。

如果您選擇了邏輯複製槽同步（請參閱 第 47.2.3 節），那麼在切換到備用伺服器之前，建議檢查備用伺服器上同步的邏輯槽是否已準備好進行故障轉移。這可以透過按照 第 29.3 節 中描述的步驟來完成。

要觸發日誌傳輸備用伺服器的故障轉移，請執行 pg_ctl promote 或呼叫 pg_promote()。如果您設定的報告伺服器僅用於將只讀查詢從主伺服器解除安裝，而不是用於高可用性目的，則無需提升。