前6天我们搭建好了OceanBase集群、创建了租户、设计了分区表现在终于到了最关键的一步——把现有的MySQL业务数据迁移过来。很多团队对迁移心存顾虑怕停机时间长、怕数据不一致。今天我们就来演示两种最实用的迁移方案从最简单的mysqldump到专业的DataX帮你找到最适合自己业务的方式。方案一mysqldump适合中小数据量10GB以下这是最简单粗暴的方式原理就是把MySQL的数据导出成标准SQL文件再用obclient导入OceanBase。因为OceanBase高度兼容MySQL语法绝大多数情况下无需修改SQL文件。# 第一步从MySQL导出数据带一致性事务快照 mysqldump -h 192.168.1.1 -uroot -p --single-transaction \ --set-gtid-purgedOFF --default-character-setutf8mb4 \ --databases myapp_db myapp_db.sql # 第二步处理可能的字符集兼容问题MySQL 8.0常见 sed -i s/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g myapp_db.sql # 第三步导入OceanBase obclient -h 127.0.0.1 -P 2881 -urootmy_tenant -D myapp_db -A myapp_db.sql⚠️ 避坑提醒导入前建议在OceanBase中先执行SET FOREIGN_KEY_CHECKS 0;禁用外键检查可以大幅提升导入速度。导入完成后再执行SET FOREIGN_KEY_CHECKS 1;恢复。方案二DataX适合大数据量支持增量同步当数据量达到几十GB甚至TB级别时mysqldump就不够用了。这时推荐使用阿里巴巴开源的DataX它支持断点续传、并发读写并且可以配置增量同步任务。首先下载并解压DataXwget https://datax-opensource.oss-cn-hangzhou.aliyuncs.com/202308/datax.tar.gz tar -xvzf datax.tar.gz然后编写一个迁移任务配置文件mysql2ob.json{ job: { setting: { speed: { channel: 4 }, errorLimit: { record: 0, percentage: 0.1 } }, content: [ { reader: { name: mysqlreader, parameter: { username: root, password: your_mysql_password, connection: [ { table: [orders, users], jdbcUrl: [jdbc:mysql://192.168.1.1:3306/myapp_db] } ] } }, writer: { name: oceanbasev10writer, parameter: { obWriteMode: insert, column: [*], connection: [ { jdbcUrl: jdbc:oceanbase://127.0.0.1:2881/myapp_db, table: [orders, users] } ], username: rootmy_tenant, password: your_ob_password, writerThreadCount: 10 } } } ] } }执行迁移任务python datax/bin/datax.py mysql2ob.json 生产迁移最佳实践无论选择哪种方案正式迁移前请务必做好以下准备评估数据量先在小表上测试迁移速度估算全量迁移所需时间窗口。备份源库迁移前对MySQL做一次完整备份确保有回滚方案。类型兼容性检查重点关注ENUM、SET、JSON等特殊类型在OceanBase中的映射关系。增量追平如果停机窗口有限可以先用DataX做一次全量迁移然后在切换前再跑一次增量同步追平差异数据。今日小结今天我们掌握了两种从MySQL迁移到OceanBase的实战方案。mysqldump简单直接适合中小数据量快速验证DataX功能强大适合生产环境的大数据量迁移。迁移并没有想象中那么可怕OceanBase的MySQL兼容性让这个过程变得非常平滑。 课后思考迁移完成后业务SQL真的可以零修改直接运行吗如果原来的MySQL里用了一些OceanBase不支持的语法比如某些存储过程或触发器我们该怎么排查和改造欢迎在评论区分享你的迁移踩坑经历