log_slave_updates未开启时，从库不会将主库同步的变更写入自身binlog，导致链式复制中断；必须与log-bin同时启用、配置在[mysqld]段并重启生效，运行时需验证@@log_slave_updates=1。
log_slave_updates 不开，从库复制的数据就不会进 binlog
这是最核心的事实：即使从库已开启 log-bin，它默认也不会把「通过 SQL 线程重放 relay log 得到的数据变更」写入自己的 binlog。只写直接在从库上执行的语句（比如手工 INSERT），不写主库同步过来的变更。
这意味着：如果这个从库还要作为其他从库的主库（即链式复制），下游从库将完全收不到上游主库的数据变更——因为中间这层从库的 binlog 是空的。
常见错误现象：
- 下游从库的
Seconds_Behind_Master一直为 0，但数据明显没同步过来 -
SHOW BINLOG EVENTS IN 'mysql-bin.000001'查不到任何来自主库的 INSERT/UPDATE 记录 - 手动在从库上执行
INSERT INTO test.t1 VALUES (1)能看到 binlog，但主库同步的同一条记录却没日志
log_slave_updates 必须和 log-bin 同时启用才生效
单独加 log_slave_updates = ON 没用，log-bin 必须已开启，否则 MySQL 启动时会忽略该参数，甚至报错（5.7+ 版本会警告，8.0 更严格）。
配置要点：
- 必须写在
[mysqld]段下，不能动态 SET（该参数是只读的，需重启生效） - 推荐显式写成
log_slave_updates = ON，而不是1或空值，避免歧义 - 如果使用多实例（如 3306/3307），每个需要转发 binlog 的实例都得单独配
示例配置片段：
[mysqld] server-id = 102 log-bin = mysql-bin log_slave_updates = ON binlog_format = ROW
不开 log_slave_updates 的典型场景会出问题
不是所有从库都需要开它，但以下情况一旦漏掉，链路就断了：
- 主 → 从A → 从B 的三级复制结构中，从A 是从B 的主库，就必须开
- 主库做异地容灾，中间用一台从库做 binlog 中转（比如过滤、延迟、格式转换），它必须能产出完整 binlog
- 用 pt-table-checksum 做跨级一致性校验时，工具依赖从库 binlog 位置推进，不开会导致校验卡住或误报
性能影响极小：只是多一次 binlog 写入，IO 开销可忽略；但不加的风险是整条复制链失效，远大于这点成本。
验证 log_slave_updates 是否真正生效
不能只看配置文件有没有写，要确认运行时状态：
- 连接从库后执行
SELECT @@log_slave_updates;，返回 1 才算启用 - 执行
SHOW VARIABLES LIKE 'log_slave_updates';，检查值是否为ON - 在主库写一条数据，然后立刻在从库查
SHOW MASTER STATUS;和SHOW BINLOG EVENTS LIMIT 10;，确认新事件已出现在其 binlog 中
最容易被忽略的是：改完配置忘记重启 MySQL 进程，或者重启后没检查 @@log_slave_updates 实际值——配置写了≠生效。
