如果主伺服器發生故障，備援伺服器應開始故障轉移程序。

如果備援伺服器發生故障，則無需進行故障轉移。 如果可以重新啟動備援伺服器，即使在一段時間後，也可以立即重新啟動復原過程，從可重新啟動的復原中受益。 如果無法重新啟動備援伺服器，則應建立一個全新的完整備援伺服器實例。

如果主伺服器發生故障，且備援伺服器成為新的主伺服器，然後舊的主伺服器重新啟動，您必須有一個機制通知舊的主伺服器，它已不再是主伺服器。 這有時被稱為STONITH(Shoot The Other Node In The Head，射擊另一個節點的頭)，這是必要的，以避免兩個系統都認為自己是主伺服器的情況，這將導致混亂，最終導致數據丟失。

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

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

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

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

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

要觸發日誌傳送備援伺服器的故障轉移，請運行 pg_ctl promote 或調用 pg_promote()。 如果您正在設置僅用於從主伺服器卸載唯讀查詢的報告伺服器，而不是用於高可用性目的，則無需提升。