从库备份会导致数据不一致，因备份获取的是延迟状态下的快照，而非主库实时状态；mysqldump --single-transaction 仅保证从库本地事务一致性，不感知主库进度，可能漏数据或超时；xtrabackup 会固化旧同步位点，pt-table-checksum 校验结果失真，掩盖真实问题。
从库备份时主从延迟会导致备份数据不一致
当 Seconds_Behind_Master 显示几十秒甚至数小时延迟，此时在从库上执行 mysqldump 或物理备份（如 xtrabackup），备份出来的数据**不是主库当前真实状态的快照**，而是“过去某个时间点”的状态。更危险的是，这个“过去时间点”无法精确对齐——因为备份过程本身耗时，而SQL线程仍在缓慢追赶，导致备份中途可能混入部分已同步、部分未同步的数据。
mysqldump --single-transaction 在延迟从库上不可靠
--single-transaction 依赖 InnoDB MVCC 生成一致性快照，但它只保证“从库自身在备份开始时刻的事务视图”，**完全不感知主库进度**。若此时从库 SQL 线程卡在某个大事务回放中，mysqldump 可能：
- 跳过尚未执行的 relay log 事务（即漏掉主库已写但从库还没回放的数据）
- 或因长事务阻塞，导致备份等待超时、被 kill，最终产出部分数据
- 即使成功完成，恢复后该备份与主库之间存在不可修复的行级差异
物理备份（xtrabackup）会固化延迟状态
xtrabackup 备份的是从库磁盘上的实际文件，它会忠实记录当前 relay-log.info 和 master.info 中的位置信息。问题在于：
- 备份里包含的
Exec_Master_Log_Pos是旧值，不代表主库最新位置 - 恢复该备份并重建从库后，新从库会从这个“落后的位置”继续同步，相当于把延迟固化为起点
- 若原主库已发生故障切换，该备份根本无法用于构建新集群，因为缺失关键变更
pt-table-checksum 校验结果失真
用 pt-table-checksum 对延迟从库做一致性校验时，工具默认读取从库当前数据并计算校验和，但：
- 它不会主动等待 SQL 线程追平，校验结果反映的是“延迟状态下的数据”
- 若主库刚执行了 DDL（如
ALTER TABLE），而从库尚未应用，校验会直接报错或跳过该表，掩盖真正问题 - 误将延迟当作不一致处理，可能触发错误的修复流程（如
pt-table-sync），造成数据覆盖
最隐蔽的风险是：延迟本身不报错，备份和校验工具也“运行成功”，但所有产物都带着时间差缺陷。线上出问题时才发现，备份不能用、校验不准、恢复后业务逻辑断裂——这类问题往往要翻日志比对 binlog 位置才能定位，耗时远超预防成本。
