轻量级流复制管理工具Repmgr高可用功能的优化

转载自：https://www.modb.pro/db/11339 《轻量级流复制管理工具Repmgr高可用功能的优化》

Repmgr功能概述

Repmgr作为由第二象限开发的一款流复制管理工具，具有非常轻量级的使用特性。具体表现为：

* 配置操作简单，可一键式完成相关部署操作；
* 支持Auto Failover和Manual Switchover；
* 分布式管理集群节点，易扩展，可在线增删集群节点；
* Repmgr流复制管理系统有repmgr和repmgrd两个命令。
* 其中repmgr命令实现对集群节点的管理，如注册主/备节点、Clone节点，Promote节点，Follow节点以及Switchover操作等；
* repmgrd命令用来启动repmgr系统的守护进程，用以对集群节点的监控。

下图是Repmgr实现架构图。

Repmgr流复制管理工具对集群节点的管理是基于一个分布式的管理系统。每个节点都有自己的repmgr.conf配置文件，用来记录本节点的ID,节点名称，连接信息，数据库PGDATA目录等配置参数。在配置好这些参数后，就可以通过repmgr命令实现对集群节点的“一键式”部署。

主节点：

1. 配置好相关参数
2. 启动数据库
3. 利用“repmgr primary register”命令实现对主节点的注册。
（该注册的目的是把配置文件的一些主要参数写到元数据表中，以便repmgr系统对集群节点的识别操作等。）
4. 启动repmgrd守护进程。

备节点：

1. 配置好相关参数
2. 利用“repmgr standby clone”命令对主节点进行物理拷贝。
3. 启动数据库
4. 利用“repmgr standby register”命令实现对备节点的注册。
5. 启动repmgrd守护进程。

部署完成后，每个节点都有自己的元数据表，记录所有集群节点的信息；每个节点都有自己的repmgrd守护进程来监控节点数据库状态。其中主节点守护进程主要用来监控本节点数据库服务状态，备节点守护进程主要用来监控主节点和本节点数据库服务状态。在发生Auto Failover时，备节点在尝试N次连接主节点失败后，repmgrd会在所有备节点中选举一个候选备节点（选举机制参考以下Tips）提升为新主节点，然后其他备节点去Follow到该新主上，至此，形成一个新的集群状态。

Tips：

Repmgr选举候选备节点会以以下顺序选举：LSN ， Priority， Node_ID。
系统会先选举一个LSN比较大者作为候选备节点；如LSN一样，会根据Priority优先级进行比较，该优先级是在配置文件中进行参数配置；如优先级也一样，会比较节点的Node ID，小者会优先选举。

Repmgr高可用功能优化
Repmgr作为流复制管理工具，在高可用方面还有一些不足之处：

* 内部没有提供对Virtual IP的管理和支持
* 高可用场景的完善优化

1. Virtual IP的支持

Virtual IP作为应用程序连接集群的“纽带”，是需要绑定在主节点上的，且在集群发生failover时，能够“漂移”到新主节点上。
经过优化后的Repmgr可以提供以下对Virtual IP的支持：
注册主节点时，会绑定Virtual IP
Failover时，原主解绑Virtual IP，新主重新绑定
集群节点重启时，会识别主接点然后绑定Virtual IP
Switchover时，Virtual IP会随主节点进行漂移

2. 高可用场景的完善优化

针对主节点出现故障，应用程序不能连接数据库服务，可以分为以下三种场景：
* 网络断开
* 系统掉电
* 外部存储掉线

<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，这样主节点就完成了从异步模式转换为同步模式的过程。