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
