MySQL数据迁移实战：不落地的在线迁移与校验回退方案

MySQL数据迁移的高危点在于迁移期间业务不能停、数据不能丢、切到新库后还能回退。本文给出不落地的在线迁移方案：先用主从复制追平增量，再在低峰期切换写流量，最后双写校验与回退预案，全程保留回退路径，适用于跨机迁移与跨版本升级。

MySQL在线迁移的三种路径

路径一，全量导出导入加增量同步，适合库表不大、停机窗口允许的场景；路径二，用主从复制追平，切换时短暂只读，业务基本不停；路径三，用DataX等工具做全量同步加binlog增量补，适用于异构迁移。在线业务首选路径二：从库持续应用binlog，延迟追平到秒级即可切换。

迁移前检查：版本、字符集与账号权限

迁移前先核对目标实例的版本差异、默认字符集、sql_mode、时区配置，避免复制过程中出现字符集乱码和字段类型转换问题。目标库账号要分配复制账号权限：REPLICATION SLAVE、REPLICATION CLIENT。

# 目标库建复制账号
CREATE USER 'repl'@'%' IDENTIFIED BY 'StrongPass@2026';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

# 源库开启binlog并确认row格式
SHOW VARIABLES LIKE 'log_bin';        -- ON
SHOW VARIABLES LIKE 'binlog_format';  -- ROW

全量导出与增量追平

用mysqldump导全量并记录位置，导入目标库后启动主从复制持续追增量。数据库较大时用XtraBackup物理备份恢复更快，追平速度取决于网络与从库配置。

# 全量导出（记录MASTER_LOG_POS）
mysqldump --single-transaction --master-data=2 \
  --databases appdb -u root -p > /backup/appdb.sql

# 目标库导入
mysql -u root -p < /backup/appdb.sql

# 启动主从复制（位置取mysqldump头部注释）
CHANGE MASTER TO
  MASTER_HOST='192.168.1.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='StrongPass@2026',
  MASTER_LOG_FILE='mysql-bin.000134',
  MASTER_LOG_POS=891234567;
START SLAVE;

追平期间持续观察 Seconds_Behind_Master，归零后再核对主从数据一致性。

切换写流量与回退预案

主从追平后，应用层先切读流量，观察无异常再切写流量。切换写流量时目标库要立即提升为主库（STOP SLAVE; RESET SLAVE ALL;），旧库只读保留。回退方案：在目标库上新开binlog，业务异常时反向复制回原库，保留历史数据安全。

# 目标库提升为主库
STOP SLAVE;
RESET SLAVE ALL;
# 此时目标库可写，应用写连接切换到目标库

# 如需回退：原库作为从库挂到目标库
CHANGE MASTER TO MASTER='192.168.1.20', ...;
START SLAVE;

迁移后的数据校验

切换后跑对比校验：每张表按主键分片统计SUM、COUNT、校验和，比对两库差异。大表用pt-table-checksum，它按行分块计算校验，差异记录进表，再人工核对。

pt-table-checksum \
  --host=192.168.1.10 --user=root --password=*** \
  --databases=appdb --tables=orders \
  --replicate-check-only --print-changes

校验通过后观察至少一个业务周期（1到2天），确认无误后下线旧库。回滚窗口内备份保留binlog，防止误操作需要恢复。