KunlunBase的Fullsync高可用机制简介
前言
KunlunBase具备完善的容灾和错误处理机制，通过分布式事务两阶段提交算法，以及Fullsync和Fullsync HA机制，可以确保在集群运行期间任意计算节点、存储节点、cluster_mgr等组件发生宕机、重启等故障或者发生网络分区（network partition）或者断连时，集群管理的用户数据以及元数据都会是一致的和完整的，不会丢失用户已提交事务的任何数据更新，也不会发生事务部分提交部分回滚等不一致情况，以及发生用户的元数据与用户数据不一致等情况。
K 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的写入负载，下文将详述。
K 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的主节点选举和切换流程主要包括如下步骤：
- 在SS1 的所有备机中找到含有新relay log的备机M1作为候选主节点。
如果有多个新备机则按照更详细的规则选出合适的备机作为M1。
KunlunBase的Fullsync机制确保了集群有一个或者多个（fullsync_consistency_level) 备机一定含有所有已经向计算节点确认完成了提交的事务的binlog。
因此， KunlunBase 可以忍受主节点和fullsync_consistency_level - 1个备节点同时宕机的错误而不丢失已提交事务的数据。
- 待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可以及时收到备机延时过大的告警并且点一下按钮就完成了备机重做从而再次紧紧跟上主节点的步伐。
- 改变SS1的其他备机的主节点为M1
对于发生网络分区或者手动切换主节点的情况，如果旧的主节点M0 仍然可以写入，即M0没有发生宕机或者重启，那么cluster_mgr会在提升M1为主节点之前，先把M0 降级为备节点，设置其为只读状态，防止发生脑裂。
- 将“M1是SS1的主节点”这个事实告知所有计算节点，即更新它们的pg_shard.master_node_id字段，这样计算节点就可以及时获知并写入新主节点。
计算节点的主节点信息不是新的也无妨，我们对此有防御手段。
首先，任何kunlun-storage节点启动后都是只读状态，所以如果M0因为任何原因重启之后如果SS1已经完成了主备切换，那么重启之后M0无法被写入，即使有一些计算节点的主节点信息还没有及时更新从而仍然试图写入M0，这些写入操作也会失败，因此不会发生脑裂。
当计算节点发现它所知道的主节点无法写入时，如果此时cluster_mgr 还没有更新计算节点的pg_shard.master_nodeid字段，则计算节点会自动启动主节点探测程序，找到SS1的新的主节点。
在找到新主之前，计算节点会根据系统设置决定阻塞等待新主选举完成或者直接返回错误给客户端。因此可以保障主节点故障对业务无感知。
- 旧的主节点重新加入—闪回
如果旧主节点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场景。
点击阅读原文
推荐阅读
KunlunBase架构介绍
KunlunBase技术优势介绍
KunlunBase技术特点介绍
KunlunBase集群基本概念介绍
END
相关文章