关于mysql:高可用-Xenon后-MHA-时代的选择

48次阅读

共计 1985 个字符,预计需要花费 5 分钟才能阅读完成。

MySQL 高可用的抉择

在 MySQL(5.5 及以下)传统复制的时代,MHA(Master High Availability)在 MySQL 高可用利用中十分成熟。在 MySQL(5.6)及 GTID 时代开启当前,MHA 却没有与新的 MySQL 一起适应时潮。

MHA 由日本 DeNA 公司 youshimaton 开发,他认为在 GTID 环境下 MHA 存在的价值不大,MHA 最近一次发版是 2018 年。现如今应用 MySQL 已离不开 GTID,无论是从性能、性能角度,还是从保护角度,GTID 能具备更优异的体现,针对数据业务要求不高场景,常应用 GTID+ROW+Semi-Sync 计划。


(图为 MHA 活跃度)

基于 MHA 和 GTID 倒退现状,为适应 MySQL 版本更新的高可用业务场景,上面介绍一款可代替 MHA 的高可用计划:MySQL + Xenon

什么是 Xenon?

Xenon [ˈziːnɒn] (https://github.com/radondb/xe… 是一款由 RadonDB 开发团队研发并开源的新一代 MySQL 集群高可用工具。基于 Raft 协定进行无中心化选主,实现主从秒级切换;基于 Semi-Sync 机制,保障数据不失落,实现数据强一致性。并联合 MySQL(5.7 及以上版本)并行复制个性,实现 Binlog 并行回放,大大降低从库提早。

Xenon 架构


主动选主

基于 Raft(依赖于 GTID)主动选主,数据一致性依赖于加强半同步 Semi-Sync。

故障主动切换

借助于配置项 leader-start-command 和 leader-stop-command 调用脚本实现故障切换,也能够联合 Consul,ZooKeeper 自在扩大。

Xtrabackup 备份调度集成

Xenon 工作原理

联合架构图,可看出 Xenon 就是基于 Raft + Semi-Sync + GTID 实现的高可用,保障大多数节点接管到数据。

而 Raft 基于心跳治理,如果从节点超时收不到主的心跳,会尝试发动选举,若失去超过半数(非 IDLE 节点)的选票,则会入选为主节点。

上面以三节点(一主两从)Xenon 集群来简略阐明工作原理。

{Leader, [GTID:{1,2,3,4,5}]

{Follower1, [GTID:{1,2,3,4,5}]

{Follower2, [GTID:{1,2,3}]

当 Leader 不可用时,Follower1 和 Follower2 立刻参加竞选成为主节点。

Xenon 校验 GTID 值较高的 Follower 成为新主节点,示例中 GTID 值较高的是 Follower1。

当 GTID 值最高的 Follower 被选举成为新主时,将完结竞选。示例中 Follower1 成为新主节点后,将会回绝 Follower2 的选举。

主动实现主从切换。

Xenon 企业级外围个性

一主多从架构,确保金融级强一致性

高可用架构大多采纳一主两从的初始节点架构设计,并通过 MySQL 5.7 版本中的 Semi-Sync 个性实现数据的多正本同步复制,多个从节点的设置将极大的屏蔽掉单点故障带来的影响,确保至多一个从节点与主节点始终保持数据的完全一致,提供金融级数据强一致性。

主正本秒级切换,确保业务高可用

节点之间应用 Raft 协定进行治理,当主节点呈现故障不可用时,集群会秒级响应并选出新的主节点(与主节点数据齐全同步的从节点),并立刻接管读写申请,确保业务的间断高可用。这一过程,无需设置后端集群中各节点的角色,所有由零碎主动切换。集群中最多能够增加 6 个从节点,主节点可读可写,从节点设置为只读。同时,集群提供两个 VIP,别离是高可用读 IP 和高可用写 IP。读 IP 可将申请在所有节点之间进行负载分担,提供读取性能的同时,也打消了单点故障的影响,提供业务可靠性。写 IP 则始终指向主节点(Leader)。

零碎主动运维,优化零碎空间应用效率

通过对 binlog 日志的保留周期 expire_logs_days 的配置(1~4 天),主节点会定期清理不再应用的 binlog 日志,其余从节点已复制结束,进步零碎的空间利用率。

Xenon 的劣势

相比 MHA,Xenon 的劣势如下:

多版本内核反对

反对 MySQL 5.6、5.7、8.0 内核版本。

多平台反对

反对物理机、虚拟机 / 云平台、容器 / Kubernetes 平台部署。

稳定性更好

MySQL 新版本个性兼容。

性能更佳

与 GTID、MTS(并行复制)联合,并行日志复制、并行日志回放。

架构更简略

不须要治理节点,机器老本更低。

数据更平安

加强半同步复制不会降级为异步,保证数据零失落,不会存在 MHA 在 GTID 模式下丢数据的危险。

故障修复全自动

Xenon 对于故障节点会主动先自我修复。

节点复原快

配合 Xtrabackup 等能够实现疾速复原。

操作更简略,保护老本更低

继续更新

Xenon 由 RadonDB 数据库开发团队继续保护更新。

相干参考

https://github.com/radondb/xe…

正文完
 0