在数据库管理的世界里，实现高可用架构是至关重要的，它能确保业务数据的安全性和系统的稳定性。今天，咱们就来聊聊 MySQL 高可用架构设计中两种常见的方案：MGR（MySQL Group Replication）和传统主从复制，看看它们各自的特点、适用场景，以及该如何选择。

一、传统主从复制架构

1. 架构原理

传统主从复制是 MySQL 最早提供的一种高可用解决方案。简单来说，就是有一个主服务器（Master）和多个从服务器（Slave）。主服务器负责处理所有的写操作，而从服务器则通过复制主服务器上的二进制日志（binlog）来同步数据，处理读操作。

2. 示例演示

咱们来看看如何搭建一个简单的传统主从复制架构。这里使用 MySQL 技术栈。

主服务器配置（Master）

首先，编辑主服务器的配置文件 my.cnf，添加以下内容：

# 开启二进制日志
log-bin=mysql-bin
# 服务器唯一 ID
server-id=1

然后重启 MySQL 服务：

sudo systemctl restart mysql

接着创建一个用于复制的用户：

-- 创建复制用户
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'password';
-- 授予复制权限
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
-- 刷新权限
FLUSH PRIVILEGES;

查看主服务器的二进制日志信息：

SHOW MASTER STATUS;

记录下 File 和 Position 的值，后面从服务器配置会用到。

从服务器配置（Slave）

编辑从服务器的配置文件 my.cnf，添加以下内容：

# 服务器唯一 ID
server-id=2

重启 MySQL 服务：

sudo systemctl restart mysql

配置从服务器连接主服务器：

-- 配置从服务器连接主服务器
CHANGE MASTER TO
MASTER_HOST='master_ip',
MASTER_USER='repl_user',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.xxxxxx',  -- 主服务器的二进制日志文件名
MASTER_LOG_POS=xxxxxx;  -- 主服务器的二进制日志位置
-- 启动从服务器复制
START SLAVE;

查看从服务器的复制状态：

SHOW SLAVE STATUS\G;

如果 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes，说明复制配置成功。

3. 应用场景

传统主从复制架构适用于读多写少的场景，比如新闻网站、论坛等。在这些场景中，大部分操作是读取文章、帖子等数据，而写操作相对较少。

4. 技术优缺点

  • 优点：
    • 实现简单，易于理解和部署。
    • 可以通过增加从服务器来扩展读性能。
    • 成本较低，不需要额外的软件或硬件支持。
  • 缺点：
    • 主服务器是单点故障，如果主服务器出现问题，需要手动进行故障转移。
    • 数据一致性问题，从服务器同步数据可能会有延迟，尤其是在高并发写操作的情况下。
    • 写操作只能在主服务器上进行，无法实现多主写入。

5. 注意事项

  • 主从服务器的 MySQL 版本要尽量保持一致，避免出现兼容性问题。
  • 定期检查从服务器的复制状态，确保数据同步正常。
  • 合理规划从服务器的数量，避免过多的从服务器影响主服务器的性能。

二、MGR 架构

1. 架构原理

MGR 是 MySQL 5.7 版本以后推出的一种全新的高可用解决方案，它基于组复制技术，实现了多主写入和自动故障转移。在 MGR 架构中，多个 MySQL 服务器组成一个组，组内的所有服务器都可以处理读写操作，并且数据会自动在组内同步。

2. 示例演示

下面我们来搭建一个简单的 MGR 架构，同样使用 MySQL 技术栈。

节点配置

假设我们有三个 MySQL 节点，分别为 node1、node2 和 node3。

首先，在每个节点的配置文件 my.cnf 中添加以下内容：

# 开启组复制插件
plugin-load-add=group_replication.so
# 服务器唯一 ID
server-id=1
# 组复制的通信地址
group_replication_group_seeds="node1:33061,node2:33061,node3:33061"
# 组复制的引导节点
group_replication_bootstrap_group=OFF
# 组复制的成员身份验证
group_replication_autorejoin_tries=10

