MySQL迁移过程如何避免数据不一致_利用强一致性备份方案

mysqldump加--single-transaction不保证强一致，仅对InnoDB表有效，且依赖REPEATABLE READ隔离级别；MyISAM表、DDL操作或隔离级别变更均破坏一致性。mysqldump 加 --single-transaction 不等于强一致很多人以为加了 --single-transaction 就能拿到全库一致性快照，实际不是——它只对 InnoDB 表生效，遇到 MyISAM 表、临时表、或者备份中途有 DDL（比如 ALTER TABLE），快照就失效了。更关键的是，--single-transaction 依赖事务隔离级别为 REPEATABLE READ，而某些 ORM 或中间件会悄悄改隔离级别，导致 dump 出来的时间点不统一。实操建议：先用 SELECT ENGINE, TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db'; 检查是否混用引擎备份前显式执行 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;如果存在 MyISAM 表，必须配合 --lock-all-tables（会锁写），不能只靠 --single-transaction避免在备份窗口内执行任何 DDL；可用 SHOW PROCESSLIST 监控长事务阻塞GTID + mysqldump --set-gtid-purged=ON 才能准确定位起点单纯导出 SQL 文件，恢复后无法知道这条数据对应主库哪个 GTID，也就没法做后续的增量同步或校验。漏掉 --set-gtid-purged=ON（或设为 OFF）会导致生成的 dump 文件里没有 SET @@GLOBAL.GTID_PURGED 语句，恢复到新实例后 GTID 集为空，binlog 位置完全脱钩。实操建议：务必确认源库已开启 gtid_mode=ON 且 enforce_gtid_consistency=ONdump 命令中显式加上 --set-gtid-purged=ON（默认值在新版 MySQL 中已是 AUTO，但行为不稳定，必须显式声明）检查 dump 文件开头是否有类似 SET @@GLOBAL.GTID_PURGED='a1b2c3e4-5678-90ab-cdef-1234567890ab:1-100'; 的行恢复时目标实例也需开启 GTID，且 gtid_executed 必须为空（否则报错 GTID_PURGED can only be set when GTID_EXECUTED is empty）用 pt-table-checksum 校验前，先停写或切读写分离流量pt-table-checksum 本身不锁表，但它依赖主从复制延迟接近零才能比对准确。如果迁移后刚切流，应用还在往旧库写、新库靠延迟同步，checksum 结果全是“不一致”，但这不是数据问题，是时间差问题。 Zeemo AI 一款专业的视频字幕制作和视频处理工具