KunlunBase 的 Fullsync 高可用机制简介

前言

KunlunBase 具备完善的容灾和错误处理机制，通过分布式事务两阶段提交算法，以及 Fullsync 和 Fullsync HA 机制，可以确保在集群运行期间任意计算节点、存储节点、cluster_mgr 等组件发生宕机、重启等故障或者发生网络分区（network partition）或者断连时，集群管理的用户数据以及元数据都会是一致的和完整的，不会丢失用户已提交事务的任何数据更新，也不会发生事务部分提交部分回滚等不一致情况，以及发生用户的元数据与用户数据不一致等情况。

KunlunBase 基于两阶段提交协议实现可靠的分布式事务处理，确保在集群任意多个节点故障时，集群数据完全一致，保障所有事务的 ACID 。

这一块详细内容请见这里（分布式事务处理两阶段提交机制和原理）和这里（分布式事务对于两阶段提交的错误处理），而 kunlun-storage 的 Fullsync 机制在这里介绍过（昆仑分布式数据库存储集群 Fullsync 机制）。

本文详细介绍 Fullsync 高可用机制，下文简称 Fullsync HA。

KunlunBase 的 Fullsync 机制确保一个 kunlun-storage 的 storage shard（存储集群）在提交任何一个事务完成后并且返回给客户端成功确认之前，必须收到 fullsync_consistency_level 个备机的 ACK 确认收到了这个事务的 binlog。

计算节点只有收到存储节点的提交成功确认，才会返回给 KunlunBase 的客户端应用，因此才有义务保障这些事务的持久性（durability），否则就没有这样的义务。

如果主节点和最多 fullsync_consistency_level-1 个备节点同时宕机，仍然有 1 个备节点（fullsync_consistency_level>1 时）含有全部已确认提交的事务的 binlog，所以这些事务的更新不会丢失。

KunlunBase 的 Fullsync HA 确保任何 kunlun-storage 存储集群发生主节点故障或者网络分区，都可以及时发现这些错误并且及时选举新的主节点继续承担这个 storage shard 的写入负载，下文将详述。

KunlunBase 的 Fullsync 和 Fullsync HA 机制确保了只要一个含有 2*N+1 个节点的 kunlun-storage 存储 shard 只要还有 N+1 个节点在运行，这个 shard 就可以持续写入。

这里的 N 就是 kunlun-storage 的 fullsync_consistency_level。

KunlunBase 的 fullsync 和 fullsync HA 机制实现了等价于 Raft 协议的高可用机制，可以确保一个 KunlunBase 集群的每个存储 shard 的主节点可以有一个或者多个备节点与主节点数据同步。

对于 fullsync_consistency_level=N（N > 1) 的一个或者多个 fullsync 存储 shard 来说，即使这些存储 shard 的主节点和 N-1 个备机同时发生任何故障或者网络断连隔离等等问题，KunlunBase 可以确保这些 shard 数据不丢失并且与集群其他存储 shard 保持数据一致性，并且 KunlunBase 会自动选出新的主节点并且提供读写能力。

主节点探活

KunlunBase 的 Fullsync HA 确保主节点宕机、重启或者发生网络分区（network partition）后，可以自动启动选主流程，完成主备切换，保障存储集群持续可用。

为了确认每一个 storage shard 的主节点可用，cluster_mgr 模块会间隔 N 秒持续向每一个 storage shard 的主节点写入心跳来探测其主节点的可用性。

如果发现某个 storage shard（标记为 SS1）的主节点 M0 持续一定时间不能写入，就会启动下文描述的选主和主备切换流程。

M0 如果重启的足够快那么并不会引发主备切换，cluster_mgr 会设置其可写，从而 M0 可以继续担任主节点，否则，cluster_mgr 就会启动如下的选主和切换流程。

主节点选举和切换

KunlunBase 的 Fullsync HA 的主节点选举和切换流程主要包括如下步骤：

1. 在 SS1 的所有备机中找到含有最新 relay log 的备机 M1 作为候选主节点。

如果有多个最新备机则按照更详细的规则选出最合适的备机作为 M1。

KunlunBase 的 Fullsync 机制确保了集群有一个或者多个（fullsync_consistency_level) 备机一定含有所有已经向计算节点确认完成了提交的事务的 binlog。

因此，KunlunBase 可以忍受主节点和 fullsync_consistency_level - 1 个备节点同时宕机的错误而不丢失已提交事务的数据。

2. 待 M1 的 relay log 重放完毕后，将 M1 提升为 SS1 的主节点。

MySQL-8.0 具备了 writeset 事务依赖检查机制（binlog_transaction_dependency_tracking=writeset 或者 writeset_session)，可以让 MySQL 备机重放速度在 replica_parallel_type=logical_clock 时比 mysql-5.7 更快。通常情况下主备延迟都只有几秒钟。

