「瀚高数据库技术栈」瀚高高可用软件DB_HA（介绍篇）

DB_HA简介

在介绍db_ha之前，我们先来聊一个大家常提的一个词---“高可用”。所谓高可用（High Availability）是指一个系统经过专门的设计，从而减少停工时间，以保持其服务的延续性。高可用所追求的理想状态是“永不宕机，永不停服”，当然在实际生产过程中这种理想状态是不存在的，系统的设计也仅在最大范围内以达到理想状态。

而数据库集群的生产场景中，通常会遭遇各种异常（主备数据库节点断网、断电、人为损坏、机器故障等），导致集群无法正常对外服务而引起的应用连接中断，使得程序宕机等。为了实现集群快速恢复，防止业务被中断，数据库高可用管理产品是不可或缺的。

瀚高高可用软件（以下简称db_ha）是基于WAL日志同步方案的高可用架构，支持瀚高全系列数据库和PostgreSQL（9.x-12.x）版本。具有高效的业务恢复能力，保障RTO（恢复时间目标）小于8秒，即从灾难状态恢复到可运行状态时间8秒；保证RP0等于0，即切换时向前恢复的数据的时间长度为0，实现切换前后数据0丢失。

DB_HA架构

db_ha是基于流复制建立主从关系的高可用组件，它通过动态监测机制轮询获取数据库状态，采用冗余备份和失效转移的手段，保证服务和数据的高可用性。db_ha支持同步和异步的数据备份模式，可以在两种模式间自由切换。同时，db_ha会记录集群的实时状态，故障转移机制将根据集群各节点状态触发相应的故障机制，且具有更加全面的VIP管理模式，提供主备节点虚拟IP接口。基本架构图如下：

宽松部署：primary monitor与secondary monitor均部署在数据库集群之外。

一般部署：secondary monitor部署在数据库集群中的备节点上，primary monitor部署在数据库集群之外。（备库所在的服务器称为备节点。）

紧凑部署：primary monitor与secondary monitor均部署在数据库集群内的备节点上。

极限部署：primary monitor部署在备节点上，secondary monitor部署在主节点上。

DB_HA产品功能

主备切换：集群中某个只读备库和主库的数据库角色互换，绑定的VIP随之漂移。

db_ha提供了主备切换的功能，将只读备库与主库角色互换，并将绑定的VIP互换，适用于各种原因需更换维护主库等情况。

故障转移：当活动的服务意外终止时，快速启用冗余或备用的服务器接替它工作。

db_ha的故障转移对降低RTO和保证RPO等于0起关键作用，有效的保证了集群的可用性和业务恢复能力。

增减备节点：db_ha可在线增减备节点

 db_ha通过tools指定不同选项发起添加备节点命令，支持添加空数据节点、已有部分数据节点和失效主节点等多种情形。

db_ha剔除备节点由tools发起，将剔除备节点的数据库关闭，并将VIP漂移至其他节点。

防脑裂检测机制：db_ha具有安全可靠的防脑裂检测机制，不依赖第三方软件，可有效的防止集群出现两个主节点的情况，杜绝脑裂的产生。

该处理由agent完成：当primary_monitor超过一定时间没有与agent发生心跳检测的通信时，节点的agent会判定本机与primary_monitor失联，并解绑VIP，停止本机数据库的对外服务。

自动剔除异常节点：节点异常时，primary_monitor会自动将其剔除集群。

primary_monitor将异常节点的VIP漂移到绑定VIP较少的备节点，若无备节点，则将VIP漂移到主节点。primary_monitor将该节点标记为异常状态，并开始对其进行状态监测。

剔除节点自动回归

对于由primary_monitor自动剔除的节点，primary_monitor会将其标记为异常状态，并定期对其进行状态检测。待节点恢复正常后，primary_monitor会自动将其加入集群。异常备节点回归时，其同步模式会被设置成失效前的状态；异常主节点回归后，其同步模式会被设置成异步模式。

手工添加剔除的节点

若一个节点出现异常但经过维修已恢复正常，则需要经过一定时间后才能自动回归集群。管理员可以使用添加节点的命令直接将该节点回归集群，以尽早提供服务。但先前绑定在该节点的VIP不会自动漂移回来，需要手工操作。

丰富的集群状态展示

通过tools工具的select命令，可以获得当前集群规模、secondary monitor的状态、各数据节点的流复制信息（节点类型、应用名、流复制类型、流复制状态）和健康程度、各agent的状态。

主监控的高可用

db_ha的primary monitor在整个高可用中权重较大，为避免因primary monitor故障导致db_ha失效，我们在secondary monitor引入primary monitor的失效检测处理逻辑。secondary monitor检测到与primary monitor失去连接，产生告警，启动新的primary monitor，继续为集群提供高可用服务。

