MySQL 中的 log-slave-updates 参数详解：链式复制（级联复制）从库

原创

a772304419 2025-10-27 14:38:38 ©著作权

©著作权归作者所有：来自51CTO博客作者a772304419的原创作品，请联系作者获取转载授权，否则将追究法律责任

本文我们来详细讲解一下 MySQL 中的 log-slave-updates 这个非常重要的参数。

log-slave-updates 是一个用于主从复制环境的配置参数。它的作用是：决定一个从服务器是否将来自主服务器的中继日志中的事件记录到它自己的二进制日志中。

为了更好地理解，我们来看一下开启和关闭此参数时，数据复制的流程。

这是最简单的链式复制场景。

结果：Slave 1 的二进制日志是空的（或者只记录它自己直接执行的写操作，如果开启了 log-bin）。其他服务器无法从 Slave 1 这里继续复制数据。

这是构建多级复制链的关键。

主库 Master 执行一个事务。
主库将这个事件写入其二进制日志。
从库 Slave 1 的 I/O 线程从主库拉取二进制日志事件，并写入本地的中继日志。
从库 Slave 1 的 SQL 线程读取中继日志并执行事件。
关键步骤：由于 log-slave-updates = ON，Slave 1 的 SQL 线程在执行完中继日志中的事件后，会将这些事件写入 Slave 1 自己的二进制日志。
另一台从库 Slave 2 可以将 Slave 1 当作它的“主库”，从 Slave 1 的二进制日志中拉取事件并进行应用。

结果：形成了一个复制链 Master -> Slave 1 -> Slave 2。数据更改从主库流经中间从库，最终到达下游从库。

主要应用在以下场景：

多级复制：
当你有大量从库时，为了减轻主库的网络和负载压力，可以设置一个或多个“中继从库”。主库只负责将数据复制给这几个中继从库，然后由中继从库将数据分发给更多的下游从库。这要求中继从库必须开启 log-slave-updates。
高可用与故障切换：
在类似 Master-Slave 的高可用架构中，如果主库宕机，需要将一个从库提升为新的主库。如果这个从库之前没有开启 log-slave-updates，那么它成为新主库后，其二进制日志中不会包含旧主库的数据变更历史，导致其他从库无法从它这里完整地继续复制。开启此参数可以确保任何可能成为主库的从服务器都拥有完整的变更记录。
作为备份源：
如果你使用像 mysqldump --master-data 或 Percona XtraBackup 这样的工具从从库进行备份，并希望这个备份能够用于搭建新的从库，那么源从库必须开启 log-slave-updates，这样备份中才能包含正确的二进制日志位置信息。

此参数需要在从服务器的 MySQL 配置文件（如 my.cnf 或 my.ini）中设置，并且需要重启 MySQL 服务才能生效。

[mysqld]
server-id = 2           # 每个服务器必须有唯一的ID
log-bin = mysql-bin     # 必须开启二进制日志，此参数才有意义
log-slave-updates = ON  # 开启从库更新日志

重要前提：只有在从服务器上启用了二进制日志（即设置了 log-bin 参数）时，log-slave-updates 参数才会生效。

数据一致性：在开启 log-slave-updates 的复制链中，需要确保所有服务器的 server-id 都是唯一的，否则会导致复制异常。
过滤规则：如果在从库上设置了二进制日志过滤规则（如 binlog-do-db 或 binlog-ignore-db），这些规则会影响哪些事件被写入从库的二进制日志，进而影响下游的复制。强烈不建议在从库上使用这些过滤参数，容易造成数据不一致。
性能影响：开启此参数会增加从服务器的负载，因为它在应用数据的同时，还需要额外写入二进制日志。这会给磁盘 I/O 带来更多压力。
GTID 复制：在基于 GTID 的复制中，log-slave-updates 同样至关重要，因为它保证了从库会为自己应用的每个事务生成并记录对应的 GTID。

特性	描述
功能	控制从库是否将从中继日志执行的事件写入自己的二进制日志。
默认值	MySQL 8.0+ 为 `ON`，MySQL 5.7 及以下为 `OFF`。
应用场景	多级复制、高可用架构、从库作为备份源。
前提条件	从库必须启用二进制日志（`log-bin`）。
影响	允许从库成为其他服务器的主库，但会增加磁盘 I/O 负担。