必须提前建立主从复制链路并持续同步，冻结前完成校验与修复，10分钟窗口仅用于原子切换。核心是提前准备：开启binlog、配置复制、校验一致性、清理长事务，确保切换时数据已就绪，实际切换耗时≤45秒。

mysqldump 不行，单线程导入500G表在普通SSD上至少要3–5小时，远超10分钟窗口。必须绕过全量逻辑导入，用增量同步+极短冻结切换。

用主从复制打底，不是“迁移时才配”

现在就该把目标库设为源库的从库，而不是等到停机前再操作。否则10分钟里既要建复制链路、又要追500G数据，根本不可能。

• 源库确认已开启 log_bin 和 binlog_format=ROW，server_id 唯一
• 目标库执行 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或 CHANGE MASTER TO，指向源库并跳过已有数据冲突（如加 replica_skip_errors=DDL_EXISTING_TABLE）
• 启动复制后持续观察 Seconds_Behind_Source，必须稳定在 0 或 ≤5 秒才算可用
• 如果源库是 MySQL 5.7，目标库是 8.0，需提前验证 GTID 兼容性；不兼容就退回到基于 binlog position 的复制

冻结写入前，先做一次轻量级校验

别等切换完才发现主从不一致。在校验阶段就暴露问题，比停机后回滚代价小得多。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 用 pt-table-checksum 对该500G表做分块校验，只比对 checksum，不拉数据，几分钟内完成
• 若发现差异，立刻用 pt-table-sync 修复，不要手动 INSERT/DELETE
• 避免在冻结窗口前 10 分钟内执行 ALTER TABLE 或大事务——它们会卡住复制，导致 Seconds_Behind_Source 突增
• 检查 information_schema.INNODB_TRX，kill 掉运行超 60 秒的未提交事务

最后10分钟：冻结 → 同步尾日志 → 切换 → 解冻

这10分钟不是给你“导入数据”的，而是用来做原子切换的。所有数据早已在后台同步好了。

• 执行 SET GLOBAL read_only = ON 在源库上停写（注意：不是 FLUSH TABLES WITH READ LOCK，后者会阻塞复制线程）
• 查 SHOW REPLICATION SOURCE STATUS 记下当前 File 和 Position，然后在目标库上 SELECT MASTER_POS_WAIT('xxx', xxx) 等待追平
• 确认 Seconds_Behind_Source = 0 后，改应用连接串或 DNS，或触发 Keepalived VIP 漂移（如有）
• 目标库执行 SET GLOBAL read_only = OFF 开放写入
• 整个过程实际耗时通常 ≤45 秒；剩下时间留给健康检查和快速回滚预案验证

真正卡住进度的，从来不是工具能力，而是复制链路没提前建好、DDL 和长事务没清理干净、校验没跑在停机前。10分钟窗口不是极限挑战，而是对前期准备是否扎实的终检。