sync_binlog=1要求每次事务提交都fsync()刷binlog到磁盘，但仅设该参数不保证真正落盘，需协同关闭磁盘/RAID写缓存、启用文件系统barrier，并配innodb_flush_log_at_trx_commit=1实现“双一”闭环。
sync_binlog=1 的目标很明确：让每次事务提交时，MySQL 都调用 fsync() 把 binlog 缓存强制刷到物理磁盘。但**光写 sync_binlog=1 并不等于“立即刷入物理磁盘”**——中间还隔着操作系统缓存、磁盘写缓存、甚至 RAID 卡缓存。下面分场景说清楚怎么做、为什么、以及容易被忽略的断层。
直接在 my.cnf 里写 sync_binlog=1 不够安全
你可以在 [mysqld] 段写下：
[mysqld] sync_binlog=1
这会让 MySQL 在每次 COMMIT 时调用 fsync()。但问题在于：
-
fsync()只保证数据进入磁盘驱动器的写缓存（write cache），不保证落盘； - 如果磁盘或 RAID 卡启用了 write-back 缓存（默认常见），且没禁用或没电池/电容保护，
fsync()返回成功后仍可能丢失； - 某些文件系统（如 ext4）在挂载时若用了
data=writeback或禁用了barrier，也会绕过写屏障，导致fsync()失效。
必须配合硬件和文件系统级配置
要真正达成“物理磁盘落盘”，需三层协同：
-
磁盘层：确认磁盘写缓存是否关闭。对 SATA/SAS 盘，用
hdparm -I /dev/sdX | grep "Write cache"查看；若显示enabled，需执行hdparm -W0 /dev/sdX（注意：重启失效，建议写入 udev 规则）； -
RAID 卡层：如使用 LSI/MegaRAID，需确认
WriteBack模式是否配有 BBU 或超级电容，否则强制设为WriteThrough； -
文件系统层：挂载时加
barrier=1（ext4 默认开启），禁用data=writeback；推荐挂载选项：defaults,noatime,barrier=1,errors=remount-ro。
sync_binlog=1 + innodb_flush_log_at_trx_commit=1 才算“双一”闭环
只设 sync_binlog=1，但 innodb_flush_log_at_trx_commit 是 0 或 2，会导致 InnoDB redo log 和 binlog 状态不一致。典型风险场景：
- 事务已写入 binlog 并
fsync()成功，但 InnoDB 还没把 redo log 刷盘； - 此时 crash，MySQL 启动后按 redo log 回滚该事务，但 slave 已经基于 binlog 执行了——主从数据不一致。
所以生产环境要求强一致性时，必须同时设置：
[mysqld] sync_binlog=1 innodb_flush_log_at_trx_commit=1
注意：innodb_flush_log_at_trx_commit=1 同样依赖底层存储是否真正落盘，它和 sync_binlog=1 是并行但独立的两个 fsync() 调用。
验证是否真生效，别只信配置文件
配置改完不等于生效，也不等于行为符合预期。验证要点：
- 确认运行时值：
SELECT @@global.sync_binlog;必须返回1； - 检查是否被动态覆盖：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'sync_binlog';； - 用
strace -e trace=fsync -p $(pidof mysqld)抓一段时间，观察fsync()调用频次是否接近事务提交频率（注意 group commit 会合并）； - 极端验证法：在高并发写入时突然断电，重启后比对
SHOW MASTER STATUS和从库SHOW SLAVE STATUS\G的Exec_Master_Log_Pos是否存在跳变或重复。
真正难的不是配参数，而是确认从 MySQL 内存 → OS page cache → 磁盘控制器缓存 → 物理闪存/磁盘扇区，这一整条链路没有一处“假装完成”。任何一层开了写缓存又没掉电保护，sync_binlog=1 就只是个乐观假设。
