接上期，自动failover 到底要在哪里配置 （如果是第一次看这篇文的，请从第一篇看起，否则会不知道说什么）
具体的配置过程，
1 打开/etc/repmgr.conf 配置文件
2 在文件中找到以下内容，并修改
1 failover='automatic' #如果侦测到失败，则进行自动切换，默认为手动
2 connection_check_type=ping #检测的方式为PING 的方式
3 promote_command='/usr/local/postgres/bin/repmgr standby promote -f etc/repmgr.conf --log-to-file' #如果主节点失败，则要进行切换的工作，并记录到日志
4 follow_command='/usr/local/postgres/bin/repmgr standby follow -f etc/repmgr.conf --log-to-file --upstream-node-id=%n'
#如果有连接到主节点的其他从节点，会根据命令连接到新主的节点
5 reconnect_attempts=6 #尝试6次
6 reconnect_interval=10 #间隔 10秒每次
然后在每台服务器上执行
repmgrd -f etc/repmgr.conf
就可以完成postgresql 高可用，主库失败，自动切换到从库的部署。其实这比较MHA 更简单。
在配置好两台机器后的，并检查复制，机器都OK 的情况下，启动 repmgrd 程序
启动需要在两个节点都进行执行
在启动后可以看了repmgr 与 repmgrd 都在执行和监听中
下面开始关闭主节点，马上主节点的repmgrd 和 从节点的 repmgrd 都开始启动反应机制了
从库的日志中，可以看到1 分钟后，无法连接到postgresql 的主库服务，程序已经开始了切库的服务
从下图也可以看出切主后的结果，主已经变到了从库，从库已经被提升为主库了。
具体的过程如下
1 repmgrd （主，从 ）监听主库的服务是否在工作状态
2 关闭 主 ，主库 从库的 PQping() returned "PQPING_REJECT"
3 开始启动计时器，6次尝试后，给出主节点已经不能被访问的结论
4 从库节点开始执行提升计划
5 整体切换结束，但主节点会持续的进行告警
6 新主节点不在会侦测原主节点
整体切换就完成了。
那么后续还有一些问题需要继续
1 是否配置见证服务器，什么情况配置，怎么配置
2 失败 主节点想重新加入，怎么办
3 IP 切换怎么办
剩下的这些问题还是讲不完，今天将最简单的 问题2 继续下去
通过上图可以看到，通过一条命令
就已经将刚才已经关闭的主库再次上线，并且以从库的身份连接到了新主上。
（这点MHA 是无法做到的，这项功能是通过 pg_rewind 命令并辅以repmgr 关于自身的一些操作变化而来的）
所以第二个问题会很好解决。
但需要注意的
1 如果原主，已经掉线很长时间，两个库的日志之间已经无法进行追日志的情况，那就无法使用这个命令，而是用其他的方法。
2 如果原主本身数据受损，或者无法启动那这个命令也是没有办法帮助你的，
这个命令的大致的使用点，1 主库意外关机后的从新加入集群（主库能用但和从库有一定的数据不一致了）
所以PG 的集群高可用还是挺有意思的，尤其适用repmgr 一体化的方案，还是比较利于维护和模型修复的。
感兴趣的可以加群，share knowledge 共同提高
