PostgreSQL Switchover vs. Failover

Wednesday, April 19, 2017 

With streaming replication, Postgres allows sophisticated setups of primary and standby servers. There are two ways to promote a standby to be the new primary. A switchover is

when the change happens in a planned way: 

1.All clients are disconnected from the master to prevent writes 

2.A sufficient delay allows the final write-ahead log (wal) records to be transferred to all standbys 

3.The primary is shut down 

4.The standby is promoted to be the primary 

A failover happens when the steps above can't be performed, usually because the primary has failed in some catastrophic way. The major difficulty with failover is the possibility

that some of the final database changes contained in the wal are not transferred to standbys, unless synchronous_standby_names was used. When a standby is promoted to 

primary after a failover, the final missing wal records can cause problems: 

1.Some transactions on the old primary that were acknowledged to clients might be lost 

2.If the old master needs to be reconnected as a standby without reimaging, it might be necessary to use pg_rewind 

Make sure you practice both methods of promoting a standby so, when you have to do the promotion in production, you are ready. 

2017年4月19日，星期三 

通過流複制方式，Postgres允許用複雜的方式配置所有 master 和 standby 伺服器。standby 更新為新的 master 有兩種方式。

角色切換，一般是一種有計劃的變更：

1.所有連接配接 master 的用戶端斷開連接配接，阻止繼續的寫入。

2.足夠的時間延遲允許最終所有 WAL 日志傳輸到所有 standbys 。

3.關閉 master 。

4.standby 更新為 primary。

通常如果 master 伺服器發生災難并變得已經無效，以上步驟無法執行時就必須要進行故障轉移。故障轉移發生時主要難題是可能一些包含在 WAL 中的代表資料庫最終變化的 WAL 記錄不會被傳輸到 standby ，除非使用了synchronous_standby_names。當一個 standby 經過故障轉移後被提升為 master 最後的 WAL 記錄也會導緻一些問題：

1.舊 master 中的一些用戶端确認送出的事務或許會丢失。

2. 如果舊 master 想作為一台 standby 被重新連接配接，沒有重新生成的話，也許有必要使用pg_rewind。

確定你已經實踐過以上提到的兩種更新 standby 的方法，這樣在生産環境做更新就會有所準備。

reference:

http://momjian.us/main/blogs/pgblog/2017.html#April_19_2017

本文轉自 pgmia 51CTO部落格，原文連結:http://blog.51cto.com/heyiyi/1917655