MySQL 常用高可用方案

1 主从或主主 + Keepalived

• 部署简单。
• 只有两个节点，没有主实例宕机后选主的问题。

• 级联复制或者一主多从在切换之后，其他从实例需要重新配置连接新主。
• 云环境使用不了。

2 MHA

• 可以根据需要扩展 MySQL 的节点数量。
• 只要复制没有延迟，MHA 通常可以在几秒内实现故障切换。
• 可以使用任何存储引擎。

• 仅监视主数据库。
• 需要做 SSH 互信
• 使用 Perl 开发，二次开发困难。
• 跟不上 MySQL 新版本，最近一次发版是 2018 年。

3 PXC

• 去中心：任何节点宕机，集群都可以继续运行而不会丢失任何数据。
• 每个节点都可以写入数据并自动同步到其他节点。
• 数据写入需要集群所有节点验证通过才会提交，保证了数据的强一致性。

• 只支持 InnoDB 引擎。
• 木桶效应：集群吞吐量取决于性能最差的节点。
• 增加节点时，必须从现有节点之一复制完整的数据集。

4 MGR/InnoDB Cluster

• MySQL Shell，MySQL 的高级客户端和代码编辑器，用于管理 MGR 集群。
• Group Replication，提供一组高可用的 MySQL 实例。
• MySQL Router，在应用程序和集群之间提供透明的路由。当 MGR 发生切换树，自动路由到新的 MGR 主节点。

• 支持多节点写入，有冲突检测机制。
• 强一致性。

• 只支持 InnoDB 表，每张表都要有主键。
• 最多只支持 9 个节点。

5 Xenon

• 不需要管理节点。
• 无数据丢失的快速故障转移。

• 只适用于 GTID。
• 默认情况下，Xenon 和 MySQL 跑在同一个账号下。

6 Orchestrator

• 自动发现 MySQL 拓扑，可以拖动拓扑图进行复制关系的变更。
• 提供命令行和 API 接口，方便运维管理。
• 快速故障转移。
• 多种故障等级，应对不同故障等级可配置不同处理办法。

• 相对于其他高可用组件，参数多很多。
• 在某些场景可能出现丢数据的情况，数据补偿机制需要优化。

7 参考文档

8 投票