跨服务器恢复的标准动作
把生产数据搬到新实例有一套固定顺序：核对目标版本、预置账号与关键参数、恢复备份、逐项校验数据，最后切换应用连接并在观察窗口内保留旧实例以便回退。跳过参数对齐与数据校验这两步，问题往往在上线后才以各种形式暴露出来。
执行步骤
- ① 目标实例版本不低于源库，跨大版本先查兼容性说明
- ② 预建账号与关键参数（字符集、时区、sql_mode、隔离级别）
- ③ 恢复备份，逻辑或物理方式按数据量与 RTO 选择
- ④ 校验数据：行数、校验和、关键业务抽样查询
- ⑤ 切应用连接并进入观察窗口，旧实例保留到确认稳定后再回收
逻辑迁移示例
逻辑迁移示例
# 源端导出：一致性快照 + 位点注释，便于后续起复制
mysqldump -uroot -p --single-transaction --source-data=2 --routines --events --all-databases > migrate.sql
# 目标端导入：字符集显式指定，避免乱码
mysql -uroot -p --default-character-set=utf8mb4 < migrate.sql
# 校验行数（示例）
mysql -N -e "SELECT COUNT(*) FROM appdb.orders" # 与源端同语句结果比对
mysql -N -e "SELECT CHECKSUM TABLE appdb.orders" > /tmp/tgt_checksum.txt # 校验和对比
# 抽样关键业务查询，确认数据可用
mysql -e "SELECT id, status FROM appdb.orders ORDER BY id DESC LIMIT 5"校验与回退检查点
| 检查项 | 手段 | 判据 |
|---|---|---|
| 版本兼容 | SELECT VERSION() | 目标版本不低于源库 |
| 字符集 | SHOW VARIABLES LIKE 'character_set%' | 与源库一致，避免乱码 |
| sql_mode | SELECT @@GLOBAL.sql_mode | 差异项已评估并记录 |
| 时区 | SELECT @@global.time_zone | 与业务预期一致 |
| 数据校验 | 行数与 CHECKSUM TABLE | 关键表一致或差异可解释 |
| 回退路径 | 保留旧实例与连接串 | 观察窗口内可快速切回 |
迁移窗口要覆盖「最后一次增量同步 + 校验 + 切流」三段耗时；大库建议先做全备预热，再用增量追平，避免切流时长时间停写。
切流后立刻销毁旧实例风险很高：观察窗口内一旦发现数据或性能问题，将失去快速回退的余地。
回退准备
- 保留旧实例并确认连接串可随时切回
- 记录变更前后的关键指标，作为是否需要回退的判据
- 回退流程至少演练一次，确认步骤与耗时符合预期