原创：知数堂

| 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 和 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}]

1. 当 Leader 不可用时，Follower1 和 Follower2 立刻参加竞选成为主节点。
2. Xenon 校验 GTID 值较高的 Follower 成为新主节点，示例中 GTID 值较高的是 Follower1。
3. 当 GTID 值最高的 Follower 被选举成为新主时，将完结竞选。示例中 Follower1 成为新主节点后，将会回绝 Follower2 的选举。
4. 主动实现主从切换。

| 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…

https://www.fatalerrors.org/a…

https://github.com/yoshinorim

https://code.google.com/archi…

https://dev.mysql.com/doc/ref…

| 预报

下一篇 Xenon 主题文章，搭建一套 Xenon+MySQL 高可用架构集群。

对于 RadonDB

RadonDB 开源社区是一个面向云原生、容器化的数据库开源社区，为数据库技术爱好者提供围绕支流开源数据库（MySQL、PostgreSQL、Redis、MongoDB、ClickHouse 等）的技术分享平台，并提供企业级 RadonDB 开源产品及服务。

目前 RadonDB 开源数据库系列产品已被 光大银行、浦发硅谷银行、哈密银行、泰康保险、太平保险、安盛保险、阳光保险、百年人寿、安吉物流、安畅物流、蓝月亮、天财商龙、罗克佳华、升哲科技、无锡汇跑体育、北京电信、江苏交通控股、四川航空、昆明航空、国控生物 等上千家企业及社区用户采纳。

RadonDB 可基于云平台与 Kubernetes 容器平台交付，不仅提供笼罩多场景的数据库产品解决方案，而且提供业余的集群治理和自动化运维能力，次要性能个性包含： 高可用主从切换、数据强一致性、读写拆散、一键装置部署、多维指标监控 & 告警、弹性扩容 & 缩容、横向自在扩大、主动备份 & 复原、同城多活、异地灾备 等。RadonDB 仅需企业及社区用户专一于业务层逻辑开发，无需关注集群高可用选型、治理和运维等简单问题，帮忙企业及社区用户大幅度晋升业务开发与价值翻新的效率！

GitHub:

https://github.com/radondb

微信群： 请搜寻增加群助手微信号 radondb