当集群只剩两个节点且primary monitor部署在其中一个节点的上时，如果另一个节点失联，primary monitor无法判断此时是自己失联还是其他节点失联，考虑到管理员可能在此台机器使用db_ha工具，这时用db_ha查询集群状态会返回WARNING: the machine on which the primary monitor resides may lose its network connection,please check的警告，提醒人工检查网络状态。

对外开放的扩展接口

db_ha仅用于提供高可用服务，然而某些集群上除了流复制有时又会有一些其他的设置，对此db_ha提供了额外的对外开放的扩展接口，在发生主备切换或故障转移后，可以在新主提升成功绑定VIP前，设置是否需要执行一些指令，以便进行一些额外的操作。当前支持shell脚本和sql指令。

例如，逻辑复制扩展接口：扩展接口在高可用集群中与逻辑复制进行了有效的衔接。传统的高可用集群中，在集群状态发生变化后，新主库上没有逻辑复制槽从而无法继续进行逻辑复制。通过该扩展接口，不断检测主节点状态，当主节点处于正常服务状态后，执行指令，在新主节点完成创建复制槽操作，以保障逻辑复制继续工作；在原主库上删除逻辑复制槽，以防止日志暴增。整个过程，保障了逻辑复制的断点续传。

VIP管理

db_ha提供丰富的VIP（虚拟IP）管理功能，支持绑定单个/多个VIP、解绑单个/多个VIP。为保证特殊情形下（例如db_ha指定某服务器绑定VIP，成功后该服务器上的agent崩溃，后经运维人员手工启动了一个新的agent）agent能够获得已绑定过的VIP以便在与primary_monitor失联时解绑所有的VIP，所有绑定过的VIP都会被记录在临时文件中。

同步降级

传统流复制集群中，WAL 日志传输模式有同步和异步两种模式。在实际生产过程中，常常会遇到服务器软硬件故障、网络抖动、服务器资源紧张等导致备节点无法和主节点保持同步模式。按照流复制集群现有的机制，在这些场景下会导致主节点出现挂起，不能继续提供服务，会严重影响到业务连续性。db_ha的自动同步降级功能，可以规避现有同步机制异常对业务连续性带来的潜在风险。瀚高系列数据库自带流复制增强功能，在开启情况下，db_ha同步降级功能不会生效。若数据库无流复制增强功能或未开启，在同步流复制异常时，db_ha会结合用户的配置，通过自动修改synchronous_standby_names参数的方式，转化为异步流复制模式。

配置信息全局备份

集群中与节点有关的配置信息，不仅保存在primary_monitor和secondary_monitor所在的机器上，还会同时保存到主库中，跟随流复制备份到各个备节点。可作为负载均衡组件的配置信息使用。

日志等级灵活设置

通过设置配置文件中的日志等级，primary monitor可以设置哪些日志记录到日志文件中。通过设置配置文件中的日志等级，agent和secondary monitor可以设置哪些日志记录到日志文件中，哪些日志打印在命令行屏幕上。

支持瀚高块修复软件

通过设置配置文件中的开关和全路径文件名，db_ha可以将块修复所需信息写入各个数据节点的预设文件。关于与瀚高块修复（db_blockguard）相关的内容，请参阅相关文档。

DB_HA技术特点

统一的集群管理命令：可由tools工具对集群发起一系列操作实现查看集群状态；添加、删除节点；主备切换；同异步切换；添加、删除VIP等一系列操作。

防脑裂机制:集群不会出现因主备间网络断开（特别是网络抖动的情况下）出现的双主现象

高效的自动故障转移：主节点因断网、断电或其他原因导致的数据库服务失败，可以自行选取新的主节点提供对外服务，RTO小于8秒，RPO等于0

统一管理集群VIP：完善的VIP管理模式：db_ha提供数据库VIP服务，当数据库服务器发生切换时，用户端的访问地址保持不变，重新连接即可恢复数据库服务；db_ha支持在主备节点配置VIP，并对所有VIP进行统一管理，支持主备VIP的自动漂移，支持利用tools工具添加、删除VIP。

智能的同步后备列表控制策略：自动修改同步复制的后备服务器列表，将失效的同步备节点转为异步模式，有效的防止备节点失效的情况下，主节点数据操作被挂住的情况。

快速的故障转移处理：针对主节点故障的情况，db_ha会根据集群目前存在备机的数量，选择不同的故障转移策略，保证集群快速恢复对外服务。并提供故障节点恢复后自动加入集群功能。

可靠的告警系统：能够及时反馈异常信息

轻量级架构：db_ha采用轻量级架构，不依赖任何插件或第三方组件，对性能影响最小。