1. 主从或主主 + Keepalived
主从或主主 + Keepalived 算是历史比较悠久的 MySQL 高可用方案，常见架构如下：
其大致原理是：在主实例的 Keepalived 中，增加监测本机 MySQL 是否存活的脚本，如果监测 MySQL 挂了，就会重启 Keepalived，从而使 VIP 飘到从实例。
优点
- 部署简单。
- 只有两个节点，没有主实例宕机后选主的问题。
缺点：
- 级联复制或者一主多从在切换之后，其他从实例需要重新配置连接新主。
- 云环境使用不了。
2. MHA
MHA（Master High Avaliable） 是一款 MySQL 开源高可用程序，MHA 在监测到主实例无响应后，可以自动将同步最靠前的 Slave 提升为 Master，然后将其他所有的 Slave 重新指向新的 Master。常见架构如下：
优点
- 可以根据需要扩展 MySQL 的节点数量。
- 只要复制没有延迟，MHA 通常可以在几秒内实现故障切换。
- 可以使用任何存储引擎。
缺点
- 仅监视主数据库。
- 需要做 SSH 互信
- 使用 Perl 开发，二次开发困难。
- 跟不上 MySQL 新版本，最近一次发版是 2018 年。
3. PXC
PXC（Percona XtraDB Cluster）是一个完全开源的 MySQL 高可用解决方案。它将 Percona Server、Percona XtraBackup 与 Galera 库集成在一起，以实现多主复制的 MySQL 集群。常见架构图如下：
优点
- 去中心：任何节点宕机，集群都可以继续运行而不会丢失任何数据。
- 每个节点都可以写入数据并自动同步到其他节点。
- 数据写入需要集群所有节点验证通过才会提交，保证了数据的强一致性。
缺点
- 只支持 InnoDB 引擎。
- 木桶效应：集群吞吐量取决于性能最差的节点。
- 增加节点时，必须从现有节点之一复制完整的数据集。
4. MGR/InnoDB Cluster
MySQL 5.7 推出了 MGR（MySQL Group Replication），与 PXC 类似，也实现了多节点数据写入和强一致性的特点。MGR 采用 GCS（Group Communication System）协议同步数据，GCS 可保证消息的原子性。
在使用 MGR 时，如果要实现完整的高可用方案，就需要用到 InnoDB Cluster。架构图如下：
InnoDB Cluster 由以下技术组成：
- MySQL Shell，MySQL 的高级客户端和代码编辑器，用于管理 MGR 集群。
- Group Replication，提供一组高可用的 MySQL 实例。
- MySQL Router，在应用程序和集群之间提供透明的路由。当 MGR 发生切换树，自动路由到新的 MGR 主节点。
优点
- 支持多节点写入，有冲突检测机制。
- 强一致性。
缺点
- 只支持 InnoDB 表，每张表都要有主键。
- 最多只支持 9 个节点。
5. Xenon
Xenon 是一个使用 Raft 协议的 MySQL 高可用和复制管理工具，使用 Go 语音编写。架构图如下：
Xenon 基于 Raft 协议进行无中心化选主，并能实现秒级切换。
优点
- 不需要管理节点。
- 无数据丢失的快速故障转移。
缺点
- 只适用于 GTID。
- 默认情况下，Xenon 和 MySQL 跑在同一个账号下。
6. Orchestrator
Orchestrator是 Go 语音编写的 MySQL 高可用性和复制管理工具，作为服务运行并提供命令行访问、HTTP API 和 Web 界面。架构图如下：
优点
- 自动发现 MySQL 拓扑，可以拖动拓扑图进行复制关系的变更。
- 提供命令行和 API 接口，方便运维管理。
- 快速故障转移。
- 多种故障等级，应对不同故障等级可配置不同处理办法。
缺点
- 相对于其他高可用组件，参数多很多。
- 在某些场景可能出现丢数据的情况，数据补偿机制需要优化。
7. 参考文档
PXC 官方文档：https://www.percona.com/doc/percona-xtradb-cluster/LATEST/index.html
官方文档 InnoDB Cluster：https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-introduction.html
Xenon Github 地址：https://github.com/radondb/xenon
Orchestrator Github 地址：https://github.com/openark/orchestrator