MongoDB迁移到KES实战全纪录（上）：迁移准备与实施指南

文章目录

为什么要从MongoDB迁移到KES？

最近接手了一个政务项目，客户明确要求数据库必须国产化。原来的系统用的是MongoDB，存了2TB多的电子证照数据，高峰期并发能到1000+。刚开始还挺头疼的，毕竟MongoDB的文档模型和关系型数据库差异不小，改代码、迁数据想想就头大。

后来接触到KingbaseES（简称KES），发现这货有点东西------居然能直接兼容MongoDB的协议！也就是说应用代码一行不用改，只改个连接地址就能跑。这就解决了最大的痛点，毕竟谁也不想重构几千行代码。而且KES还支持关系型+文档型数据一体化存储，以后新功能开发也不用维护两套数据库了。

迁移前的环境准备工作

硬件配置要求

KES对硬件要求不算苛刻，但要跑起来顺畅还是得有点家底：

CPU：至少4核，生产环境建议8核以上（我们用的是鲲鹏920，8核64G内存）
内存：开发测试环境4G起步，生产环境建议16G+（我们给数据库分了32G，毕竟要扛高并发）
磁盘：SSD是必须的！2TB数据迁移，机械硬盘怕是要跑到地老天荒。预留至少3倍数据量的空间，迁移过程中要存临时文件。

软件环境配置

操作系统我们选的是银河麒麟V10，毕竟政务项目要求国产化。安装过程很简单，图形化界面一路下一步就行。这里有个小坑：默认安装路径是C:\Program Files\Kingbase\ES\V9，建议改成纯英文无空格路径，比如D:\Kingbase\V9，避免后续权限问题。

数据库参数配置是重点，尤其是内存相关的：

sql 复制代码

-- 设置共享缓冲区，建议物理内存的50%
ALTER SYSTEM SET shared_buffers = '16GB';
-- 工作内存，每个连接的排序/哈希操作可用
ALTER SYSTEM SET work_mem = '64MB';
-- 最大连接数，比MongoDB的连接池配置大20%
ALTER SYSTEM SET max_connections = 1500;

改完参数要重启数据库生效，记得用sys_ctl restart -D /data/kingbase命令，别直接kill进程。

网络与安全配置

网络这块要保证源MongoDB和目标KES能互通，防火墙开放54321端口（KES默认端口）。安全方面KES比MongoDB强太多，我们启用了SSL加密传输，还配置了细粒度的权限控制：

sql 复制代码

-- 创建迁移专用用户
CREATE USER migrator WITH PASSWORD 'Encrypted@123';
-- 只给迁移必要的权限
GRANT CONNECT, CREATE ON DATABASE test TO migrator;

MongoDB那边也要创建一个只读用户，毕竟迁移过程中不能影响业务读写。

KDTS迁移工具深度体验

工具安装与初始化

金仓提供的KDTS（Kingbase Data Transfer Service）工具是个宝，支持全量+增量迁移。安装包不大，就100多MB，解压就能用。不过要注意JDK版本，官方推荐Oracle JDK 8，用OpenJDK可能会有驱动兼容性问题。

初始化配置文件是关键，kdts-plus/conf/application.yml里要指定源和目标数据库类型：

yaml 复制代码

spring:
  profiles:
    active: mongodb  # 源数据库类型
running-mode: DataMigration  # 数据迁移模式，还支持DataCompare模式

然后在datasource-mongodb.yml里配置MongoDB连接信息：

yaml 复制代码

source:
  dbType: mongodb
  url: mongodb://user:pass@192.168.1.100:27017/test
  username: migrator
  password: mongo_pass
target:
  dbType: kingbase
  url: jdbc:kingbase8://192.168.1.200:54321/test
  username: system
  password: kingbase_pass

数据映射规则配置

KDTS的自动映射功能挺智能，MongoDB的BSON类型会自动转换成KES的JSONB类型。不过还是要检查一下：

ObjectId → VARCHAR(32)，保留字符串形式
Date → TIMESTAMP，时区要统一设置为UTC+8
嵌套文档 → JSONB，完美保留结构

我们遇到一个特殊情况，MongoDB里有个字段存的是二进制文件（证照扫描件），KDTS会自动映射成BYTEA类型，迁移后能正常读取，这点很赞。

全量迁移实战

全量迁移我们选在周末业务低峰期进行。启动命令很简单：

bash 复制代码

