MySQL 级联复制配置

什么是级联复制

级联复制（Cascade Replication）是 MySQL 主从复制的一种扩展拓扑结构，其中一个从服务器同时作为另一个从服务器的主服务器。这种拓扑结构允许构建更复杂的复制集群，适用于大规模数据库部署场景。

级联复制的典型拓扑结构：

主服务器（Master）
中间服务器（Intermediate Slave/Master）
从服务器（Slave）

级联复制的优势

减少主服务器负载：主服务器只需要向中间服务器发送二进制日志，而不需要向所有从服务器发送
支持更多从服务器：突破单个主服务器可以支持的从服务器数量限制
灵活的复制拓扑：可以根据地理分布和业务需求设计复杂的复制拓扑
隔离不同业务：不同业务可以使用不同的中间服务器，实现业务隔离
便于维护：可以在不影响主服务器的情况下，对部分从服务器进行维护

级联复制的劣势

增加复制延迟：数据需要经过中间服务器转发，可能导致更长的复制延迟
增加故障点：中间服务器的故障会影响其下游从服务器
配置复杂度增加：需要管理更复杂的复制拓扑
监控难度增加：需要监控整个复制链路的状态

级联复制的配置步骤

1. 准备环境

假设有三台服务器：

Master：192.168.1.100
Intermediate：192.168.1.101
Slave：192.168.1.102

2. 配置主服务器（Master）

2.1 修改配置文件

ini

# /etc/my.cnf
[mysqld]
# 启用二进制日志
log_bin = mysql-bin
server_id = 100
# 启用 GTID（可选，推荐）
gtid_mode = ON
enforce_gtid_consistency = ON
# 二进制日志格式
binlog_format = ROW
# 保存从服务器信息
log_slave_updates = ON

2.2 重启 MySQL 服务

bash

systemctl restart mysqld

2.3 创建复制用户

sql

CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

3. 配置中间服务器（Intermediate）

3.1 修改配置文件

ini

# /etc/my.cnf
[mysqld]
# 启用二进制日志
log_bin = mysql-bin
server_id = 101
# 启用 GTID（可选，推荐）
gtid_mode = ON
enforce_gtid_consistency = ON
# 二进制日志格式
binlog_format = ROW
# 保存从服务器信息（必须启用，否则无法作为上游服务器）
log_slave_updates = ON

3.2 重启 MySQL 服务

bash

systemctl restart mysqld

3.3 配置从主服务器复制

基于 GTID 的复制

sql

CHANGE MASTER TO
  MASTER_HOST = '192.168.1.100',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'repl_password',
  MASTER_AUTO_POSITION = 1;

START SLAVE;

基于位置的复制

sql

-- 在主服务器上获取二进制日志信息
SHOW MASTER STATUS;

-- 在中间服务器上配置复制
CHANGE MASTER TO
  MASTER_HOST = '192.168.1.100',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'repl_password',
  MASTER_LOG_FILE = 'mysql-bin.000001',
  MASTER_LOG_POS = 154;

START SLAVE;

3.4 验证复制状态

sql

SHOW SLAVE STATUS\G;

确保 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes。

3.5 创建下游复制用户

sql

CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

4. 配置从服务器（Slave）

4.1 修改配置文件

ini

# /etc/my.cnf
[mysqld]
server_id = 102
# 启用 GTID（可选，推荐）
gtid_mode = ON
enforce_gtid_consistency = ON

4.2 重启 MySQL 服务

bash

systemctl restart mysqld

4.3 配置从中间服务器复制

基于 GTID 的复制

sql

CHANGE MASTER TO
  MASTER_HOST = '192.168.1.101',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'repl_password',
  MASTER_AUTO_POSITION = 1;

START SLAVE;

基于位置的复制

sql

-- 在中间服务器上获取二进制日志信息
SHOW MASTER STATUS;

-- 在从服务器上配置复制
CHANGE MASTER TO
  MASTER_HOST = '192.168.1.101',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'repl_password',
  MASTER_LOG_FILE = 'mysql-bin.000001',
  MASTER_LOG_POS = 154;

START SLAVE;

4.4 验证复制状态

sql

SHOW SLAVE STATUS\G;

确保 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes。

级联复制的监控

1. 监控复制状态

1.1 使用 SHOW SLAVE STATUS

sql

-- 在中间服务器上
SHOW SLAVE STATUS\G;

-- 在从服务器上
SHOW SLAVE STATUS\G;

关键指标：

Slave_IO_Running：IO 线程状态
Slave_SQL_Running：SQL 线程状态
Seconds_Behind_Master：复制延迟
Last_Error：最近的错误信息

1.2 使用 Performance Schema

sql

-- 监控复制连接
SELECT * FROM performance_schema.replication_connection_status;

-- 监控复制应用
SELECT * FROM performance_schema.replication_applier_status;

-- 监控复制延迟
SELECT * FROM performance_schema.replication_applier_status_by_worker;

1.3 使用 MySQL Shell

bash

# 连接到 MySQL Shell
mysqlsh --uri root@192.168.1.100

# 监控复制拓扑
\repl topology show

1.4 使用第三方监控工具

Prometheus + Grafana
Zabbix
Nagios
MySQL Enterprise Monitor

2. 监控复制延迟

2.1 使用 SHOW SLAVE STATUS

sql

SHOW SLAVE STATUS\G;

查看 Seconds_Behind_Master 字段。

2.2 使用 PT-HEARTBEAT

bash

# 在主服务器上启动心跳
pt-heartbeat --daemonize --interval=1 --database=test --update --master-server-id=100

# 在从服务器上检查延迟
pt-heartbeat --database=test --check --master-server-id=100

级联复制的故障处理

1. 主服务器故障

处理步骤

选择新主服务器：选择一个合适的中间服务器作为新主服务器
提升中间服务器为主服务器：
sql
```
STOP SLAVE;
RESET SLAVE ALL;
```
重新配置其他中间服务器：将其他中间服务器重新指向新主服务器
重新配置应用程序：将应用程序连接指向新主服务器

2. 中间服务器故障

处理步骤

评估影响范围：确定受影响的下游从服务器

临时解决方案：将下游从服务器直接指向主服务器

sql

STOP SLAVE;
CHANGE MASTER TO
  MASTER_HOST = '192.168.1.100',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'repl_password',
  MASTER_AUTO_POSITION = 1;
START SLAVE;

修复中间服务器：修复或替换故障的中间服务器
恢复原始拓扑：将下游从服务器重新指向修复后的中间服务器

3. 从服务器故障

处理步骤

修复从服务器：修复或替换故障的从服务器
重新配置复制：根据当前复制拓扑，重新配置从服务器
验证复制状态：确保复制正常运行

4. 复制延迟过高

可能原因

中间服务器性能不足
网络延迟
大事务
从服务器配置不当

解决方案

优化中间服务器和从服务器的硬件配置
优化网络连接
拆分大事务
调整复制参数
考虑使用并行复制

级联复制的最佳实践

1. 拓扑设计

避免过深的级联层级：建议级联层级不超过3层
考虑地理分布：将中间服务器部署在不同的数据中心
业务隔离：根据业务需求设计复制拓扑
冗余设计：为关键中间服务器配置冗余

2. 配置优化

启用 GTID：简化复制配置和故障切换

启用并行复制：提高复制性能

ini

slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 4

调整复制线程优先级：

ini

slave_net_timeout = 60
master_connect_retry = 10

启用半同步复制：提高数据安全性

ini

plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_slave_enabled = 1

3. 监控与告警

设置复制状态告警：当复制中断时及时告警
设置复制延迟告警：当延迟超过阈值时及时告警
监控中间服务器性能：确保中间服务器有足够的处理能力
定期检查复制拓扑：确保复制拓扑的完整性

4. 维护管理

定期备份：定期备份所有服务器的数据
定期检查复制状态：确保复制正常运行

定期清理二进制日志：避免磁盘空间不足

sql

PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);

定期更新统计信息：提高查询性能
sql
```
ANALYZE TABLE table_name;
```

5. 升级与迁移

分批升级：从最底层的从服务器开始，逐步升级到主服务器
测试环境验证：在测试环境中验证升级方案
制定回滚计划：准备详细的回滚计划
监控升级过程：实时监控升级过程中的复制状态

级联复制与其他复制拓扑的比较

拓扑类型	优点	缺点	适用场景
简单主从复制	配置简单、易于维护	主服务器负载高、支持从服务器数量有限	小型数据库集群
级联复制	减少主服务器负载、支持更多从服务器	复制延迟增加、故障点增多	大型数据库集群、跨地域部署
双主复制	高可用性、读写分离	数据一致性问题、配置复杂	高可用性要求高的场景
环形复制	高可用性、灵活的拓扑	故障影响范围大、数据一致性问题	特定的高可用性场景
组复制	自动故障切换、数据一致性保证	配置复杂、性能开销大	现代高可用性数据库集群

常见问题（FAQ）

Q1: 级联复制中，中间服务器需要启用 log_slave_updates 吗？

A1: 是的，中间服务器必须启用 log_slave_updates 配置项，否则无法将从主服务器复制的数据写入自己的二进制日志，下游从服务器也就无法从中间服务器复制数据。

Q2: 级联复制支持并行复制吗？

A2: 是的，级联复制支持并行复制。可以在中间服务器和从服务器上配置 slave_parallel_workers 参数来启用并行复制，提高复制性能。

Q3: 如何在级联复制中添加新的从服务器？

A3: 可以将新的从服务器添加到任意中间服务器或主服务器下，具体取决于拓扑设计。添加步骤与普通主从复制相同。

Q4: 级联复制中，主服务器的二进制日志需要保存多长时间？

A4: 主服务器的二进制日志需要保存足够长的时间，确保所有中间服务器都已复制。建议根据复制延迟和备份策略来确定，一般保存7-14天。

Q5: 如何将级联复制转换为普通主从复制？

A5: 可以将下游从服务器直接指向主服务器，然后停止中间服务器的复制。具体步骤：

在从服务器上停止复制
重新配置从服务器指向主服务器
启动复制
验证复制状态
停止中间服务器的复制（可选）

Q6: 级联复制支持半同步复制吗？

A6: 是的，级联复制支持半同步复制。可以在主服务器和中间服务器上启用半同步复制插件，提高数据安全性。

Q7: 如何监控级联复制的整个拓扑？

A7: 可以使用以下方法：

MySQL Shell 的复制拓扑监控功能
第三方监控工具如 Prometheus + Grafana
自定义脚本监控

Q8: 级联复制中，如何处理大事务？

A8: 大事务会导致复制延迟增加，可以通过以下方法处理：

拆分大事务为多个小事务
调整复制参数，如 slave_parallel_workers
监控大事务，及时发现并处理
考虑使用组复制等更适合处理大事务的复制技术

Q9: 级联复制支持不同版本的 MySQL 服务器吗？

A9: 是的，级联复制支持不同版本的 MySQL 服务器，但需要注意版本兼容性。一般建议从服务器的版本不低于主服务器的版本。

Q10: 如何在级联复制中实现读写分离？

A10: 可以在应用程序层面或使用数据库代理（如 ProxySQL、MaxScale）来实现读写分离，将写操作发送到主服务器，读操作发送到从服务器。

案例分析

案例1：跨地域级联复制

问题：一家跨国公司需要在全球多个数据中心部署 MySQL 数据库，主数据中心在上海，备份数据中心在北京和广州。

解决方案：使用级联复制拓扑：

上海：主服务器
北京：中间服务器
广州：从服务器（从北京的中间服务器复制）

结果：

减少了上海主服务器的负载
降低了跨地域复制的网络延迟
便于管理不同地区的数据中心

案例2：业务隔离级联复制

问题：一家电商公司有多个业务线（电商、支付、物流），每个业务线都需要访问 MySQL 数据库，导致主服务器负载过高。

解决方案：使用级联复制拓扑，为每个业务线配置独立的中间服务器：

主服务器：处理所有写操作
电商中间服务器：处理电商业务的读操作
支付中间服务器：处理支付业务的读操作
物流中间服务器：处理物流业务的读操作

结果：

降低了主服务器的负载
实现了业务隔离
便于每个业务线独立管理自己的从服务器

案例3：级联复制故障切换

问题：某公司的级联复制拓扑中，中间服务器发生故障，导致其下游从服务器无法复制数据。

解决方案：

立即将下游从服务器重新指向主服务器
修复故障的中间服务器
验证中间服务器修复成功后，将下游从服务器重新指向中间服务器

结果：

最小化了故障对业务的影响
成功恢复了原始复制拓扑
积累了级联复制故障处理经验

不同版本的差异

MySQL 5.6

支持级联复制，但配置相对复杂
支持基于位置的复制和 GTID 复制（MySQL 5.6.10+）
并行复制功能有限（仅支持基于数据库的并行复制）

MySQL 5.7

增强了级联复制的支持
支持基于逻辑时钟的并行复制
增强了 GTID 复制的稳定性
引入了 Performance Schema 复制监控

MySQL 8.0

进一步增强了级联复制的支持
支持多源复制
引入了 MySQL Shell 复制拓扑管理
增强了并行复制的性能
引入了复制延迟监控的新功能

MySQL 级联复制配置 ​

什么是级联复制 ​

级联复制的优势 ​

级联复制的劣势 ​

级联复制的配置步骤 ​

1. 准备环境 ​

2. 配置主服务器（Master） ​

2.1 修改配置文件 ​

2.2 重启 MySQL 服务 ​

2.3 创建复制用户 ​

3. 配置中间服务器（Intermediate） ​

3.1 修改配置文件 ​

3.2 重启 MySQL 服务 ​

3.3 配置从主服务器复制 ​

基于 GTID 的复制 ​

基于位置的复制 ​

3.4 验证复制状态 ​

3.5 创建下游复制用户 ​

4. 配置从服务器（Slave） ​

4.1 修改配置文件 ​

4.2 重启 MySQL 服务 ​

4.3 配置从中间服务器复制 ​

基于 GTID 的复制 ​

基于位置的复制 ​

4.4 验证复制状态 ​

级联复制的监控 ​

1. 监控复制状态 ​

1.1 使用 SHOW SLAVE STATUS ​

1.2 使用 Performance Schema ​

1.3 使用 MySQL Shell ​

1.4 使用第三方监控工具 ​

2. 监控复制延迟 ​

2.1 使用 SHOW SLAVE STATUS ​

2.2 使用 PT-HEARTBEAT ​

级联复制的故障处理 ​

1. 主服务器故障 ​

处理步骤 ​

2. 中间服务器故障 ​

处理步骤 ​

3. 从服务器故障 ​

处理步骤 ​

4. 复制延迟过高 ​

可能原因 ​

解决方案 ​

级联复制的最佳实践 ​

1. 拓扑设计 ​

2. 配置优化 ​

3. 监控与告警 ​

4. 维护管理 ​

5. 升级与迁移 ​

级联复制与其他复制拓扑的比较 ​

常见问题（FAQ） ​

Q1: 级联复制中，中间服务器需要启用 log_slave_updates 吗？ ​

MySQL 级联复制配置

什么是级联复制

级联复制的优势

级联复制的劣势

级联复制的配置步骤

1. 准备环境

2. 配置主服务器（Master）

2.1 修改配置文件

2.2 重启 MySQL 服务

2.3 创建复制用户

3. 配置中间服务器（Intermediate）

3.1 修改配置文件

3.2 重启 MySQL 服务

3.3 配置从主服务器复制

基于 GTID 的复制

基于位置的复制

3.4 验证复制状态

3.5 创建下游复制用户

4. 配置从服务器（Slave）

4.1 修改配置文件

4.2 重启 MySQL 服务

4.3 配置从中间服务器复制

基于 GTID 的复制

基于位置的复制

4.4 验证复制状态

级联复制的监控

1. 监控复制状态

1.1 使用 SHOW SLAVE STATUS

1.2 使用 Performance Schema

1.3 使用 MySQL Shell

1.4 使用第三方监控工具

2. 监控复制延迟

2.1 使用 SHOW SLAVE STATUS

2.2 使用 PT-HEARTBEAT

级联复制的故障处理

1. 主服务器故障

处理步骤

2. 中间服务器故障

处理步骤

3. 从服务器故障

处理步骤

4. 复制延迟过高

可能原因

解决方案

级联复制的最佳实践

1. 拓扑设计

2. 配置优化

3. 监控与告警

4. 维护管理

5. 升级与迁移

级联复制与其他复制拓扑的比较

常见问题（FAQ）

Q1: 级联复制中，中间服务器需要启用 log_slave_updates 吗？