接上期说，（没看上期的，还是先看上期，要不从这看是看不懂的）
那到底这个手动转换的过程是如何的，这个要搞一搞清楚
repmgr -f /etc/repmgr.conf standby switchover -U repmgr --verbose
1 步 根据执行地的repmgr 数据库中的记录，开始找到那个是当前的主节点，因为你是在从库执行的
2 步 发现主节点，并且找到其node ID
3 步连接到主节点通过SSH 协议
4 检测当前的archive 文件
5 检测主从之间的数据差距，通过wallog 来判断
6 检测没有问题，关闭主节点，如果还有没有checkpoint的，就等待checkpoint
7 开始执行 -m fast sotp 命令，快速关闭pg 主库
8 开始等待关闭，时间为1分钟，每秒侦测一次到底关没有关 （可以调节）
9 开始对从库 promote 执行promote 命令
10 开始检查从库是否promote 成功 时间1 分钟
11 将原来的主库重新加入，对比两个节点之间的日志差距
12 原主节点变更为从节点
任务成功
那问题来了，如果要是这段操作不成功呢，MHA 也没有百分之百成功的，也有失误的时候，如何补救。
下面继续，
遇到的问题
1 虽然切换成功，但原主库并没有关闭，demotion失败
解决方法
1 关闭原主库（用任何方法都可以），如果运维自动化，可以写脚本，KILL
2 打开主库，然后使用命令将其驱逐出 repmgr 集群
使用命令
repmgr standby unregister -f /etc/repmgr.conf
将降级为standby的从库从集群中注销
3 关闭分离的从库
4 清理数据目录
5 重新使用
repmgr -h 192.168.198.22 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone
命令将进行从库的clone
6 更改 postgresql.conf listen 地址
7 启动从库
8 重新注册从库
repmgr -f /etc/repmgr.conf standby register
一切正常，数据库集群完璧归赵。
手动的切换的问题，我们告一段落，下面是怎么能自动切换的问题，怎么配置的过程先不废话，先看效果，估计要讲清这个系列的问题，是要几期的
192.168.198.21 primary postgresql
192.168.198.22 standby postgresql
现在我要停止 192.168.198.21 的postgresql ，然后在1分钟后 primary 如果还不能正常工作，则 192.168.198.22 将变为主库，这个过程其实和MHA 没有什么区别
1 在关闭 primary 前的和关闭后的图
2 关闭primary 的图
3 切换成功，从库已经可以进行写操作
好了到目前为止，POSTGRESQL 的高可用，手动，自动 都是可以的，没有任何问题。
问题是到底怎么做的，这就是依靠 repmgr 的另一个功能 repmgrd 组件来进行的监控，并在出现问题后通过配置进行切换的方法。
问题的repmgrd 是什么 （具体怎么做的先了解他是什么什么东西再说）
repmgrd是一个管理和监视守护进程，它在复制集群中的每个节点上运行。它可以自动执行一些操作，比如故障转移和更新备用服务器，并提供关于每个备用服务器状态的监视信息。
在使用repmgrd 的情况下，需要将其与postgresql进行绑定，也就是需要在
shared_preload_libraries = 'repmgr' 中进行配置,需要加载到共享库。（这不是高可用的内容，这是安装POSTGRESQL 是的一些配置，如不清楚，请自行翻看以前的安装文字或百度）
在使用repmgrd 进行主从切换的有几个需要注意的地方 （其实和MHA 差不多）
1 在主从切换的过程中，等待多长时间来判断主库已经无法启动了或不是因为网络原因造成的问题，或及时是网络造成的问题，多长时间能容忍，不切换。
2 切换的过程如果不成功怎么办，什么可能的因素会导致切换失败
3 多节点，如果切换，其他的节点是否可以连接到新的主上，并继续工作
4 跨数据中心的怎么来进行高可用的规划。
1 在主从切换的过程中，等待的时间要和你的当前的运维基础有关，如果你本身的网络基础就不好，还设置的比较短的诊断时间，那只能是给你自己平添烦恼
2 切换失败后的问题分析诊断，以及恢复
3 多从节点的换主，后续安排工作的自动化
4 跨数据中心的高可用，在网络以及切换上的考量
这里基本上 repmgr 与 repmgrd 都有相关的安排和设置
1 主失败后等待切换时间的设置在 repmgr.conf 文件中，红色标注的地方
这里分别是在设置重新连接主库的次数 和 时间间隔，
reconnect_attempts * reconnect_interval 等于最终主库无响应（包含网络问题）后的切换前的重试时间，所以这里就是第一个问题，如果你的网络不稳定，或者跨机房，你自己就的适当的调整参数，已适应你出现问题后的情况。
2 切换不成功的大概率可能性是从库在从事其他的工作，而不是standby，所以这你就需要衡量一下，到底你的这个standby 的重要性是什么，是要协同工作，读写分离，还是就是一个standby 随时待命来进行切换。当你有多个standby 的时候，你还可以调整你从库的 priority （这点和 MYSQL的 MGR 中的 priority 有点像，其实也是一个意思，这里就不啰嗦了）
3 多节点，例如你有三个postgresql 的节点其中一主两从，当其中主节点失效后其中一个变为主节点，但另一个从节点也需要继续工作，需要链接到新的主上，这个工作在POSTGRESQL 怎么做，因为是物理复制，不是逻辑复制，所以也没有那么简单。
4 跨数据中心的postgresql 则需要考虑的问题是跨数据中心的网络问题，以及脑裂问题，例如部署一定是单数节点，那单数节点的情况下，那边的节点数量要多，而多的那边放置的是什么节点，例如我就两台postgresql 主从，跨数据中心，但我怎么能防止脑裂，则就需要引入 wintness 服务器，也就是postgresql 见证服务器，他一般放置在数据中心的 主库位置，本身不参与数据的复制和分发，（这点有点类似 SQL SERVER 镜像功能的见证服务器，虽然SQL SERVER 新的版本 镜像功能被取消了）如果主变得不可用备用可以决定是否它能促进本身也不用担心“分裂的场景，如果它不能看到证人或主服务器,很可能有一个网络级中断,它不应该促进本身。如果它可以看到见证而不是主节点，这证明不存在网络中断，主节点本身不可用。
这期就到这里，下期会开始进行实际的 postgresql 自动故障切换处理的设置，以及相关文字
