背景某客户主从不同步下面是模拟场景主库执行 truncate 后从库数据未同步复制状态却一切正常、不报任何错误——这正是“主库改了从库不同步、复制还不报错”这类最难排查的问题。本文通过一次完整的模拟排查还原问题现象、定位根因并给出可落地的预防方案。一、问题现象主库truncate/update/delete表从库数据未同步主库截断一个表从库延迟是0但是表还有数据二、排查过程确认复制链路是否健康首先确认主从复制链路本身是否正常排除复制中断或指向错误主库的可能。主库 SELECT server_id, hostname, server_uuid; SHOW MASTER STATUS; -- 看当前写的是哪个 binlog 文件/位置 从库 SHOW SLAVE STATUS\G -- 看 Master_Host / Master_Server_Id / Master_UUID SELECT * FROM performance_schema.replication_connection_status\G 判定规则 执行 truncate 节点的 server_uuid 等于从库的 Master_UUID4089baa2-...、server_id 等于 513306 → 那它就是真主库进入下面第 3 步继续查 不相等 → 你敲命令的机器不是这台从库的上游复制不同步是必然的。请确认当前真实主库.51在真正的上游上重新验证 truncate。 主库 看 truncate 到底有没有产生事务、落在哪个 binlog SHOW BINLOG EVENTS IN mysql-bin.000005 FROM 1 LIMIT 20;三、初步结论truncate 未写入 binlog结论truncate 没有写进 binlog被会话级 sql_log_bin0 跳过了所以永远不会同步到从库。这次所有证据都齐了链路本身完全健康问题不在复制而在主库那一条 truncate 根本没进二进制日志。四、根因验证确认 sql_log_bin0主库正常打开binlog记录截断表为什么执行成功、本地生效、却不进 binlog、不耗 GTID只有一个原因主库这个会话执行 truncate 时 sql_log_bin0维护时常见的残留设置或某脚本里 SET SESSION sql_log_bin0 没复原。sql_log_bin0 时所有语句只在本地生效既不写 binlog 也不分配 GTID因此对从库隐形。请主库执行确认基本可以一锤定音如果 sql_log_bin 0根因就坐实了。SELECT sql_log_bin, log_bin, enforce_gtid_consistency;五、收尾提醒避免同类问题复发以后凡是为做维护临时关过 sql_log_bin操作完一定 SET sql_log_bin1否则这类主库改了从库不同步、复制还全是 Yes 且不报错的坑会反复出现且因为不报错最难排查。为了彻底避免同类问题复发建议把以下安全检查清单固化为每次维护操作的固定流程操作前记录基线执行任何可能影响复制的维护前先记录当前会话的 sql_log_bin 值确认它是否为 1同时记录 binlog 位点SHOW MASTER STATUS作为回滚参照。操作后立即恢复维护语句执行完毕后第一时间执行 SET SESSION sql_log_bin1并在同一会话内再次查询 sql_log_bin 确认已恢复避免残留设置影响后续语句。业务/跑批场景禁止使用 sql_log_bin0 防止关掉忘了开的隐患长期潜伏。 
长河君 · 2026/10/18 7:57:32 · 阅读 1.2k MySQL 主从不同步排查实录：一条 truncate 为何对从库“隐形”
背景某客户主从不同步下面是模拟场景主库执行 truncate 后从库数据未同步复制状态却一切正常、不报任何错误——这正是“主库改了从库不同步、复制还不报错”这类最难排查的问题。本文通过一次完整的模拟排查还原问题现象、定位根因并给出可落地的预防方案。一、问题现象主库truncate/update/delete表从库数据未同步主库截断一个表从库延迟是0但是表还有数据二、排查过程确认复制链路是否健康首先确认主从复制链路本身是否正常排除复制中断或指向错误主库的可能。主库 SELECT server_id, hostname, server_uuid; SHOW MASTER STATUS; -- 看当前写的是哪个 binlog 文件/位置 从库 SHOW SLAVE STATUS\G -- 看 Master_Host / Master_Server_Id / Master_UUID SELECT * FROM performance_schema.replication_connection_status\G 判定规则 执行 truncate 节点的 server_uuid 等于从库的 Master_UUID4089baa2-...、server_id 等于 513306 → 那它就是真主库进入下面第 3 步继续查 不相等 → 你敲命令的机器不是这台从库的上游复制不同步是必然的。请确认当前真实主库.51在真正的上游上重新验证 truncate。 主库 看 truncate 到底有没有产生事务、落在哪个 binlog SHOW BINLOG EVENTS IN mysql-bin.000005 FROM 1 LIMIT 20;三、初步结论truncate 未写入 binlog结论truncate 没有写进 binlog被会话级 sql_log_bin0 跳过了所以永远不会同步到从库。这次所有证据都齐了链路本身完全健康问题不在复制而在主库那一条 truncate 根本没进二进制日志。四、根因验证确认 sql_log_bin0主库正常打开binlog记录截断表为什么执行成功、本地生效、却不进 binlog、不耗 GTID只有一个原因主库这个会话执行 truncate 时 sql_log_bin0维护时常见的残留设置或某脚本里 SET SESSION sql_log_bin0 没复原。sql_log_bin0 时所有语句只在本地生效既不写 binlog 也不分配 GTID因此对从库隐形。请主库执行确认基本可以一锤定音如果 sql_log_bin 0根因就坐实了。SELECT sql_log_bin, log_bin, enforce_gtid_consistency;五、收尾提醒避免同类问题复发以后凡是为做维护临时关过 sql_log_bin操作完一定 SET sql_log_bin1否则这类主库改了从库不同步、复制还全是 Yes 且不报错的坑会反复出现且因为不报错最难排查。为了彻底避免同类问题复发建议把以下安全检查清单固化为每次维护操作的固定流程操作前记录基线执行任何可能影响复制的维护前先记录当前会话的 sql_log_bin 值确认它是否为 1同时记录 binlog 位点SHOW MASTER STATUS作为回滚参照。操作后立即恢复维护语句执行完毕后第一时间执行 SET SESSION sql_log_bin1并在同一会话内再次查询 sql_log_bin 确认已恢复避免残留设置影响后续语句。业务/跑批场景禁止使用 sql_log_bin0 防止关掉忘了开的隐患长期潜伏。