MySQL主从复制确定性丢数据的四大根源：一是binlog_format非ROW导致NOW()/UUID()等函数重算失真；二是sync_binlog与innodb_flush_log_at_trx_commit未全设为1，主库崩溃丢已确认事务；三是binlog被过早purge，从库无法拉取；四是半同步未校验SQL线程执行位点，切主时丢失“已收未执”事务。
MySQL主从复制丢失部分数据，不是偶然故障，而是配置、操作或架构层面的确定性后果——只要某个关键环节没对齐，丢数据就是时间问题。
binlog_format 不是 ROW 时，非确定性函数直接导致逻辑不一致
STATEMENT 或 MIXED 模式下，NOW()、UUID()、SYS_DATE() 这类函数在从库重放时会重新求值，主从记录的时间戳、ID 完全不同。比如主库插入 INSERT INTO log VALUES (UUID(), NOW())，从库执行时生成另一个 UUID 和当前时间，表面“成功”，实则数据已失真。
- 必须执行
SET GLOBAL binlog_format = 'ROW'，并写入my.cnf的[mysqld]段 + 重启才生效 - MySQL 8.0+ 虽默认 ROW，但升级后务必验证：
SELECT @@binlog_format; - ROW 模式日志体积大，但这是保一致的必要代价；混有 MyISAM 表不影响 ROW 生效，只是无法事务快照导出
sync_binlog 和 innodb_flush_log_at_trx_commit 任一为 0/2，主库崩溃即丢事务
主库提交事务后，若 sync_binlog != 1 或 innodb_flush_log_at_trx_commit != 1，binlog 或 redo log 可能只写入页缓存未刷盘。断电或 kill -9 后，这部分已返回客户端“成功”的事务，从库永远收不到。
-
sync_binlog = 1：每个事务都fsyncbinlog 文件 -
innodb_flush_log_at_trx_commit = 1：每个事务都刷 redo 到磁盘 - 两者缺一不可；设为 0 或 2 是为性能妥协，但在金融、订单等场景等于主动放弃数据完整性
主库 binlog 被提前 purge，从库根本没机会拉取
主从同步中断期间，若 expire_logs_days 过小（如设为 1）、磁盘满触发自动清理，或运维误执行 PURGE BINARY LOGS，会导致从库尚未读取的 binlog 被删。此时 SHOW SLAVE STATUS 报错 Could not find first log file name，已不可逆。
- 生产环境
expire_logs_days至少设为 7，且禁用自动清理，改用校验脚本手动PURGE BINARY LOGS TO 'xxx' - 监控
df -h /var/lib/mysql，使用率超 85% 时告警，避免 MySQL 主动 purge 保命 - 用
SHOW BINARY LOGS;和从库Read_Master_Log_Pos对比，确认最老 binlog 是否已被消费完
半同步复制开启但未校验 SQL 线程执行位点，切主即丢“已收未执”事务
半同步只保证至少一个从库收到 binlog 并写入 relay log，不保证已执行。若切换时选中了 Read_Master_Log_Pos == Master_Log_File 但 Exec_Master_Log_Pos 明显滞后的从库，那些“已接收、未执行”的事务就永远消失了。
- 切主前必须检查：
Seconds_Behind_Master = 0且Slave_SQL_Running_State = 'Slave has read all relay log' - 优先选
Read_Master_Log_Pos == Exec_Master_Log_Pos的从库；否则宁可停写等待追平 - 工具如 MHA 默认不校验执行位点，需额外配置或人工介入
真正难防的不是单点故障，而是多个“看起来合理”的配置叠加后形成的盲区——比如开了半同步却忘了调 rpl_semi_sync_master_timeout，结果超时退化成异步还不自知；又比如设了 relay_log_recovery = ON 却没配 relay_log_info_repository = TABLE，导致恢复逻辑失效。这些细节不暴露在报错里，只在丢数据那一刻才浮现。
