关于数据库:KunlunDB的Fullsync高可用机制简介

6次阅读

共计 4054 个字符，预计需要花费 11 分钟才能阅读完成。

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 场景。

昆仑数据库是一个 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

正文完