共计 3040 个字符，预计需要花费 8 分钟才能阅读完成。
Repmgr 作为由第二象限开发的一款流复制管理工具，具有非常轻量级的使用特性。具体表现为：
配置操作简单，可一键式完成相关部署操作；
支持 Auto Failover 和 Manual Switchover；
分布式管理集群节点，易扩展，可在线增删集群节点；
Repmgr 流复制管理系统有 repmgr 和 repmgrd 两个命令。其中 repmgr 命令实现对集群节点的管理，如注册主 / 备节点、Clone 节点，Promote 节点，Follow 节点以及 Switchover 操作等；repmgrd 命令用来启动 repmgr 系统的守护进程，用以对集群节点的监控。
下图是 Repmgr 实现架构图。
Repmgr 流复制管理工具对集群节点的管理是基于一个分布式的管理系统。每个节点都有自己的 repmgr.conf 配置文件，用来记录本节点的 ID, 节点名称，连接信息，数据库 PGDATA 目录等配置参数。在配置好这些参数后，就可以通过 repmgr 命令实现对集群节点的“一键式”部署。
主节点：
- 配置好相关参数
- 启动数据库
- 利用“repmgr primary register”命令实现对主节点的注册。
（该注册的目的是把配置文件的一些主要参数写到元数据表中，以便 repmgr 系统对集群节点的识别操作等。）
- 启动 repmgrd 守护进程。
备节点：
- 配置好相关参数
- 利用“repmgr standby clone”命令对主节点进行物理拷贝。
- 启动数据库
- 利用“repmgr standby register”命令实现对备节点的注册。
- 启动 repmgrd 守护进程。
部署完成后，每个节点都有自己的元数据表，记录所有集群节点的信息；每个节点都有自己的 repmgrd 守护进程来监控节点数据库状态。其中主节点守护进程主要用来监控本节点数据库服务状态，备节点守护进程主要用来监控主节点和本节点数据库服务状态。在发生 Auto Failover 时，备节点在尝试 N 次连接主节点失败后，repmgrd 会在所有备节点中选举一个候选备节点（选举机制参考以下 Tips）提升为新主节点，然后其他备节点去 Follow 到该新主上，至此，形成一个新的集群状态。
Tips：
Repmgr 选举候选备节点会以以下顺序选举：LSN，Priority，Node_ID。
系统会先选举一个 LSN 比较大者作为候选备节点；如 LSN 一样，会根据 Priority 优先级进行比较，该优先级是在配置文件中进行参数配置；如优先级也一样，会比较节点的 Node ID，小者会优先选举。
Repmgr 高可用功能优化
Repmgr 作为流复制管理工具，在高可用方面还有一些不足之处：
内部没有提供对 Virtual IP 的管理和支持
高可用场景的完善优化
- Virtual IP 的支持
Virtual IP 作为应用程序连接集群的“纽带”，是需要绑定在主节点上的，且在集群发生 failover 时，能够“漂移”到新主节点上。
经过优化后的 Repmgr 可以提供以下对 Virtual IP 的支持：
注册主节点时，会绑定 Virtual IP
Failover 时，原主解绑 Virtual IP，新主重新绑定
集群节点重启时，会识别主接点然后绑定 Virtual IP
Switchover 时，Virtual IP 会随主节点进行漂移
- 高可用场景的完善优化
针对主节点出现故障，应用程序不能连接数据库服务，可以分为以下三种场景：
网络断开
系统掉电
外部存储掉线
<1> 网络断开
当集群主节点网络断开（网线被拔掉或者网卡坏掉）后，Repmgr 原来的机制是：备节点会有 N 次（配置参数）尝试机会去连接主节点，如果 N 次连接还是不成功，则 Repmgr 系统会认为主节点出现故障，开始进行 failover。failover 过程中，系统会选举一个备节点提升为新主节点，该过程中，Virtual IP 也会漂移到新主上去，其他备节点随后去 Follow 该新主节点。
但是现在需要注意的问题是：如果原来主节点网络恢复后，则它会以一个“非法”的主节点继续存在集群中。
针对该问题对 Repmgr 进行优化后:
在完成 failover 过程后，如果原来主节点网络恢复，则 repmgrd 守护进程会对原来主节点进行降级成备节点，然后重新“node rejoin”到集群里，即原来主节点会变成备节点角色重新加入集群，保证在 Failover 后，继续维持集群的节点数量。
<2> 系统掉电
所谓系统掉电的高可用就是指系统在掉电，然后再上电后，能继续维持集群所有节点的正常状态。这部分的实现，除了 Repmgr 流复制管理系统，还需要依赖数据库的启动脚本。
当主节点掉电后，failover 过程同断网一样，备节点在尝试 N 次连接主节点后没有成功时，Repmgr 系统选举出一个备节点进行提升为新主节点，Virtual IP 同样漂移到该新主节点上，随后其他备节点 follow 到新主节点上。
当 Failover 过程完成后，重新启动原主节点系统，系统会依次启动数据库服务，repmgrd 守护进程，接下来 repmgrd 守护进程同断网场景一样，对原主节点降级成备节点，然后重新加入到集群中去。
当然，备节点掉电后再上电，同样重新加入集群里去。
除了单个节点掉电，还有整个集群节点全部掉电的场景（其实这种场景在有些情况下出现的概率比单个节点掉电的概率还要高）。
整个集群都掉电后，不会发生 failover 过程。此时只需要对集群各个节点重新上电来恢复原来的集群状态。在恢复过程中，数据库系统依靠启动脚本会依次恢复数据库服务和 repmgrd 守护进程，在判断出主节点后，会重新绑定 Virtual IP。最后恢复为掉电前的集群状态。需要注意的是，由于 repmgrd 是依赖数据库服务启动的，特别是备节点的 repmgrd 需要依赖主节点的数据库服务。所以按逻辑，需要先启动主节点系统，然后再启动备节点系统。但经过优化后，可以按任意节点顺序启动恢复整个集群状态。
<3> 外部存储掉线
该场景应用在将数据库数据存储在挂载的外部存储上。当外部存储光纤掉线后，repmgrd 守护进程通过检测 $PGDATA 目录出现故障（只读或写 hang 住）后，会先停掉当前数据库服务（$PGDATA 出现问题后，数据库服务依然处于活动状态），以为 failover 过程做准备。当数据库服务停掉后，failover 过程就如掉电等过程一样。
当存储重新挂载或重启系统恢复正常后，原主节点同样会降级成备节点重新加入集群中去。
同异步转换场景的完善
在一主一备集群场景中，把备节点设置为同步备节点能够保证数据的安全可靠性，但是如果备节点如果出现断网或服务停掉的问题，则主节点写操作会 hang 住。为了解决上述问题，保证业务的连续性，增加了同异步转换的功能。
同步转异步
在备节点出现断网或停服务后，主节点通过 walsend 进程的状态判断同步备节点是否还正常（如果是断网问题，主节点会等待 wal_sender_timeout 之后做出判断），在判断备节点出现问题后，repmgrd 会再预留 timeout 时间检测备节点状态。超过 timeout 备节点没有恢复正常，主节点会通过修改 synchronous_standby_names 并 reload，来完成从同步模式转换为异步模式的过程。
异步转同步
在同步转异步后，如果备节点又恢复正常了，此时会进行恢复为原来的同步模式。具体实现为：在备节点恢复正常后，在 catchup 主节点的 LSN 延迟达到一个比较小的值时，主节点同样通过修改 synchronous_standby_names 参数并 reload，这样主节点就完成了从异步模式转换为同步模式的过程。