重启 MySQL 服务：

sudo systemctl restart mysql

初始化组

在 node1 节点上执行以下命令，初始化组：

-- 开启组复制引导模式
SET GLOBAL group_replication_bootstrap_group=ON;
-- 启动组复制
START GROUP_REPLICATION;
-- 关闭组复制引导模式
SET GLOBAL group_replication_bootstrap_group=OFF;

加入组

在 node2 和 node3 节点上执行以下命令，加入组：

-- 启动组复制
START GROUP_REPLICATION;

查看组状态

在任意节点上执行以下命令，查看组状态：

SHOW STATUS LIKE 'group_replication_%';

3. 应用场景

MGR 架构适用于对数据一致性要求较高、需要多主写入的场景，比如电商系统、金融系统等。在这些场景中，需要保证数据的实时一致性，并且可能会有多个节点同时进行写操作。

4. 技术优缺点

  • 优点：
    • 多主写入，提高了写性能和系统的并发处理能力。
    • 自动故障转移，当某个节点出现问题时，组内会自动进行故障转移，无需手动干预。
    • 数据一致性高，采用了强一致性算法，确保组内所有节点的数据一致。
  • 缺点：
    • 部署和配置相对复杂，需要对组复制技术有深入的了解。
    • 资源消耗较大，每个节点都需要参与复制和同步，会占用一定的系统资源。
    • 对网络环境要求较高，组内节点之间的通信需要稳定可靠的网络连接。

5. 注意事项

  • 确保所有节点的 MySQL 版本一致，并且开启了组复制插件。
  • 合理规划组内节点的数量，一般建议为奇数个，以避免脑裂问题。
  • 监控组内节点的状态，及时处理异常情况。

三、MGR 与传统主从的对比

1. 数据一致性

传统主从复制架构存在数据一致性问题，从服务器同步数据可能会有延迟。而 MGR 采用了强一致性算法，确保组内所有节点的数据一致，数据一致性更高。

2. 故障转移

传统主从复制架构需要手动进行故障转移，操作繁琐且容易出错。而 MGR 可以自动进行故障转移，当某个节点出现问题时，组内会自动选举新的主节点，确保系统的高可用性。

3. 写性能

传统主从复制架构的写操作只能在主服务器上进行，无法实现多主写入。而 MGR 支持多主写入，可以提高写性能和系统的并发处理能力。

4. 部署和维护复杂度

传统主从复制架构实现简单，易于理解和部署。而 MGR 部署和配置相对复杂，需要对组复制技术有深入的了解，并且需要监控组内节点的状态。

四、选型建议

1. 根据业务需求选择

如果业务对数据一致性要求不高，读多写少，并且对成本和部署复杂度有较高的要求，那么传统主从复制架构是一个不错的选择。例如，一些小型的新闻网站、博客等。

如果业务对数据一致性要求较高，需要多主写入，并且能够承受一定的部署和维护复杂度，那么 MGR 架构更适合。例如，电商系统、金融系统等。

2. 根据系统规模选择

对于小规模的系统，传统主从复制架构可以满足需求，并且成本较低。而对于大规模的系统，MGR 架构可以更好地应对高并发和数据一致性的挑战。

3. 根据团队技术能力选择

如果团队对 MySQL 技术有一定的了解，但对组复制技术不太熟悉，那么可以先采用传统主从复制架构。随着团队技术能力的提升，再考虑迁移到 MGR 架构。

五、文章总结

传统主从复制架构和 MGR 架构都是 MySQL 高可用架构设计中的常见方案，它们各有优缺点，适用于不同的应用场景。在选择架构时，需要根据业务需求、系统规模和团队技术能力等因素进行综合考虑。传统主从复制架构实现简单，成本低，适合读多写少、对数据一致性要求不高的场景；而 MGR 架构数据一致性高，支持多主写入，适合对数据一致性要求较高、需要高并发处理的场景。