背景某套业务系统当前使用 openGauss 数据库后续计划切换到 GreatSQL。本文示例是使用 DataX 将 openGauss 的一张业务表的数据同步到 GreatSQL 的过程主要包括 DataX 安装、JDBC 驱动准备、目标表结构转换、任务配置以及迁移结果校验。 实际的生产数据迁移时需要结合表数量、数据量、停机窗口、约束和索引重建策略完整评估迁移耗时。方案概述DataX 是阿里巴巴开源的异构数据源离线同步工具。它将数据同步过程抽象为 Reader、Framework 和 Writer 三部分Reader 从源端读取数据Framework 负责调度和传输Writer 将数据写入目标端。本次迁移链路如下openGauss - DataX Reader - DataX Framework - mysqlwriter - GreatSQLGreatSQL 完全兼容 MySQL 协议和 MySQL 语法因此目标端使用 DataX 的mysqlwriter插件写入。源端 openGauss 与 PostgreSQL 生态有较高兼容性但在 JDBC 驱动、数据类型和 SQL 语法上仍需要注意差异。DataX 概述什么是DataXDataX 是阿里巴巴开源的一个异构数据源离线同步工具致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。DataX的设计为了解决异构数据源同步问题DataX 将复杂的网状的同步链路变成了星型数据链路DataX 作为中间传输载体负责连接各种数据源。当需要接入一个新的数据源的时候只需要将此数据源对接到 DataX便能跟已有的数据源做到无缝数据同步。框架设计DataX安装DataX下载下载地址 https://github.com/alibaba/DataX 本次下载的datax_v202309版本前置要求本文示例环境使用 Linux 服务器运行 DataX 前需要准备JDK建议使用 JDK 1.8。PythonDataX 启动脚本依赖 PythonPython 2 或 Python 3 均可本文环境中 Python 2.7.5 和 Python 3.6.8 均已安装。网络连通性DataX 所在服务器需要能够访问 openGauss 和 GreatSQL 的数据库端口。数据库权限源端账号需要具备查询权限目标端账号需要具备写入权限如果使用preSql、postSql还需要相应的 DDL/DML 权限。检查 Java 和 Python 版本[rootlocalhost ~]# java -version java version 1.8.0_411 Java(TM) SE Runtime Environment (build 1.8.0_411-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.411-b09, mixed mode) [rootapsl ~]# python --version Python 2.7.5 [rootlocalhost ~]# python3 --version Python 3.6.8下载并解压 DataX本次下载的datax_v202309版本将datax.tar.gz上传到服务器后解压到/opt目录tar -zxvf datax.tar.gz -C /opt解压后DataX 主目录为/opt/datax。准备 openGauss JDBC 驱动下载官方 openGauss JDBC 驱动 并将 openGauss 驱动放入 postgresqlreader 目录wget https://opengauss.obs.cn-south-1.myhuaweicloud.com/3.0.0/x86/openGauss-3.0.0-JDBC.tar.gz tar -zxvf openGauss-3.0.0-JDBC.tar.gz cp openGauss-3.0.0-JDBC.jar plugin/reader/postgresqlreader/libs/运行 DataX 自检DataX 安装包自带job.json示例可以先用它验证 DataX 能否正常启动python /opt/datax/bin/datax.py /opt/datax/job/job.json 2026-05-21 14:35:49.173 [job-0] INFO JobContainer - 任务启动时刻 : 2026-05-21 14:35:39 任务结束时刻 : 2026-05-21 14:35:49 任务总计耗时 : 10s 任务平均流量 : 253.91KB/s 记录写入速度 : 10000rec/s 读出记录总数 : 100000 读写失败总数 : 0自检任务能正常运行说明 DataX基 础运行环境没有问题。后续还需要通过真实任务验证数据库连接、驱动加载和表结构映射是否正确。迁移前准备创建目标库、用户和表迁移前需要先在 GreatSQL 中创建数据库、用户和目标表。openGauss 的建表语句不能直接在 GreatSQL 中执行需要根据两端的数据类型、字符集、默认值、约束和索引进行转换。本文示例表为g_test_recordopenGauss 建表语句如下CREATE TABLE g_test_record ( pk_operate_record character(32) NOT NULL, operate_type nvarchar2(100) NOT NULL, host_media_count integer, pk_deploy_media character(32), pk_operator character(32), operate_time timestamp with time zone ) WITH (orientationrow, compressionno);GreatSQL 的建表语句CREATE TABLE g_test_record ( pk_operate_record char(32) NOT NULL, operate_type varchar(100) NOT NULL, host_media_count int DEFAULT NULL, pk_deploy_media char(32) DEFAULT NULL, pk_operator char(32) DEFAULT NULL, operate_time datetime DEFAULT NULL ) ENGINEInnoDB;常用字段类型转换关系如下openGauss字段类型GreatSQL字段类型charactercharnvarchar2varcharintegerintsmallintsmallintintinttexttextblobblobnumericdecimaltimestampdatetime、datetime(6)包含毫秒编写配置文件在/opt/datax/job/目录下创建任务配置文件例如og2mysql_g_test_record.json。下面配置以gaussdbreader为例。如果当前环境继续使用postgresqlreader只需要将 reader 的name改为postgresqlreader并确保 openGauss JDBC 驱动已经放到postgresqlreader/libs目录。[rootapsl datax]# more job/og2mysql_g_test_record.json { job: { content: [ { reader: { name: postgresqlreader, parameter: { username: dbps, password: *********, column: [*], where: , connection: [ { jdbcUrl: [ jdbc:opengauss://192.168.1.100:15000/demo ], table: [g_test_record] } ] } }, writer: { name: mysqlwriter, parameter: { username: root, password: **********, column: [*], writeMode: update, connection: [ { jdbcUrl: jdbc:mysql://192.168.1.100:8603/demo?useSSLfalseuseUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNull, table: [g_test_record] } ] } } } ], setting: { speed: { channel: 1 } } } }配置说明配置主要分为 reader 和 writerreader用于从 openGauss 读取数据writer 将读取的数据写入到 GreatSQLusername 是用户名、password 是密码jdbcUrl 是数据库连接信息table 是待迁移的表名column 是指表的字段本次迁移测试是在 GreatSQL 创建好表后立刻进行数据迁移使用的*更稳妥的做法是显式列出所有字段。如果源表或目标表后续发生字段顺序变化或者发生新增或者删除字段导致openGauss和GreatSQL表结构不一致会导致重新进行数据迁移时迁移任务失败。示例配置中 mysqlwriter 使用了 writeMode: “update”。该模式依赖目标表的主键或唯一索引触发 ON DUPLICATE KEY UPDATE。如果目标表没有主键或唯一索引重复执行任务可能插入重复数据。若表存在业务主键建议在目标表中补充主键约束。特别说明配置文件中postgresqlreader的驱动需要配置为openGauss执行数据迁移在 DataX 目录下执行任务python ./bin/datax.py job/og2mysql_g_test_record.json任务执行完成后关注输出中的记录数、失败数和错误日志。示例输出如下2026-05-21 16:03:26.788 [job-0] INFO JobContainer - [total cpu info] averageCpu | maxDeltaCpu | minDeltaCpu -1.00% | -1.00% | -1.00% [total gc info] NAME | totalGCCount | maxDeltaGCCount | minDeltaGCCount | totalGCTime | maxDeltaGCTime | minDeltaGCTime PS MarkSweep | 1 | 1 | 1 | 0.024s | 0.024s | 0.024s PS Scavenge | 1 | 1 | 1 | 0.015s | 0.015s | 0.015s 2026-05-21 16:03:26.788 [job-0] INFO JobContainer - PerfTrace not enable! 2026-05-21 16:03:26.789 [job-0] INFO StandAloneJobContainerCommunicator - Total 23 records, 2583 bytes | Speed 258B/s, 2 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 0.000s | All Task WaitReaderTime 0.000s | Percentage 100.00% 2026-05-21 16:03:26.790 [job-0] INFO JobContainer - 任务启动时刻 : 2026-05-21 16:03:15 任务结束时刻 : 2026-05-21 16:03:26 任务总计耗时 : 10s 任务平均流量 : 258B/s 记录写入速度 : 2rec/s 读出记录总数 : 23 #迁移23条数据 读写失败总数 : 0数据核对迁移完成后至少需要核对以下内容源端和目标端记录数是否一致。主键或唯一键对应的数据是否一致。字符串字段是否存在截断、乱码或空格差异。时间字段的时区和精度是否满足业务要求。数值字段是否存在精度变化。源端 openGauss 示例数据-[ RECORD 22 ]------------------------------------- pk_operate_record | 7dc11468b7734417abc6e1d0787e7a96 operate_type | install host_media_count | 1 pk_deploy_media | f8e443cbc4194bfab2a6a78b7ebe6063 pk_operator | 1390a49407784921868a1a55116c351a operate_time | 2025-05-16 10:19:57.12108 -[ RECORD 23 ]------------------------------------- pk_operate_record | 99911468b7734417abc6e1d0787e7a96 operate_type | install host_media_count | 1 pk_deploy_media | f8e443cbc4194bfab2a6a78b7ebe6063 pk_operator | 1390a49407784921868a1a55116c351a operate_time | 2025-05-16 10:19:5708目标端 GreatSQL示例数据*************************** 22. row *************************** pk_operate_record: 7dc11468b7734417abc6e1d0787e7a96 operate_type: install host_media_count: 1 pk_deploy_media: f8e443cbc4194bfab2a6a78b7ebe6063 pk_operator: 1390a49407784921868a1a55116c351a operate_time: 2025-05-16 10:19:57 *************************** 23. row *************************** pk_operate_record: 99911468b7734417abc6e1d0787e7a96 operate_type: install host_media_count: 1 pk_deploy_media: f8e443cbc4194bfab2a6a78b7ebe6063 pk_operator: 1390a49407784921868a1a55116c351a operate_time: 2025-05-16 10:19:57 23 rows in set (0.00 sec)示例中目标端已查询到 23 条数据与 DataX 任务日志中的读取记录数一致。需要特别注意的是源端第一条记录包含毫秒和时区信息写入 GreatSQL 的datetime字段后只保留到秒。毫秒精度没有在目标字段中保留可以和业务进行确认是否需要保留毫秒信息如果需要保留毫秒信息GreatSQL建表语句可以使用datetime(6)总结使用 DataX 可以完成 openGauss 到 GreatSQL 的离线数据迁移。迁移过程的关键点包括源端 Reader 插件需要正确加载 openGauss JDBC 驱动。GreatSQL 目标端可使用mysqlwriter写入。openGauss DDL 不能直接复用到 GreatSQL需要先完成数据类型、字符集、约束和索引转换。writeMode: update需要目标表存在主键或唯一索引否则重复执行可能产生重复数据。时间、字符集、数值精度等字段需要在迁移后重点核对。本文示例完成了单表 23 条数据的迁移验证DataX 日志显示失败记录数为 0目标端查询结果也能对应到源端数据。后续如果迁移多表或大表建议补充全量校验、抽样校验、失败重跑策略和迁移窗口评估。