谁说postgresql 没有靠谱的高可用（3）

接上期，自动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 共同提高