MySQL 从节点也可以当其他节点的主节点吗

级联复制：从节点作为其他节点的主节点

答案是：可以。这在 MySQL 中被称为级联复制（Cascading Replication）或链式复制（Chain Replication）。一个从节点可以同时作为另一个节点的”主节点”，形成多级复制拓扑。

架构形态

Master → Slave1（中间层）→ Slave2
                          → Slave3
                          → Slave4

在这种架构中，Slave1 同时扮演着”从”和”主”的双重角色：对 Master 它是从节点，对 Slave2/3/4 它是主节点。

配置方法

第 1 步：在中间从库（Slave1）上开启 binlog

中间从库必须开启 binlog 才能将数据继续传递给下游：

[mysqld]
server-id = 2
log-bin = mysql-bin
log-slave-updates = 1   # 关键！让从库把重放的事件也写入自己的 binlog
binlog-format = ROW

log-slave-updates 是级联复制的关键参数。如果不开启，从库从主库同步的数据不会写入自己的 binlog，下游从库就获取不到数据。

第 2 步：在中间从库上创建复制用户

CREATE USER 'repl_sub'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_sub'@'%';

第 3 步：下游从库指向中间从库

CHANGE MASTER TO
  MASTER_HOST='slave1_host',
  MASTER_USER='repl_sub',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000010',
  MASTER_LOG_POS=456;

START SLAVE;

使用场景

1. 减轻主库网络负担

主库只需要服务少量直接连接的从库，大量读取从库可以通过中间层级联，减少主库的网络连接数。

2. 跨机房部署

主库（北京机房）→ 中间从库（上海机房）→ 从库群（上海）
                                       → 从库群（上海）
                                       → 从库群（上海）

主库只需要与上海机房的中间节点通信，无需跨地域连接大量从库。

3. 分层权限管理

在数据分发场景中，中间节点可以控制数据下发的范围。

需要注意的问题

主从延迟放大

级联复制会放大延迟。Master 到 Slave1 已经存在延迟，Slave1 到 Slave2 又会叠加一层。层级越深，末端从库的延迟越大。

Master 写入时间: T+0
Slave1 同步完成: T+1s
Slave2 同步完成: T+2s
Slave3 同步完成: T+3s

中间节点故障影响面大

如果 Slave1 宕机，它下游的所有从库都会失去数据来源，影响范围远大于单层架构。

故障恢复复杂

当中间节点发生故障时，需要重新选路，将下游从库重新指向其他可用的节点。

替代方案：环形复制

MySQL 也支持环形复制（双向复制），但需要谨慎处理冲突：

Master1 ←→ Master2
  ↑          ↑
  │          │
Slave1     Slave2

环形复制主要用于异地多活场景，但需要业务层解决冲突或使用基于行记录的冲突检测。

面试要点

• 级联复制的核心配置：log-slave-updates = 1
• 适用场景：减轻主库压力、跨机房部署
• 主要风险：延迟放大、单点故障影响面大
• 级联复制 vs 直接复制：性能和可靠性的权衡
• 实践中建议级联不超过 2-3 层