| 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/xenon) 是一款由 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/xenon/tree/master/docs https://www.fatalerrors.org/a/separation-of-mha-atlas-for-mysql-high-availability.html https://github.com/yoshinorim https://code.google.com/archive/p/mysql-master-ha/ https://dev.mysql.com/doc/refman/5.6/en/replication-gtids-concepts.html
| 预告
下一篇 Xenon 主题文章，搭建一套 Xenon MySQL 高可用架构集群。
关于 RadonDB
RadonDB 开源社区是一个面向云原生、容器化的数据库开源社区， 为数据库技术爱好者提供围绕主流开源数据库（MySQL、PostgreSQL、Redis、MongoDB、ClickHouse 等）的技术分享平台，并提供企业级 RadonDB 开源产品及服务。
目前 RadonDB 开源数据库系列产品已被 光大银行、浦发硅谷银行、哈密银行、泰康保险、太平保险、安盛保险、阳光保险、百年人寿、安吉物流、安畅物流、蓝月亮、天财商龙、罗克佳华、升哲科技、无锡汇跑体育、北京电信、江苏交通控股、四川航空、昆明航空、国控生物 等上千家企业及社区用户采用。
RadonDB 可基于云平台与 Kubernetes 容器平台交付，不仅提供覆盖多场景的数据库产品解决方案，而且提供专业的集群管理和自动化运维能力，主要功能特性包括：高可用主从切换、数据强一致性、读写分离、一键安装部署、多维指标监控&告警、弹性扩容&缩容、横向自由扩展、自动备份&恢复、同城多活、异地灾备 等。RadonDB 仅需企业及社区用户专注于业务层逻辑开发，无需关注集群高可用选型、管理和运维等复杂问题，帮助企业及社区用户大幅度提升业务开发与价值创新的效率！
GitHub: 原文链接可达
https://github.com/radondb
