迁移 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 差异，都可能引发复制中断或数据偏差。
