sync_binlog=1是主库防丢数据的硬性前提，强制每次事务提交都fsync落盘binlog，确保崩溃后binlog不丢失；备库可设为>1但需满足relay_log_info_repository=TABLE、relay_log_recovery=ON及非GTID模式，否则易引发GTID跳号或重复执行。
sync_binlog=1 是防丢数据的硬性前提
主库上，sync_binlog=1 是防止 binlog 丢失、保障事务提交后数据可恢复的最低要求。它强制每次事务提交都触发 fsync，把 binlog 缓冲区内容真正写入磁盘。不设为 1，哪怕 innodb_flush_log_at_trx_commit=1（Redo Log 落盘），也存在 binlog 未落盘而主库崩溃导致复制中断或 PITR 失败的风险。
常见错误现象：SHOW SLAVE STATUS 显示 Seconds_Behind_Master 正常，但主库断电重启后，从库报错 Could not execute Write_rows event on table... 或 GTID 跳号/重复；用 mysqlbinlog 查看最新 binlog 文件末尾缺失最近若干事务。
- 必须在
my.cnf中配置并重启生效：sync_binlog=1 - 不能只靠
SET GLOBAL sync_binlog = 1—— 该命令在某些 MySQL 版本中不持久，且部分场景下（如已开启 binlog 的连接）可能不立即生效 - 搭配
innodb_flush_log_at_trx_commit=1才构成“双一标准”，完整覆盖 Redo Log 和 Binlog 两个持久化链路
备库可以不设 sync_binlog=1，但必须满足三个条件
备库的 binlog 本质是 relay log 的二次输出（启用 log_slave_updates 时），其丢失不直接影响主从一致性，但会破坏 GTID 连续性和后续级联复制。能否设 sync_binlog>1 取决于是否接受 GTID 跳号和是否启用位置模式回放。
只有同时满足以下三点，才建议在备库设 sync_binlog=1000 类似值：
-
relay_log_info_repository = TABLE（复制位点存于 InnoDB 表，崩溃可恢复） -
relay_log_recovery = ON（启动时自动修复 relay log 与位点一致性） - 复制模式为传统文件位置（
MASTER_AUTO_POSITION = 0），而非 GTID 自动定位
若启用了 GTID（gtid_mode=ON）且依赖 MASTER_AUTO_POSITION = 1，备库 sync_binlog>1 极易引发 Duplicate entry 报错——因为本地已执行的事务在 binlog 中缺失，GTID 恢复机制会重拉并重放。
sync_binlog=N（N>1）的实际性能收益很有限
设 sync_binlog=100 或 1000 并不意味着性能线性提升。真实瓶颈往往不在 binlog fsync 频次，而在磁盘 I/O 吞吐、IOPS 或日志刷盘争用。实测表明，在 NVMe SSD 上，sync_binlog=100 相比 =1 的 TPS 提升通常不足 15%，却引入最多 99 个事务的丢失窗口。
更关键的是：这个“N”不是越大越好。MySQL 内部按事务提交顺序累积计数，但若高并发下多个事务几乎同时提交，fsync 仍可能被合并调度；而一旦 N 超过 1000，单次刷盘数据量增大，反而可能加剧 IO 延迟毛刺。
- 推荐值仅限
sync_binlog=10～100，且必须配合压测验证（例如用sysbench对比oltp_point_select+oltp_update_non_index混合场景） -
sync_binlog=0完全不可取——它把刷盘交给操作系统，30 秒周期不可控，崩溃丢失风险极高，连测试环境都不应使用
验证 sync_binlog 是否真正生效
配置后不能只看 SHOW VARIABLES LIKE 'sync_binlog' 返回 1 就认为万事大吉。要确认它实际参与了事务提交路径，需检查 binlog 写入行为是否符合预期。
最直接的方式是抓包或使用 strace 观察 mysqld 进程的系统调用（生产环境慎用），更稳妥的是通过 binlog 文件时间戳与事务时间交叉验证：
- 开启 general log 记录事务提交时间：
SET GLOBAL general_log = ON - 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A 2 "COMMIT"查看每个 COMMIT 事件的时间戳 - 对比 general log 中对应事务的
COMMIT时间与 binlog 里该事件的 timestamp —— 若sync_binlog=1，二者时间差应在毫秒级；若差几百毫秒甚至秒级，说明配置未生效或被其他参数覆盖
最容易被忽略的一点：Docker/K8s 环境下，MySQL 容器若挂载了 hostPath 或 NFS 卷，fsync 可能被底层存储截断或延迟，此时 sync_binlog=1 在语义上成立，但物理落盘并不及时。务必在目标存储上做 fio 测试验证 fsync 延迟。
