MySQL数据库迁移方案怎么选？4种方案对比+大数据量迁移避坑实战

大家好我是数据库小学妹 上个月帮一个客户做服务器迁移数据库大概两百万条数据。当时觉得 mysqldump 一把梭就完事了。结果导出的 SQL 文件 1.2G导入新库跑了一整晚还没跑完。CPU 直接拉满业务方第二天一早就来催了。后来换了金仓 KES 的迁移工具同样的数据量几分钟就搞定了。当时还挺意外的。迁移过程中存储过程和触发器也一并带过去了没有额外处理。踩完这个坑之后我把主流的 MySQL 数据库迁移方案都研究了一遍。每种方案都有自己的适用场景也有各自的坑。选错了方案轻则浪费时间重则数据出问题。今天把 4 种方案的优劣和踩坑经验整理出来帮朋友们少走弯路。一、mysqldump基础但有天花板mysqldump 是 MySQL 自带的导出工具。把表结构和数据导出成 SQL 文件再到目标库执行导入。操作简单几乎零门槛大部分 DBA 学的第一个迁移工具就是它。# 导出单库mysqldump-uroot-p--databasesmydbmydb.sql# 导入mysql-uroot-pmydb.sql数据量在百万以下、停机窗口充裕的场景下mysqldump 足够用了。问题出在数据量大的时候。 数据量超过百万后导入速度断崖式下降。我那次两百万条数据导出 5 分钟就跑完了导入跑了一整晚。原因是 mysqldump 导出的 SQL 全是 INSERT 语句。一条一条往目标库写效率很低。数据量越大这个问题越明显。想优化的话导出时加--single-transaction保证一致性加--quick减少内存占用。数据量大的话可以用 mydumper/myloader 做并行导入速度能提升好几倍。KES 的迁移工具 KDTS底层采用 并行导出导入机制类似 mydumper比 mysqldump 快很多。二、物理文件迁移快但限制多直接把 MySQL 的 datadir 数据目录打包复制到新服务器。速度确实快但前提条件非常苛刻。同版本 MySQL、同操作系统、同存储引擎追求迁移速度的场景下可以用。但限制也很明显。源和目标的 MySQL 版本、操作系统、文件系统必须高度兼容。跨版本基本不能用InnoDB 数据文件格式可能不兼容。迁移期间必须停库业务要完全停下来。而且操作风险高复制过程中文件损坏就会丢数据。这个方案用得不多。除非是同机房换服务器或者开发环境克隆这种场景。三、主从复制不停机但只能同库利用 MySQL 自带的主从复制让新库作为从库同步数据。追平后再切换主从角色。# 目标库配置为从库CHANGE MASTER TOMASTER_HOST源库IP,MASTER_USERrepl,MASTER_PASSWORD密码,MASTER_AUTO_POSITION1;START SLAVE;SHOW SLAVE STATUS\G不允许长时间停机、数据量大、同版本迁移。满足这几个条件主从复制是个不错的选择。优势是不停机短板是只能同库同版本。 触发器和存储过程不会自动同步需要手动迁移。如果源库有大量触发器迁移后很容易漏掉。如果目标是国产数据库主从复制这条路就走不通了。这就引出了第四种方案。四、专业迁移工具跨库场景的解法前面三种方案各有短板。mysqldump 大数据量慢物理文件不能跨版本主从复制只能同版本同类型。实际项目里真正难的是这几类场景跨版本迁移MySQL 5.6 到 8.0SQL 语法有差异字段类型有变化跨库迁移MySQL 到国产数据库存储引擎和数据类型不兼容不停机迁移业务不能停但又要保证数据一致性混合场景既要跨版本又要不停机组合起来难度翻倍这种场景下金仓 KES 提供了一套完整的迁移工具链。覆盖了从全量迁移到实时增量同步的全流程。KDTS 负责全量迁移。底层用 mydumper 做并行导出导入比 mysqldump 快很多。我开头说的那个案例两百万数据跑了一整晚。换 KDTS 几分钟就搞定了。KES的完整方案是KDTS做全量KFS(Kingbase FlySync)做实时增量同步前后接力整个过程不需要停库业务不受影响。KFS 负责实时增量同步。直接读 MySQL 的 Binlog不做全表扫描不加锁对生产库几乎无影响。同步延迟稳定在秒级以内日均可处理 4.5TB 增量数据。还支持双轨并行方案迁移期间出了问题可以秒级回切到原库。之前我参与过一个百万级数据的迁移项目。用 KFS 做增量同步最终切换只用了十几分钟业务全程没断过。实际操作分两步。先用 KDTS 做全量迁移再启动 KFS 做增量同步追平差异。等两边数据一致了选个业务低峰期做最终切换。KES 对 MySQL 的兼容度比较高。存储过程、触发器、视图迁过去基本能直接运行。KES 还内置了兼容性评估工具KDMS。迁移前自动分析 SQL 语法和数据类型的兼容问题生成评估报告。哪些语句能直接跑、哪些需要改写报告里标得清清楚楚。提前发现问题比迁移到一半报错强多了。五、4种方案对比表对比维度mysqldump物理文件主从复制KES迁移工具数据量适用百万以下不限不限不限停机时间长长短短跨版本支持支持不支持不支持支持跨库支持不支持不支持不支持支持操作难度低中中低可视化数据一致性依赖停库依赖停库实时同步实时同步触发器/存储过程自动导出自动需手动自动迁移回退能力无无手动双轨秒级回切选方案没那么复杂。数据量小、停得起就用 mysqldump。不能停但同版本就用主从复制。涉及到跨版本或跨库KDTS 加 KFS 的组合能把复杂度兜住。六、选型决策框架问题1数据量多大 → 100万以下 → mysqldump 够用 → 100万以上 → 往下看 问题2能接受停机吗 → 能有4小时以上窗口 → mysqldump 优化版mydumper并行导入 → 不能 → 往下看 问题3源和目标版本/类型一样吗 → 一样 → 主从复制 → 不一样跨版本/跨库 → KES迁移工具KDTSKFS七、避坑清单迁移前这几点一定要确认都是我踩过的坑1. binlog 格式必须是 ROW。我第一次做主从复制源库 binlog 格式是 STATEMENT。同步直接报错改完重启才发现。白白浪费了两个小时。如果用 KFS 做增量同步同样要求 binlog 是 ROW 格式。迁移前先确认一下。2. 触发器不会自动跟过去。mysqldump 可以带触发器但主从复制不行。迁完不检查的话有些业务逻辑就断了。迁移完记得手动检查SELECTTRIGGER_SCHEMA,COUNT(*)FROMinformation_schema.TRIGGERSWHERETRIGGER_SCHEMANOTIN(sys,mysql,information_schema)GROUPBYTRIGGER_SCHEMA;3. 字符集要对齐。源库 utf8、目标库 utf8mb4看起来兼容。实际迁移时排序规则不同会导致索引失效。4. 先在测试环境跑一遍。别直接上生产。我有一次在生产库做 mysqldump锁表时间太长业务方打了三个电话。如果是跨库迁移到 KES建议先用兼容性评估工具跑一遍。提前发现 SQL 语法和数据类型的问题。5. 迁完一定要做数据校验。不能只看表数量一样就完事。行数、主键范围、随机抽样比对这三步至少做一步。我有一次迁移完觉得没问题。上线后才发现有个时间字段精度丢了。排查了半天最后发现是 DATETIME 和 TIMESTAMP 的默认行为不一样。MySQL 数据库迁移没有一种方案能搞定所有场景。选哪个要看数据量、停机窗口和迁移距离。不过有一点我可以确定。如果你的迁移目标是国产数据库KES 的工具链是比较完整的。KDTS 负责全量迁移KFS 负责实时增量同步还有双轨回切换保底。前期做好兼容性评估剩下的就是个体力活。说到底迁移这件事不怕工具不好用就怕选错方案。选对了方案半夜都能睡个好觉。朋友们还遇到过哪些迁移的坑欢迎在评论区分享 我是数据库小学妹咱们下篇见