大家好我是数据库小学妹 前段时间接了个MySQL迁移到国产数据库的项目。领导给了一周还补了一句“数据不能丢业务不能停。”我心凉了半截。光评估市面上的工具就花了两天最后还是踩了几个坑。好在上周项目终于做完了今天把之前踩过的坑整理出来希望能帮大家少走弯路少踩坑。在展开之前先帮不太熟悉的朋友理一下MySQL迁移工具简单说就是能把MySQL的表结构、数据、索引、存储过程这些对象从一个库搬到另一个库的专用软件。常见的有mysqldump、DataX、Navicat、KFSKingbase FlySync等选的时候主要看三样数据量多大、要不要增量同步、目标库是什么。一、MySQL迁移到底难在哪很多人以为数据迁移就是导出来、再导进去实际上没那么简单。字段类型不匹配导入直接报错。字符集没统一中文变成乱码。最要命的是大表迁移过程中有新数据写入源库和目标库的数据就对不上了。选MySQL迁移工具说白了就是选怎么扛住这些风险。二、5款工具挨个说说市面上工具不少我把反复用过和仔细对比过的5款挑出来逐个聊聊。先看总览。工具适用场景增量同步数据校验学习成本数据量上限跨库迁移mysqldump小库备份、同版本迁移不支持手动对比低中小50GB不支持DataX离线批量同步不支持需配Canal有内置校验中大支持Navicat临时迁移、小规模操作不支持无极低小10GB支持KDTSKFSKDC信创迁移、异构同步支持自动化校验KDC中大支持gh-ost在线DDL变更不适用有行数校验高—不支持2.1 mysqldump小库够用大库别碰MySQL自带的导出工具用法很简单mysqldump-h127.0.0.1-uroot-p--opt--default-character-setutf8 mydb/tmp/mydb.sql导出SQL文件再导入到目标库。5分钟上手不用装别的东西。如果用的是InnoDB引擎建议加--single-transaction参数它会在导出前开启一个一致性快照导出期间不锁表业务照常读写。不加的话导出过程中表会被锁住写入全部阻塞。这个参数很多人不知道但对线上库迁移来说是必须的。但我第一次用它迁一个30GB的库加了--single-transaction导出还是花了40分钟导入又花了一小时。它也不支持增量同步导出之后新产生的数据丢了就是丢了。总的来说库不大、允许停机、同版本MySQL之间迁移可以用它超出这个范围就别勉强了。2.2 DataX批量搬运能手但配置太累阿里开源的离线同步框架支持几十种数据源。从MySQL搬到MySQL行搬到HDFS、Hive也行。坑在哪每张表要单独写一个JSON任务配置结构大概是这样reader部分指定MySQL连接和查询SQLwriter部分指定目标库的写入方式insert/replace/upsert。{reader:{name:mysqlreader,parameter:{connection:[{jdbcUrl:[jdbc:mysql://127.0.0.1:3306/src],table:[user]}],username:root,password:***}},writer:{name:mysqlwriter,parameter:{connection:[{jdbcUrl:jdbc:mysql://127.0.0.1:3307/dst,table:[user]}],username:root,password:***,writeMode:replace}}}200多张表就要写200多个这样的配置文件光这项工作就花了一下午。而且它不支持增量要增量同步得自己搭Canal解析binlog运维成本翻倍。适合的场景是数据仓库之间的批量ETL或者一次性的大规模搬迁需要持续同步的信创迁移DataX搞不定。2.3 Navicat应急可以别当生产工具4步完成迁移连源库、连目标库、选表、开传。连SQL都不用写临时搬几张表或者给测试环境造数据的时候挺好用。同事用它迁过一个8GB的库传到一半报错字段类型映射出了问题没有断点续传只能重来。加上商业版要收费应急偶尔用用还行生产环境不太靠谱。2.4 KFS信创迁移场景下的首选信创迁移到金仓数据库通常不是单靠一个工具完成的而是三个工具配合KDTS负责全量迁移和结构转换KFS负责增量实时同步KDC负责数据校验。KFS全称是金仓异构数据同步软件Kingbase FlySync在方案里承担的是增量同步这一环。用下来有几个点印象比较深。全量迁移靠KDTS。它能自动识别并转换表结构、索引、视图、存储过程不用一个个手动改字段类型映射。之前做异构迁移最头疼的就是这块经常改到半夜。现在KDTS跑一遍结构迁移基本就到位了。增量同步是KFS的强项。基于binlog实时捕获同步延迟在毫秒级别。迁移过程中源库有新写入也能同步过去切业务的时候数据基本是实时一致的。之前那个项目领导要求业务不停机靠的就是KFS这个能力。数据校验是KDC的活。之前用mysqldump迁移全量导完我得自己写SQL一条条比对200多张表校验了一整天。配合KDC迁移完成后自动逐表比对源库和目标库的数据一致性有差异直接标出来。当时第一次跑校验还真发现了几张表的字段精度有偏差幸好在测试阶段就拦住了。还有个可视化监控界面迁移进度和数据流向一清二楚。哪张表同步延迟高了、哪条数据校验出差异了界面上直接标红。领导喜欢看这个我也省了不少解释的功夫。KFS还支持断点续传迁移过程中网络抖了一下恢复之后从断点继续不用从头来。之前团队评估过传统导出-转换-导入的方案预估要48小时。换成KDTS加KFS的方案之后全量加增量追平实际不到4个小时。2.5 gh-ost / pt-online-schema-change改表结构用的这俩不算迁移工具是在线DDL变更工具。但讨论MySQL迁移经常被提到顺带说一下。gh-ost是GitHub开源的思路和直接ALTER TABLE完全不同。直接ALTER是原地锁表修改期间完全不可写。gh-ost的做法是创建影子表分批拷贝数据用binlog实时追增量数据追平后原子RENAME TABLE切换全程原表可正常读写。之前有个项目8000万行的订单表要加字段直接ALTER跑了40分钟还锁表业务方电话打爆了。换gh-ost在线完成业务基本无感知。注意它只管改表结构不管搬数据跨库迁移帮不上忙。三、怎么选看三个点选工具看什么数据量多大、要不要增量同步、目标库是什么。库小、允许停机的mysqldump或者Navicat就够用。数据量大、一次性搬完的DataX批量能力强。要持续同步的信创迁移KFS比较对路。同实例内改表结构gh-ost。这里多说一句。如果你在做MySQL到国产数据库的迁移信创合规是硬要求那选工具就不能图省事了。兼容性、增量同步、数据校验三个都得过关。也有人选自己写脚本迁移前期能跑通但后面维护成本很高表结构一改脚本就挂排查问题也没有日志可看。工具方案的学习成本是一次性的脚本方案的维护成本是持续的。KES配合KDTS、KFS、KDC的组合在信创迁移场景里落地比较早案例也多。KES对MySQL的SQL语法兼容度比较高应用层基本不用改代码。KDTS负责全量迁移和结构自动转换KFS负责增量实时同步KDC负责数据一致性校验从迁移启动到业务切换全链路都能覆盖。在金融、政务、制造这些行业里落地案例挺多的。我们团队当时也是参考了几个同行的案例才下的决定。四、MySQL迁移工具实操中我踩过的4个坑只测全量不测增量。全量数据对上了就以为没问题了结果上线后发现增量同步漏了好几条记录。后来在测试阶段就模拟写入操作确认增量数据实时同步到目标库才放心。字符集没统一。源库utf8mb4目标库utf8用户昵称里的emoji全变成问号。现在我迁移前第一件事就是查两端字符集。大表一次性导出。50GB的表直接mysqldump内存爆了。后来按主键范围切片分批处理稳多了。漏了存储过程和触发器这个坑踩得最深。当时以为mysqldump默认什么都导结果上线后发现几个定时任务不跑了排查了半天才意识到触发器根本没迁过来。mysqldump得手动加-R参数才导存储过程和触发器DataX更干脆存储过程迁移直接不支持。库里有这些东西一定要单独处理迁移完再逐个验证。最后说两句MySQL迁移工具没有最好这一说看你的场景。小库应急mysqldump批量搬DataX信创场景KFS各有各的活法。动手之前先想清楚三个事数据量、停机窗口、目标库类型想明白了选工具就不太会出大问题。这里重点说下信创迁移场景。如果目标是KESKDTSKFSKDC这套组合有三个比较突出的能力全量自动转换KDTS将表结构、索引、存储过程自动迁移不用手动改字段映射实时同步KFS基于binlog毫秒级增量捕获迁移期间业务不用停自动校验KDC逐表比对一致性有差异直接标出来。在金融和政务项目里落地比较多我们团队当初也是看了同行案例才做的决定。你用过哪几款MySQL迁移工具遇到过什么坑欢迎评论区聊聊说不定你的经验能帮到其他人 我是数据库小学妹咱们下篇见