备份时FLUSH TABLES WITH READ LOCK会阻塞从库SQL线程，导致Seconds_Behind_Master飙升、relay_log_space_limit耗尽、IO线程退避、pt-heartbeat失效，最终造成不可控的非线性延迟与PITR失准。
备份时从库被 FLUSH TABLES WITH READ LOCK 阻塞
mysqldump 或 xtrabackup 在从库执行全量备份时，会先触发 FLUSH TABLES WITH READ LOCK。这个命令会获取全局读锁，而从库的 SQL 线程必须等待该锁释放才能继续回放 relay log。一旦备份持续时间长（比如大表、慢磁盘），SQL 线程就卡住，Seconds_Behind_Master 会指数级上涨——不是因为网络或性能差，而是被自己备份操作主动“冻结”了同步。
备份期间 relay_log_space_limit 耗尽导致 IO 线程退避
从库中继日志空间受 relay_log_space_limit 控制。备份过程中 SQL 线程停滞，IO 线程却仍在持续写入 relay log，很快就会触达上限。此时 IO 线程自动暂停拉取 binlog，主库新产生的变更完全无法进入从库，延迟开始真实累积。你看到的 Seconds_Behind_Master 值，其实是“堆积 + 冻结”双重叠加的结果。
备份完成后的恢复窗口不可控
备份结束、锁释放后，SQL 线程才开始追赶积压的 relay log。如果积压量大（例如备份花了 15 分钟，期间主库写了 20 万行），追赶过程本身可能再耗 10–30 分钟。这意味着：你拿到的备份数据，实际对应的是 15–45 分钟前的主库状态，且这个偏移量每次都不固定——业务无法据此做精确的时间点恢复（PITR）或一致性校验。
为什么 pt-heartbeat 在备份期间也失效
pt-heartbeat 依赖在主库定时写入心跳表、从库实时比对时间戳来计算延迟。但当从库 SQL 线程被锁住时，心跳记录无法被回放，pt-heartbeat 检测到的延迟会直接跳变为“无限大”或报错，掩盖真实同步进度。它无法区分是网络中断、SQL 线程崩溃，还是人为锁表——而这三者对备份时效性的影响完全不同。
