MySQL主从复制不保证强一致性，需通过半同步复制、定期校验（pt-table-checksum）、禁止从库写入、规范SQL操作及监控延迟等手段保障一致性。
MySQL主从复制本身不自动保证强一致性，需结合配置、监控和运维手段来尽量减少数据差异。核心思路是：降低复制延迟、避免写入从库、及时发现并修复不一致。
启用半同步复制（Semi-sync Replication）
默认异步复制下，主库提交事务后不等待从库确认就返回成功，存在主库宕机而从库未收到日志的风险。半同步可强制至少一个从库写入 relay log 后，主库才提交。
- 主库安装插件：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; - 从库安装插件：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; - 主库启用：
SET GLOBAL rpl_semi_sync_master_enabled = 1; - 从库启用：
SET GLOBAL rpl_semi_sync_slave_enabled = 1;（需重启 IO 线程生效） - 建议搭配超时参数：
rpl_semi_sync_master_timeout = 10000（毫秒），避免主库长时间阻塞
校验与修复主从数据差异
即使复制正常，因语句级复制（STATEMENT）、非确定函数、跨库操作等，仍可能产生隐性不一致。需定期主动校验。
- 使用 pt-table-checksum（Percona Toolkit）在主库执行，生成校验和并同步到从库比对
- 校验前确保从库
Seconds_Behind_Master = 0，且无长事务阻塞 - 发现不一致后，用 pt-table-sync 生成修复 SQL（建议先在测试环境验证）
- 避免直接在从库执行写操作；修复应通过主库变更或停写后重建从库
规避导致不一致的常见操作
很多“看似安全”的操作会悄悄破坏一致性，需在规范层面约束。
- 禁用
SQL_LOG_BIN = 0在从库执行 DML —— 这类操作不记 binlog，主库无法感知，后续复制可能冲突 - 避免使用
NOW()、UUID()、USER()等非确定函数（ROW 格式可缓解，但仍建议用常量或应用层生成） - 不要在从库创建临时表后执行依赖它的语句（临时表不复制，从库报错或跳过）
- DDL 操作（如
ALTER TABLE）需评估锁表时间，大表建议用 pt-online-schema-change 减少主从延迟激增
监控关键指标并设置告警
一致性是动态结果，靠人工检查不可持续。必须建立可观测性闭环。
- 核心指标：
Seconds_Behind_Master（延迟秒数）、Slave_SQL_Running和Slave_IO_Running（是否为 Yes）、Retrieved_Gtid_Set与Executed_Gtid_Set是否一致（GTID 模式下） - 延迟超过阈值（如 60 秒）需触发告警，并自动采样
SHOW PROCESSLIST和慢查询日志定位原因 - 建议用 Prometheus + mysqld_exporter + Grafana 可视化趋势，比单纯看数值更易发现抖动模式
- 每日定时跑 checksum，并将结果存档，便于回溯对比
