# 25.3\. 失效切換 如果主服務器失敗，則備服務器應該開始失效切換處理。 如果備服務器失敗，則沒有失效切換需要考慮。如果可以重啟備用服務器， 甚至一段時間后，也可以立即重啟恢復進程，發揮重啟恢復的優勢。 如果不能重啟備服務器，則應該創建一個全新的備服務器實例。 如果主服務器失敗，并且備服務器成為新主服務器，然后舊主服務器重啟， 你必須有一個通知舊主服務器，其不再是主服務器的機制。 這有時被稱為STONITH（在頭去掉其它節點）， 這是必要的，以避免系統都認為它們是主服務器的情況下， 這將導致混亂和最終數據丟失。 許多失效切換系統只使用兩個系統，主備服務器，通過某種心跳機制， 不斷驗證兩者連接和主服務器的活力。 也可以使用一個第三方的系統 （稱為“證人服務器”），以防止某些情況下不適當的失效切換， 但額外的復雜性可能是不值得的，除非設置它為充分仔細和嚴格的測試。 PostgreSQL不提供所需的用來確定主服務器失敗， 并通知備用數據庫服務器的系統軟件。 存在許多這樣的工具和成功失效切換所需的集成操作系統的工具，如IP地址遷移。 一旦發生失效切換到備服務器，僅有一臺服務器運行。這就是所謂的退化狀態。 前者備服務器現在是主服務器，但前者主服務器是可能會停留下來。 要返回正常運行，必須重建一個備服務器，無論是在以前的服務器， 或在第三，可能是新的系統。一旦完成主備服務器，可以考慮轉換角色。 有些人選擇使用第三方服務器，提供新主服務器的備份直到新備服務器重建， 盡管清楚這個復雜的系統配置和操作流程。 所以從主到備服務器可以快速切換，但需要一些時間重新準備失敗切換集群。 定期主備服務器切換是有用的,因為它允許定期停機進行每個系統的維修。 這也是作為一個測試，以確保故失效切換機制，當你需要時會真的工作。 建議寫管理操作流程。 要觸發日志傳送備服務器的失效切換，運行`pg_ctl promote`或者創建一個觸發文件, 這個文件是通過在`recovery.conf`文件中`trigger_file`設置指定的文件名和路徑。 如果你計劃使用`pg_ctl promote`進行失效切換，則不需要`trigger_file`。 如果你設置報告服務器僅僅用于卸載主服務器的只讀查詢， 而不是針對高可用性的目的，那么你不需要推動它。