前几天有个朋友半夜给我打电话，说他们公司的 MySQL 从库宕机了，恢复后主从数据对不上，业务已经报错了。我问他是怎么恢复的，他说直接重启了从库，然后用 change master 重新搭建主从关系。听完我就知道问题出在哪儿——这哥们儿根本没管 binlog 的位置，直接让从库从头同步，结果主库早就把旧的数据清理掉了，中间缺了一大段。这种情况其实特别常见，尤其是那些对 MySQL 运维不够重视的团队，动不动就翻车。
先说说从库宕机后最常见的坑。很多人觉得从库挂了，重启一下不就完事儿了，简单粗暴。但问题在于，从库宕机时，主库还在继续写数据，binlog 一直在滚动。等你把从库拉起来，它记录的同步位置可能早就被主库的 binlog 清理策略给删掉了。比如主库设置了 binlog 保留 7 天，从库宕了 10 天，那中间 3 天的数据就彻底丢了。这时候再执行 change master， 从库只能从最新位置开始同步，之前缺的那部分数据根本补不回来，主从数据就永远对不上了。
更麻烦的是，有些从库宕机不是因为硬件故障，而是因为主库压力太大，导致从库的 iothread 或 sqlthread 卡死。这种情况下，从库可能已经积累了大量的 relay log 没来得及应用，但 binlog 的位置却还在往前跑。等你重启从库，它只会按照文件里记录的位置继续同步，而这个位置早已和实际的数据状态错位。我见过最夸张的案例：从库宕了三天，主库的 binlog 位置跑了上百万条记录，从库重启后直接报错 1062（主键冲突），就是因为重复插入了已经存在的数据。
那怎么判断主从数据到底有没有不一致呢？最简单的办法是用 pt-table-checksum 这个工具，Percona Toolkit 里的神器。它能对比主库和从库的每一行数据，生成报告告诉你哪些表的哪些行对不上。但注意，这玩意儿跑起来挺吃资源的，尤其是大表，建议在业务低峰期执行。我一般会先查看主库的 binlog 位置和从库的 execmasterlogpos 是否一致，如果差距太大，基本可以断定数据已经出问题了。还有一种土办法：随便找一张有自增主键的表，在主库插入一条数据，看看从库能否同步过来。该方法只能验证同步是否正常，查不出深层次的不一致。
如果已经确定数据不一致，最稳妥的恢复方案是重新搭建从库。具体步骤如下：先在主库上执行 FLUSH TABLES WITH READ LOCK ，把主库锁成只读状态，然后记录当前的 binlog 文件名和位置。接着用 mysqldump 或 xtrabackup 把主库的数据全量导出，传到从库上恢复。恢复完后，再根据之前记录的位置重新配置主从关系。这个过程虽然繁琐，但能保证主从数据完全一致。有人嫌麻烦，想用 pt-table-sync 直接修复不一致的数据，这个工具确实能修，但只适用于小范围的不一致；如果是大面积的错乱，还是老老实实重搭从库更可靠。
说到这儿，不得不提一个常见误区：很多人以为只要从库的 SecondsBehindMaster 显示为 0，就说明主从数据一致。这是大错特错。 SecondsBehindMaster 只能说明从库的 sqlthread 追上了 iothread，然而 iothread 本身可能已经在错误的位置上。比如从库的 relay log 因网络丢包， iothread 却认为已经收到了足够的数据，这时 SecondsBehindMaster 仍然是 0，但实际数据已经对不上了。所以千万别迷信这个指标，它只能作为参考，不能当金标准。
平时怎么预防这种问题？我建议从两个维度入手。一是监控层面，实时告警从库的 iothread 和 sql_thread 状态，一旦发现它们停止运行，立刻报警并自动记录当前的 binlog 位置。二是备份层面，定期用 xtrabackup 对从库做全量备份，这样即使从库彻底挂了，也能用备份快速恢复，而不是依赖主库的 binlog。还有，主库的 binlog 保留时间尽量设置长一点，比如 7 到 14 天，给从库故障恢复留足缓冲期。有些公司为了省磁盘空间，把 binlog 只保留 3 天，结果从库一宕机就抓瞎，省下的那点空间根本不够买后悔药。
说个真实案例。去年有个电商客户，大促期间从库宕了，运维小哥图省事，直接 RESET SLAVE 然后重新配置，结果导致订单数据对不上，用户下单了但库存没扣减，最终造成了十几万的损失。事后复盘发现，如果当时先用 pt-table-checksum 检查一下，或者老老实实重搭从库，根本不会出这个事。所以，MySQL 主从架构看似简单，但坑都在细节里。别等到数据对不上了才想补救，平时多留个心眼，把监控和备份做到位，比什么都强。毕竟，运维的终极目标不是解决问题，而是让问题压根儿不发生。
