MySQL 8.0 一主两从，物理备份挂在从库上，主库一次大事务让从库延迟到 600 秒，备份正好在延迟期间启动，恢复出来的数据比预期少了四十分钟的写入。
一开始怀疑是「从库开了并行复制，relay log 的应用位置和位点不是线性对应」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。备份开始时 Seconds_Behind_Source 已经很大，快照落在旧位置。少数情况下是工具记录的是 binlog 位点，恢复时从该位点往后追，中间事务被跳过。
还有一种情况，备份脚本没有校验延迟，拉起任务就开始拷文件。
第一件事是备份前先确认延迟
mysql -e 'SHOW REPLICA STATUS\G' | grep -E 'Seconds_Behind_Source|Exec_Source_Log_Pos|Read_Source_Log_Pos'延迟清零后再启动备份
mysql -e 'STOP REPLICA SQL_THREAD; START REPLICA SQL_THREAD;' && sleep 30接着记录备份的一致性位点
mysql -e 'SHOW MASTER STATUS\G' | tee /data/backup/pos-$(date +%F).txt恢复后按位点核对数据
mysql -e 'SELECT MAX(id) FROM orders' && cat /data/backup/pos-2026-11-10.txt改完先别撤，确认这几项。恢复库的 GTID 集合与备份位点一致，订单表最大 id 与主库当时的值相同，备份前延迟指标为 0。
补一句。从库备份的前提是延迟为零，靠 sleep 猜不可靠；用 GTID 记录位置比 binlog 文件加偏移更稳，跨机房恢复少踩坑。报错文案容易误导，真正的原因往往在相邻那一层的日志里。