MySQL主从迁移需分四阶段：一评估现状（版本、复制方式、延迟等）；二部署新环境并同步数据；三无感切换（锁表、切流量、启复制）；四验证一致性与稳定性。
迁移 MySQL 主从架构不是简单地搬数据，核心是保障复制链路不断、数据一致、服务不中断。关键在于分阶段操作：先评估现状，再搭建新环境，接着平滑切换，最后验证收尾。
一、迁移前必须摸清当前主从状态
不清楚现有架构细节，迁移极易出错。重点确认以下几点：
- 主库和从库的 MySQL 版本（如 5.7 → 8.0 需注意兼容性与认证插件变更）
- 复制方式（基于 binlog 的传统异步复制？GTID？半同步？MGR？）
- 主从延迟情况（执行
SHOW SLAVE STATUS\G查看 Seconds_Behind_Master 和 SQL_Delay） - 是否存在过滤规则（
replicate-do-db、binlog-do-db等） - 主库是否开启
log_bin、server_id是否唯一、从库是否启用了read_only=ON
二、新环境部署与数据同步准备
推荐使用物理备份 + binlog 追平方式，兼顾速度与一致性：
- 在主库上用
mysqldump --single-transaction --master-data=2或Percona XtraBackup做一致性快照 - 将备份恢复到新主库，并确保
server_id不同、gtid_mode与原环境一致（若启用 GTID，需同时设置enforce_gtid_consistency=ON） - 新从库可先指向旧主同步，或直接从新主拉取（取决于切换策略）
- 若跨版本迁移（如 5.7→8.0），务必提前在测试环境验证 SQL 兼容性、字符集、密码认证插件（caching_sha2_password vs mysql_native_password）
三、业务无感切换的关键步骤
避免停机，需控制写入、等待同步、原子切换：
- 在旧主库执行
FLUSH TABLES WITH READ LOCK，记录当前 binlog 位置（SHOW MASTER STATUS） - 暂停应用写入（可通过中间件/配置中心下线写流量，或临时修改 DNS/负载均衡指向只读）
- 等所有从库
Seconds_Behind_Master = 0后，停止旧从库的复制：STOP SLAVE - 将新主库的
CHANGE MASTER TO指向旧主最后位置（或通过 GTID 自动定位），启动复制：START SLAVE - 确认新主从同步正常后，把应用写请求切到新主库，再逐步放开读流量
四、迁移后必须验证的事项
切完不等于成功，要快速验证稳定性与数据正确性：
- 检查新主库的
SHOW PROCESSLIST中是否有大量写入阻塞 - 对比新旧主库的表行数（
SELECT COUNT(*)抽样关键表）、校验 checksum（如pt-table-checksum） - 监控新主从的
Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running状态 - 观察慢查询日志、连接数、QPS 是否异常，确认性能未劣化
- 保留旧主库至少 48 小时只读运行，作为回滚兜底；确认无误后再下线
不复杂但容易忽略细节，尤其 GTID 模式下 RESET MASTER 和 SET GTID_PURGED 的配合、跨版本权限表初始化、时区与 SQL mode 差异，都可能引发复制中断或数据偏差。
