mysql replication 不适用于一次性迁移，本质是持续同步而非快照导出；适合场景仅限旧库不可停机或目标已部署从库需补增量；gtid模式下应使用mysqldump加--set-gtid-purged=on并执行reset slave all收尾。
MySQL Replication 不是为一次性迁移设计的
直接用主从复制做“数据迁移”容易掉坑里——它本质是持续同步机制，不是 mysqldump 或 mysqlpump 那种快照式导出。如果你只是想把旧库搬到新服务器并停用旧库，走复制流程反而多出一堆状态管理、GTID 对齐、IO/SQL 线程监控等冗余操作。
真正适合迁移的场景只有两个：
一是旧库不能停机，需要边跑边切；
二是目标环境已部署好从库，只需补全最新增量。
常见错误现象：
• 启动从库后 SHOW SLAVE STATUS\G 显示 Seconds_Behind_Master: NULL 且 Slave_IO_Running: No
• 手动执行 CHANGE MASTER TO 后报错 ERROR 3021 (HY000): This operation cannot be performed with a running slave io_thread
• 切换后发现部分事务丢失，尤其跨库 DDL 或临时表操作没同步
必须先获取一致位点再配从库
想让从库和主库起点对齐，不能靠“现在停写、立刻 FLUSH TABLES WITH READ LOCK、然后 SHOW MASTER STATUS”，因为锁释放到从库执行 CHANGE MASTER TO 之间存在时间差，主库可能已写入新 binlog。
实操建议（GTID 模式下更稳妥）：
• 主库开启 gtid_mode=ON + enforce_gtid_consistency=ON
• 备份时用 mysqldump --single-transaction --master-data=2 --set-gtid-purged=ON，这样 dump 文件开头自带 SET @@GLOBAL.GTID_PURGED='...'
• 从库导入后，直接执行 START SLAVE 即可，不用手动指定 binlog 文件和位置
• 若用非 GTID 模式，必须在 FLUSH TABLES WITH READ LOCK 后**立刻**执行 SHOW MASTER STATUS，记录 File 和 Position，且锁不能释放，直到从库 CHANGE MASTER TO 并 START SLAVE 成功
过滤规则要设在从库，别碰主库 binlog
迁移时经常想“只同步某几个库”，有人会去主库改 binlog-do-db，这是危险操作：一旦漏配或拼错，主库 binlog 就不完整，后续恢复或审计全崩。
正确做法全在从库端：
• 使用 replicate_do_db（按 USE db 判断，有陷阱）或更可靠的 replicate_replicate_wild_do_table
• 示例：只同步 app_db 下所有表，配置 replicate_wild_do_table = app_db.%
• 注意：这些参数必须写在从库的 my.cnf 中并重启生效，运行时用 SET GLOBAL 修改无效
• 如果主库用了 innodb_file_per_table=OFF，迁移后从库建表可能因共享表空间路径不同而失败，需提前检查 datadir 和 innodb_data_home_dir
STOP SLAVE 后的状态清理常被忽略
完成迁移验证、准备切流时，很多人 STOP SLAVE 就完事，但残留的复制元数据会让后续操作混乱：
• SHOW SLAVE STATUS 里的 Master_Host、Master_User 还在，下次误启 START SLAVE 会连错源
• relay_log.info 和 master.info 文件未清空，可能保留旧 binlog 位置，导致跳过本该重放的事务
• 正确收尾动作：
– STOP SLAVE;
– RESET SLAVE ALL;（注意是 ALL，否则 master.info 不删）
– 检查 SELECT * FROM performance_schema.replication_connection_configuration; 是否为空
GTID 模式下还要确认 SELECT @@global.gtid_executed; 和目标一致性是否匹配，否则切过去可能丢事务。
