缩短 MySQL 迁移停机时间的核心是通过增量同步+分阶段切换将停写窗口压至10–30秒：提前建立GTID/position主从复制、规避DDL与长事务、可选XtraBackup加速初始同步，并强化流程闭环与实测回滚。
缩短 MySQL 迁移停机时间，核心在于把“必须停写”的窗口压到最短，甚至趋近于零。关键不是追求一次性全量迁移，而是通过增量同步 + 切换控制，让业务感知不到或仅感知极短中断。
提前建立主从复制链路
在正式迁移前，将目标库（新实例）配置为源库（旧实例）的从库，开启基于 GTID 或 binlog position 的实时同步。这样迁移期间数据持续追平，避免全量导出导入阶段产生大量延迟。
- 确保源库开启 binlog_format=ROW 和 log_bin，且有稳定唯一的 server_id
- 目标库用 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或 CHANGE MASTER TO 指向源库，跳过已有数据冲突（如设置 replica_skip_errors 或提前过滤掉 DDL）
- 用 SHOW REPLICA STATUS 观察 Seconds_Behind_Source 是否稳定为 0
分阶段切换流量，而非一刀切停服
停机时间 = 最后一次增量同步 + 权限/连接切换 + 健康检查耗时。可将这个过程拆解为预热、冻结、校验、切换四步，其中只有“冻结”阶段需短暂停写（通常控制在 10–30 秒内）。
- 预热：应用连接池逐步指向新库（只读），验证查询逻辑和性能
- 冻结：关闭源库写权限（SET GLOBAL read_only = ON），停止写入；同时拉取并回放最后一段 binlog
- 校验：用 pt-table-checksum 或自定义脚本比对关键表行数与校验和，确认数据一致
- 切换：更新 DNS / 配置中心 / 连接串，重启应用连接池（或触发热重连），放开新库写权限
规避大表 DDL 和长事务干扰
迁移期间若源库执行 ALTER TABLE 或存在运行超 5 分钟的事务，会导致复制延迟飙升，直接拖长停机窗口。
- 提前识别并延期所有非紧急 DDL，大表变更用 pt-online-schema-change 或 gh-ost 在迁移前完成
- 监控 information_schema.INNODB_TRX，迁移前 kill 掉长时间未提交事务
- 避免在冻结窗口前后 5 分钟内发起批量导入、报表生成等重负载操作
使用物理备份加速初始同步（可选）
对于 TB 级数据库，逻辑导出（mysqldump）太慢。可用 Percona XtraBackup 对源库做热备，再恢复到目标库作为复制起点，大幅缩短首次同步时间。
- 备份时加 --slave-info，自动记录 binlog 位置，方便后续配置复制
- 恢复后启动 mysqld 时不启动 SQL 线程，先 CHANGE REPLICATION SOURCE TO 再 START REPLICA
- 注意版本兼容性：XtraBackup 8.0 只支持 MySQL 8.0，不兼容 5.7
真正影响停机长短的，往往不是技术多复杂，而是流程是否闭环、监控是否到位、回滚预案是否实测过。一次成功的迁移，90% 功夫在迁移前的准备和演练。