但是如果用户数据表设计和使用不合理，比如没有定义主键和唯一索引的情况先执行大量行更新或者删除语句（即使每个语句只改/删了少量行），则会导致备机重放（replay）binlog 的延时较大，在这种特殊情况下重放完毕所有的 relay log 需要消耗较长的时间，这段时间内任何备机无法提升为主节点。

为了避免此类特殊情况出现，我们为 KunlunBase 开发了非常便利的备机重做接口和备机延时告警机制，确保 DBA 可以及时收到备机延时过大的告警并且点一下按钮就完成了备机重做从而再次紧紧跟上主节点的步伐。

3. 改变 SS1 的其他备机的主节点为 M1

对于发生网络分区或者手动切换主节点的情况，如果旧的主节点 M0 仍然可以写入，即 M0 没有发生宕机或者重启，那么 cluster_mgr 会在提升 M1 为主节点之前，先把 M0 降级为备节点，设置其为只读状态，防止发生脑裂。

4. 将“M1 是 SS1 的主节点”这个事实告知所有计算节点，即更新它们的 pg_shard.master_node_id 字段，这样计算节点就可以及时获知并写入新主节点。

计算节点的主节点信息不是最新的也无妨，我们对此有防御手段。

首先，任何 kunlun-storage 节点启动后都是只读状态，所以如果 M0 因为任何原因重启之后如果 SS1 已经完成了主备切换，那么重启之后 M0 无法被写入，即使有一些计算节点的主节点信息还没有及时更新从而仍然试图写入 M0，这些写入操作也会失败，因此不会发生脑裂。

当计算节点发现它所知道的主节点无法写入时，如果此时 cluster_mgr 还没有更新计算节点的 pg_shard.master_nodeid 字段，则计算节点会自动启动主节点探测程序，找到 SS1 的新的主节点。

在找到新主之前，计算节点会根据系统设置决定阻塞等待新主选举完成或者直接返回错误给客户端。因此可以保障主节点故障对业务无感知。

5. 旧的主节点重新加入---闪回

如果旧主节点 M0 之后某个时间重新完成启动，那么 cluster_mgr 会把它作为备机重新加入 SS1 这个 storage shard。

由于 Fullsync 机制使用 after commit 模式等待备机 ACK，所以 M0 中可能有一些已经在 M0 本季提交但是没有收到任何 ACK 的事务，这些事务都需要备闪回掉。

kunlun-storage 的闪回插件会在启动后完成闪回，以确保随后的备机复制可以正常运行。

闪回操作主要做的就是对于这些多余的事务执行的行操作做相反的操作，将其改动去除掉，并且切除多余的 binlog 文件，并且从 mysql.gtid_executed 系统表中把那些被闪回的事务的 gtid 去掉。

最后，kunlun-storage FullsyncHA 有一套实用的措施来避免在极端情况下产生不必要的主备切换。

这通常是在写入负载极重的情况下容易发生，因此不必要的主备切换容易引起系统负载最重的情况下性能下降甚至短暂不可用，因而是需要极力避免的问题。

我们基于多年丰富的现网开发和运维经验，以及对 MySQL 内核相关技术的深入理解，实现了一整套逻辑可以识别和避免不必要的主备切换。

通过分布式事务处理以及 Fullsync 和 Fullsync HA 机制，KunlunBase 可以确保完备的数据一致性保障和容灾能力，并实现了高可靠性和高可用性，同时也提供了极高的性能，可以胜任高并发重负载的 OLTP 场景。

END

昆仑数据库是一个 HTAP NewSQL 分布式数据库管理系统，可以满足用户对海量关系数据的存储管理和利用的全方位需求。应用开发者和 DBA 的使用昆仑数据库的体验与单机 MySQL 和单机 PostgreSQL 几乎完全相同，因为首先昆仑数据库支持 PostgreSQL 和 MySQL 双协议，支持标准 SQL:2011 的 DML 语法和功能以及 PostgreSQL 和 MySQL 对标准 SQL 的扩展。同时，昆仑数据库集群支持水平弹性扩容，数据自动拆分，分布式事务处理和分布式查询处理，健壮的容错容灾能力，完善直观的监测分析告警能力，集群数据备份和恢复等 常用的 DBA 数据管理和操作。所有这些功能无需任何应用系统侧的编码工作，也无需 DBA 人工介入，不停服不影响业务正常运行。昆仑数据库具备全面的 OLAP 数据分析能力，通过了 TPC-H 和 TPC-DS 标准测试集，可以实时分析最新的业务数据，帮助用户发掘出数据的价值。昆仑数据库支持公有云和私有云环境的部署，可以与 docker，k8s 等云基础设施无缝协作，可以轻松搭建云数据库服务。请访问 http://www.zettadb.com/ 获取更多信息并且下载昆仑数据库软件、文档和资料。

KunlunBase 项目已开源

【GitHub：】https://github.com/zettadb

【Gitee：】https://gitee.com/zettadb