人大金仓数据库KingbaseES repmgr之主备切换

金仓数据库KingbaseES ——

repmgr之主备切换

关键字：

KingbaseES、repmgr、主备切换、人大金仓、KingbaseES

背景

KES集群节点有三层结构：kbha、repmgr、kingbase，三层解构关系大概如下：

图1 集群节点进程结构

其中上层通过控制下层，来实现高可用的理念：kingbase进程通过内部函数或方法，形成数据库集群，形成节点信息的同步；repmgr通过控制kingbase进程的行为，确保数据库对外行为即便是在故障场景下，仍旧能按照预期尽可能提供服务；kbha进程则是为repmgr提供运行保证的，即：当repmgr故障时，kbha需要将repmgr进程拉起；同时当repmgr进程无法被拉起时，kbha也会有限地承担一部分repmgr工作。

从上述分析不难看出，repmgr是集群高可用实现的核心；同时在实际场景下集群的主备切换与repmgr同样密不可分。接下来本文将以主节点故障为切入点，介绍repmgr的集群主节点故障处理流程。

集群主节点故障处理——备机升主

当主节点故障时，首先需要考虑集群的trust _server是否在线，以及是否开启了running_under_failure_servers参数，如果集群trust_server不在线且开启了running_under_failure_servers，此时repmgr会停止运行，并由kbha会接管部分repmgr的功能。具体的后续文章会进行讲解，本文这里主要分析repmgr的行为。

主节点重连超时

repmgr执行重连超时主要是通过参数reconnect_attempts（）与reconnect_interval（）控制。当备节点发现主节点无法访问时，会进行间隔一共次的重试。但需要注意的是，理论上超时重传的耗时是，但实际上由于执行重传本身有一定耗时，因此执行的实际时间是大于的。在执行完这个流程仍旧无法访问主节点时，备节点会认为主节点已经掉线，切断walreceiver并获取当前存活的备节点ip。

准备升主

在上一步的基础上备节点根据自身的流复制状态决定是否参与升主的竞选，如果备节点在主机连接丢失前已经被标记为异步状态（async）则会直接失去竞选资格；接着会比较当前备机的LSN（可以理解为日志记录点），日志新的会优先升主，如果都一样则继续判断；接查看节点是否对原先的主节点可见，如果有节点对当前主节点可见则放弃升主；接着对比节点的优先级（Priority），该参数为手动设置，优先级大的优先升主；如果各节点优先级一致，则比较节点id（如node1，node2这种）节点id小的优先升主。

在选好升主的备节点后，还会判断当前节点可见的备节点数量是否达到总备节点数量的一般，如果不达到一半时则同样不会升主，该操作是为了避免少数节点因为网络故障而意外升主而进入双主深水区。

升主执行

升主流程是不可被中断的，一旦备机进入升主流程，原主此时即便可以访问也会被终止进程，进入降为备机的流程；如果此时原主不可访问，则直接跳过对原主的操作。

根据集群部署时是否配置了VIP，待升主的备机此时需要判断是否需要加载VIP，如果配置了，备机需要分析当前持有VIP的主机状态，如果VIP无法访问或VIP可以访问且为当前节点时，则进行升主同时时间线+1，完成后将原主标记为异步async状态。

如果此时VIP可以访问可以被卸载时，待升主的备机此时会卸载VIP持有节点的VIP，并加载至自身重试升主流程；但如果VIP无法卸载时，则会升主失败，陷入循环。

升主之后

执行升主之后，新主节点需要将其他节点接入自己的流复制槽（replication slot）内。当原主可达时，新主会使用对rewind原主进行降备操作，然后将节点流复制状态恢复为集群默认状态。

小结

本文从高可用集群主节点的角度介绍了repmgr执行的流程。repmgr实际上执行的内容远不止这些，感兴趣的同事可以参考更多相关的repmgr手册，此处仅做抛砖引玉，不再过多赘述。