从库开启binlog后mysqldump无法保证一致性，因--single-transaction仅冻结innodb快照却不阻塞relay log应用，且show master status返回的是从库自身binlog位点而非主库同步位点exec_master_log_pos；真正可回溯的一致性位点必须以主库show master status结果为基准，并严格验证从库relay_master_log_file和exec_master_log_pos与之完全匹配。
为什么从库开启 binlog 后 mysqldump 无法保证一致性位点
因为 mysqldump --single-transaction 只能冻结 InnoDB 表的 MVCC 快照，但完全不干预 relay log 的应用进程。备份过程中如果从库仍在执行 SQL_THREAD，导出的数据就卡在某个中间状态：既不是主库当时的完整快照，也不是从库当前已同步到的位置。更危险的是，SHOW MASTER STATUS 返回的是从库自身 binlog 的 File 和 Position，而非它实际同步到主库的 Exec_Master_Log_Pos —— 用这个值做恢复锚点，大概率跳过大量未应用事件。
如何获取真正可回溯的一致性位点（主库为唯一权威）
必须以主库的 binlog 位点为唯一基准，再确认从库已追平该点。操作要点：
- 在主库低峰期执行
FLUSH TABLES WITH READ LOCK（或对关键库用LOCK TABLES ... READ LOCAL配合mysqldump --lock-for-backup） - 立刻执行
SHOW MASTER STATUS，记下File（如mysql-bin.000042）和Position（如198765） - 在从库执行
STOP SLAVE，再查SHOW SLAVE STATUS\G，严格比对Relay_Master_Log_File和Exec_Master_Log_Pos是否与主库一致 - 只有二者完全匹配，才能认为从库数据已精确对齐主库该位点，此时 dump 才具备可回溯性
非停机场景下怎么安全获取一致性位点
当无法锁主库或业务不能容忍 STOP SLAVE 时，pt-table-checksum + pt-table-sync 是更务实的选择：
- 先用
pt-table-checksum在主库运行校验，生成 checksum 表并同步到从库 - 再用
pt-table-sync --sync-to-master检查从库是否已追平主库最新校验点；若存在延迟，它会提示具体 lag - 确认无 lag 后，再执行
mysqldump --no-lock --skip-triggers --databases，并手动记录当前SHOW SLAVE STATUS中的Master_Host/Relay_Master_Log_File/Exec_Master_Log_Pos - 该三元组才是真实反映“从库此刻同步到主库哪条 binlog 哪个位置”的一致性位点
XtraBackup 备份时怎样确保位点不丢
xtrabackup 默认不记录 GTID 或 position，必须显式启用参数才可靠：
- 对主库直备：加
--source-data=2，会在xtrabackup_info中写入CHANGE MASTER TO语句，含准确的MASTER_LOG_FILE和MASTER_LOG_POS - 对已有从库转主再备：用
--dump-slave=2，它执行SHOW SLAVE STATUS并提取Relay_Master_Log_File和Exec_Master_Log_Pos - 两种方式都要求备份期间主库不能重启，否则
gtid_executed可能截断，导致恢复后 GTID 不连续
真正容易被忽略的，是位点本身没有意义 —— 它必须和对应时刻的物理/逻辑数据严格绑定。哪怕只差一行数据没刷盘、一个 relay log event 没 apply，那个位点就是假的。
