跨数据库迁移实战：用Kettle实现MySQL到PostgreSQL的高效数据同步
当你需要将业务系统从MySQL迁移到PostgreSQL时，最头疼的问题莫过于如何安全高效地转移海量数据。传统的手工导出导入不仅耗时费力，还容易出错。本文将带你用Kettle的ETL工具链，构建一个自动化、可复用的数据迁移流水线。
1. 环境准备与连接配置
在开始数据迁移前，我们需要确保两端数据库环境就绪。PostgreSQL建议安装与MySQL字符集兼容的扩展（如citext模块），避免后续出现大小写敏感问题。
数据库连接配置步骤：
- 启动Kettle后，右键点击"数据库连接"选择新建
- MySQL连接参数示例：
连接名称: src_mysql 主机名: 127.0.0.1 端口: 3306 数据库名: order_db 用户名: etl_user 密码: ****** - PostgreSQL连接需要特别注意SSL模式配置：
连接名称: dst_pg 主机名: pg.example.com 端口: 5432 数据库名: analytics 用户名: loader 密码: ****** SSL模式: require
提示：测试连接时若失败，检查防火墙规则是否放行了Kettle所在主机的IP地址
2. 构建基础迁移转换流
新建转换（ktr）文件后，从核心对象面板拖入以下组件构建基础流程：
表输入 -> 字段选择 -> 表输出表输入组件的关键配置：
- SQL查询建议使用完全限定列名，避免字段歧义：
SELECT orders.id AS order_id, customers.name AS customer_name, orders.total_amount FROM orders JOIN customers ON orders.customer_id = customers.id - 勾选"替换SQL语句里的变量"以便动态传参
- 记录数限制先设为1000进行测试迁移
字段映射的典型问题处理：
- MySQL的
datetime映射到PostgreSQL的timestamp tinyint(1)转为boolean类型- 文本字段注意编码转换（utf8mb4 -> utf8）
3. 高级优化技巧
当迁移数据量超过百万级时，需要采用分片策略提升性能：
批量提交优化参数：
| 参数项 | 测试值1 | 测试值2 | 生产推荐值 |
|---|---|---|---|
| 提交记录数 | 1000 | 5000 | 10000 |
| 批量插入大小 | 100 | 500 | 1000 |
| 并行线程数 | 2 | 4 | 8 |
在表输出组件中启用高级配置：
使用批量插入: 是 批量插入大小: 1000 压缩数据传输: 是性能对比测试结果：
- 单线程默认配置：12,000行/分钟
- 优化后多线程：85,000行/分钟
4. 异常处理与数据校验
迁移过程中最常见的三类问题及解决方案：
数据类型不兼容
- PostgreSQL的日期范围更严格，需预处理非法日期
- 使用
字段选择组件添加类型转换规则
字符集问题
- 在字段选择中添加
编码转换步骤 - 典型转换对：
latin1 -> utf8、gbk -> utf8
- 在字段选择中添加
外键约束冲突
- 迁移前禁用目标表约束
- 按依赖顺序迁移表（先主表后子表）
数据校验SQL示例：
-- 数量校验 SELECT (SELECT COUNT(*) FROM mysql.orders) AS src_count, (SELECT COUNT(*) FROM pg.orders) AS dst_count; -- 抽样校验 SELECT md5(array_agg(t::text)::text) AS hash_value FROM ( SELECT id, customer_id, amount FROM pg.orders ORDER BY random() LIMIT 10000 ) t;5. 自动化调度与监控
将转换保存后，可以通过作业（kjb）实现自动化：
- 创建每日增量迁移作业流：
开始 -> 检查依赖文件 -> 执行转换 -> 发送通知 -> 结束 - 配置增量查询条件：
WHERE update_time > ${LAST_RUN_TIME} - 添加错误处理分支：
- 失败时重试3次
- 最终失败发送告警邮件
在资源库中创建migration_log表记录每次运行情况：
CREATE TABLE migration_log ( job_name VARCHAR(100), start_time TIMESTAMP, end_time TIMESTAMP, rows_processed INT, status VARCHAR(20) );实战经验分享
在一次电商系统迁移中，我们发现订单表的JSON字段在PostgreSQL中解析失败。解决方案是在字段选择中添加JavaScript步骤进行预处理：
// 处理JSON字段转换 function cleanJson(input) { try { return JSON.stringify(JSON.parse(input)); } catch (e) { return null; } }另一个教训是关于大字段迁移——将LONGTEXT直接映射到TEXT导致性能骤降。后来改为分批提取大字段，吞吐量提升了8倍。
