PostgreSQL 10.1 手冊_部分 III. 伺服器管理_第 26 章 高可用、負載均衡和複制_26.3. 故障轉移

26.3. 故障轉移

如果主伺服器失效，則後備伺服器應該開始故障轉移過程。

如果後備伺服器失效，則不會有故障轉移發生。如果後備伺服器可以被重新開機 （即使晚一點），由于可重新開機恢複的優勢，那麼恢複處理也能被立即重新開機。 如果後備伺服器不能被重新開機，則一個全新的後備伺服器執行個體應該被建立。

如果主伺服器失效并且後備伺服器成為了新的主伺服器，那麼接下來舊的主伺服器重新開機後， 你必須有一種機制來通知舊的主伺服器不再成為主伺服器。有些時候這被稱為STONITH（Shoot The Other Node In The Head，關閉其他節點）， 這對于避免出現兩個系統都認為它們是主伺服器的情況非常必要， 那種情況将導緻混亂并且最終導緻資料丢失。

很多故障轉移系統僅使用兩個系統，主系統和後備系統， 它們由某種心跳機制連接配接來持續驗證兩者之間的連接配接性和主系統的可用性。 也可能會使用第三個系統（稱為目擊者伺服器）來防止某些不當故障轉移的情況， 但是除非非常小心地建立它并且經過了嚴格地測試，否則額外的複雜度可能會使該工作得不償失。

PostgreSQL 并不提供在主伺服器上辨別失敗并且通知後備資料庫伺服器所需的系統軟體。 現在已有很多這樣的工具并且很好地與成功的故障轉移所需的作業系統功能整合在一起， 例如 IP 位址遷移。

一旦到後備伺服器的故障轉移發生，就隻有單一的一台伺服器在操作。 這被稱為一種退化狀态。之前的後備伺服器現在是主伺服器， 但之前的主伺服器處于關閉并且可能一直保持關閉。要回到正常的操作， 一個後備伺服器必須被重建，要麼在之前的主系統起來時使用它重建， 要麼使用第三台（可能是全新的）伺服器來重建。

pg_rewind

 工具可以用來在大型叢集上加速此程序。一旦完成， 主伺服器和後備伺服器可以被認為是互換了角色。 某些人選擇使用第三台伺服器來為新的主伺服器提供備份，直到新的後備伺服器被重建， 不過顯然這會使得系統配置和操作處理更複雜。

是以，從主伺服器切換到後備伺服器可以很快，但是要求一些時間來重新準備故障轉移叢集。 從主伺服器到後備伺服器的定期切換是有用的， 因為它允許每個系統有定期的關閉時間來進行維護。 這也可以作為一種對故障轉移機制的測試，以保證在你需要它時它真地能夠工作。 我們推薦寫一些管理過程來做這些事情。

要觸發一台日志傳送後備伺服器的故障轉移，運作

pg_ctl promote

 或者建立一個觸發器檔案，其檔案名和路徑由

recovery.conf

 中的

trigger_file

設定指定。如果你正在規劃使用 

pg_ctl promote

進行故障轉移，

trigger_file

就不是必要的。 如果你正在建立隻用于從主伺服器分流隻讀查詢而不是高可用性目的的報告伺服器， 你不需要提升它。

本文轉自PostgreSQL中文社群，原文連結：