./startup.sh --job=full_migrate --conf=./conf/application.yml

工具会先做预检查，提示索引数量、数据量等信息。2TB数据我们开了8个并行线程，实际迁移耗时4小时20分钟，比预期快不少（计划是6小时）。控制台会实时显示进度：

复制代码

[INFO] 迁移进度：75%，已迁移1500万条，速度：12000条/秒
[INFO] 当前表：ecertificates，预计剩余时间：45分钟

期间监控服务器资源，CPU利用率维持在70%左右，内存占用稳定，没有出现OOM。

增量同步配置

全量迁移完成后不能马上切换，因为MongoDB还在产生新数据。KDTS的增量同步基于MongoDB的Oplog，配置也很简单：

yaml 复制代码

increment:
  enable: true
  oplogStart: 1620000000  # 全量迁移开始的时间戳
  interval: 5000  # 每5秒拉取一次Oplog

启动增量同步后，工具会记录同步位点，即使中途重启也能续传。我们观察了24小时，增量延迟稳定在1秒以内，完全满足业务要求。

数据一致性校验步骤

迁移完数据不能直接撒手不管，必须验证一致性。KDTS自带了校验工具，支持三种方式：

记录数比对

最基础的校验，确保每个集合的文档数一致：

bash 复制代码

./kdts-verify --type=count --source=mongodb://... --target=jdbc:kingbase8://...

我们2TB数据有1.2亿条记录，校验耗时15分钟，所有集合的记录数完全匹配，第一步通过。

抽样内容校验

随机抽取10%的文档进行字段级比对，重点检查嵌套结构和数组：

bash 复制代码

./kdts-verify --type=content --sample=10% --source=... --target=...

这里发现个小问题：MongoDB的ObjectId在KES里被转换成字符串后，长度多了2个字符。后来发现是JSON序列化时加了引号，不影响使用，只是显示差异。

业务接口测试

最后是端到端测试，把应用连到KES跑一遍核心业务流程。我们用JMeter模拟了500并发用户，跑了30分钟，所有接口返回结果和MongoDB环境完全一致，响应时间还快了10%！

迁移中的坑与解决方案

数据类型转换问题

MongoDB的Decimal128类型迁移到KES时默认转成了NUMERIC，导致一些高精度计算结果有微小差异。解决方案是在映射配置里指定：

yaml 复制代码

type-mapping:
  Decimal128:
    target-type: DOUBLE

虽然损失了点精度，但业务能接受。如果要求严格，也可以用KES的NUMERIC(38,18)类型。

索引迁移注意事项

MongoDB的地理空间索引在KES里需要手动创建，KDTS不会自动转换。创建语句类似：

sql 复制代码

CREATE INDEX idx_location ON ecertificates USING GIST ( (metadata->'location') );

创建完索引后查询性能提升明显，原来MongoDB上要2秒的地理查询，KES只要300ms。

大文档处理技巧

有个集合存了证照扫描件的Base64字符串，单个文档超过10MB。迁移时老是超时，后来调整了KDTS的批处理大小：

yaml 复制代码

batch:
  size: 100  # 每批100条，默认是1000
  timeout: 300000  # 超时时间5分钟

问题解决，大文档也能顺利迁移。

迁移实施计划与回滚策略

迁移窗口选择

政务系统要求业务中断时间不超过4小时，我们选了周日凌晨0点到4点。实际操作下来，全量迁移+增量同步+切换验证总共用了3小时15分钟，留了45分钟缓冲时间，非常从容。

回滚预案

虽然信心满满，但回滚预案必须有：

迁移前对MongoDB做全量备份：mongodump -d ecert -o /backup/20250420
KES这边记录增量同步位点，万一出问题可以回退到初始状态
应用系统准备双数据源切换开关，5分钟内可切回MongoDB

整个迁移过程很顺利，没用到回滚。但预案这东西就像保险，宁可不用不可不备。

小结与后续计划

今天的介绍就到这里，我们已经完成了环境准备、数据迁移和一致性校验，下一步就是应用切换和性能优化了。整体感觉KES的迁移体验超出预期，尤其是协议级兼容这点太香了，省去了大量改代码的工作。

下一篇我们将会重点讲应用切换过程、性能压测结果，以及针对高并发场景的优化技巧。政务系统对性能要求可不低，1000+并发下要保证查询响应时间<500ms，这里面门道不少，敬请期待！