MySQL 常用高可用方案

这一节内容来简单聊聊 MySQL 最常用的几种高可用方案。

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 接口，方便运维管理。
• 快速故障转移。
• 多种故障等级，应对不同故障等级可配置不同处理办法。

缺点

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

其他参考资料：

MySQL的高可用 - Gabydawei - 博客园

五大常见的MySQL高可用方案分享

实战 MySQL 高可用架构

Mysql高可用架构