前言
KunlunDB具备欠缺的容灾和错误处理机制，通过分布式事务两阶段提交算法，以及Fullsync和Fullsync HA机制，能够确保在集群运行期间任意计算节点、存储节点、cluster_mgr等组件产生宕机、重启等故障或者产生网络分区（network partition）或者断连时，集群治理的用户数据以及元数据都会是统一的和残缺的，不会失落用户已提交事务的任何数据更新，也不会产生事务局部提交局部回滚等不统一状况，以及产生用户的元数据与用户数据不统一等状况。
KunlunDB基于两阶段提交协定实现牢靠的分布式事务处理，确保在集群任意多个节点故障时，集群数据完全一致，保障所有事务的ACID 。
这一块具体内容请见这里（分布式事务处理两阶段提交机制和原理）和这里（分布式事务对于两阶段提交的错误处理），而kunlun-storage的Fullsync机制在这里介绍过（昆仑分布式数据库存储集群 Fullsync 机制）。
本文具体介绍Fullsync高可用机制，下文简称Fullsync HA。
KunlunDB的Fullsync机制确保一个kunlun-storage的storage shard（存储集群）在提交任何一个事务实现后并且返回给客户端胜利确认之前，必须收到fullsync_consistency_level个备机的ACK确认收到了这个事务的binlog。
计算节点只有收到存储节点的提交胜利确认，才会返回给KunlunDB的客户端利用，因而才有任务保障这些事务的持久性（durability），否则就没有这样的任务。
如果主节点和最多fullsync_consistency_level-1个备节点同时宕机，依然有1个备节点（fullsync_consistency_level>1时）含有全副已确认提交的事务的binlog，所以这些事务的更新不会失落。
KunlunDB的Fullsync HA确保任何kunlun-storage存储集群产生主节点故障或者网络分区，都能够及时发现这些谬误并且及时选举新的主节点持续承当这个storage shard的写入负载，下文将详述。
KunlunDB的Fullsync和Fullsync HA机制确保了只有一个含有2*N+1个节点的kunlun-storage存储shard只有还有N+1个节点在运行，这个shard就能够继续写入。
这里的N就是kunlun-storage的fullsync_consistency_level。
KunlunDB的fullsync和fullsync HA机制实现了等价于Raft协定的高可用机制，能够确保一个KunlunDB集群的每个存储shard的主节点能够有一个或者多个备节点与主节点数据同步。
对于fullsync_consistency_level=N（N > 1) 的一个或者多个fullsync存储shard来说，即便这些存储shard的主节点和N-1个备机同时产生任何故障或者网络断连隔离等等问题，KunlunDB能够确保这些shard数据不失落并且与集群其余存储shard保持数据一致性，并且KunlunDB会主动选出新的主节点并且提供读写能力。
主节点探活
KunlunDB的Fullsync HA确保主节点宕机、重启或者产生网络分区（network partition）后，能够主动启动选主流程，实现主备切换，保障存储集群继续可用。
为了确认每一个storage shard的主节点可用，cluster_mgr模块会距离N秒继续向每一个storage shard的主节点写入心跳来探测其主节点的可用性。
如果发现某个storage shard（标记为 SS1）的主节点M0继续肯定工夫不能写入，就会启动下文形容的选主和主备切换流程。
M0如果重启的足够快那么并不会引发主备切换，cluster_mgr会设置其可写，从而M0能够持续负责主节点，否则，cluster_mgr就会启动如下的选主和切换流程。
主节点选举和切换
KunlunDB的Fullsync HA的主节点选举和切换流程次要包含如下步骤：
- 在SS1 的所有备机中找到含有最新relay log的备机M1作为候选主节点。
如果有多个最新备机则依照更具体的规定选出最合适的备机作为M1。
KunlunDB的Fullsync机制确保了集群有一个或者多个（fullsync_consistency_level) 备机肯定含有所有曾经向计算节点确认实现了提交的事务的binlog。
因而，KunlunDB能够忍耐主节点和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须要耗费较长的工夫，这段时间内任何备机无奈晋升为主节点。
为了防止此类非凡状况呈现，咱们为KunlunDB开发了十分便当的备机重做接口和备机延时告警机制，确保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机制，KunlunDB能够确保齐备的数据一致性保障和容灾能力，并实现了高可靠性和高可用性，同时也提供了极高的性能，能够胜任高并发重负载的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/ 获取更多信息并且下载昆仑数据库软件、文档和材料。
KunlunDB我的项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb