级联复制的原理与应用场景
概述
级联复制（Cascading Replication）是一种链式复制架构：从库不直接从主库同步数据，而是从另一个从库同步。这种架构可以减轻主库的复制负载，适合从库数量较多的场景。
基本架构
传统星形架构
┌── 从库 A
│
主库 ─────┼── 从库 B
│
└── 从库 C
（所有从库直连主库，主库需要为每个从库维护 Binlog Dump 线程）
主库需要为每个从库维护一个 Binlog Dump 线程。如果从库很多（如 20+），主库压力很大。
级联复制架构
主库 ───→ 从库 1（中继）───→ 从库 2
│
├──→ 从库 3
│
└──→ 从库 4
主库只需要服务一个从库（中继从库），其他从库从中继从库同步。
多层级联
主库 → 从库 A → 从库 B → 从库 C
↓
从库 D
级联复制的配置
级联复制中，中间节点既是”从库”（从上游同步），又是”主库”（向下游提供 Binlog）。
第一步：中间节点开启 Binlog
# 中间节点（如 从库 1）的配置
[mysqld]
server-id = 2
log_bin = /var/log/mysql/mysql-bin -- 开启 Binlog（记录变更）
log_slave_updates = ON -- 关键！将从库回放的事务也写入 Binlog
binlog_format = ROW
关键参数：log_slave_updates = ON
这个参数告诉 MySQL：SQL 线程回放的变更也写入本机的 Binlog。这样下层节点才能从这个”从库”拉取数据。
第二步：配置复制链路
-- 第一层：主库 → 从库 1
-- 从库 1 上执行
CHANGE MASTER TO
MASTER_HOST='192.168.1.10', -- 这是主库
MASTER_PORT=3306,
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_AUTO_POSITION = 1;
START SLAVE;
-- 第二层：从库 1 → 从库 2
-- 从库 2 上执行
CHANGE MASTER TO
MASTER_HOST='192.168.1.11', -- 这是从库 1（中继节点）
MASTER_PORT=3306,
MASTER_USER='repl',
MASTER_PASSWORD='password', -- 使用相同的复制账号
MASTER_AUTO_POSITION = 1;
START SLAVE;
级联复制时的 GTID
GTID 在级联复制中保持不变，可以跨级追踪：
主库 GTID = 3e11fa47:1
事务写入主库：
GTID = 3e11fa47:1
↓ 同步到从库 1
从库 1 执行 GTID = 3e11fa47:1
从库 1 的 Binlog 中包含 GTID = 3e11fa47:1（因为 log_slave_updates=ON）
↓ 从库 2 从从库 1 拉取
从库 2 执行 GTID = 3e11fa47:1
所有节点上的 GTID 是相同的，这有助于排查问题。
级联复制的优缺点
优点
| 优点 | 说明 |
|---|---|
| 减轻主库压力 | 主库只需要维护少量 Binlog Dump 线程 |
| 支持更多从库 | 通过多层扩展，可以支持几十甚至上百个从库 |
| 单一复制账号 | 所有节点可以使用相同的复制账号 |
| 网络隔离 | 中间层可以部署在核心网络，下层在边缘网络 |
缺点
| 缺点 | 说明 |
|---|---|
| 延迟更大 | 每多一级就多一次复制延迟 |
| 故障面扩大 | 中间节点故障会影响下层所有从库 |
| 排障更复杂 | 问题可能发生在任何一级，排查链条更长 |
| 配置更复杂 | 需要正确设置 log_slave_updates |
延迟分析
主库写入 → 从库 1 同步 → 从库 2 同步 → 从库 3 同步
假设每级延迟 2 秒：
从库 1 延迟 = 主库写入后 2 秒可见
从库 2 延迟 = 主库写入后 4 秒可见
从库 3 延迟 = 主库写入后 6 秒可见
级联深度建议不超过 3 层，否则延迟可能不可接受。
应用场景
场景一：大量从库的读扩展
主库 → [从库 A] → 从库 1 ~ 从库 5（业务 A）
→ [从库 B] → 从库 6 ~ 从库 10（业务 B）
→ [从库 C] → 从库 11 ~ 从库 15（业务 C）
主库只需要 3 个连接（到从库 A/B/C），而非 15 个。
场景二：多机房/多数据中心
北京机房 上海机房
主库 → 从库 1（跨机房同步） → 从库 2
↓
从库 3
跨机房同步只有一条链路，延迟相对可控。上海机房内部再级联分发。
场景三：读写分离 + 分析库分离
主库 → 从库 A（业务读取）
→ 从库 B（分析/报表）
↓
从库 C（离线备份/ETL）
分析库和离线备份从从库同步，不影响主库和业务从库。
最佳实践
# 中间节点的关键配置
[mysqld]
server-id = 2
log_bin = /var/log/mysql/mysql-bin
log_slave_updates = ON -- 必须开启，否则下层无法同步
binlog_format = ROW
expire_logs_days = 3 -- 中间节点 Binlog 不需要保留太久
relay_log = /var/log/mysql/relay-log
监控建议
-- 在每一层查看复制状态
SHOW SLAVE STATUS\G
-- 检查从上到下的 GTID 是否一致
-- 主库
SELECT @@GLOBAL.gtid_executed;
-- 从库 1
SELECT @@GLOBAL.gtid_executed;
-- 应该包含主库的 GTID
面试要点
- 级联复制 = 从库可以同时作为”主库”，向下层提供 Binlog
log_slave_updates=ON是关键配置，让从库回放的事务也写入 Binlog- 优点：减轻主库负载，支持更多从库
- 缺点：延迟逐级累加，一级故障影响整条链路
- 建议级联深度不超过 3 层
- GTID 在级联复制中不变（所有节点使用相同的 GTID），便于排障
- 典型应用场景：大量从库、多机房、分析库分离
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
暂无评论内容