背景

某套业务系统当前使用 openGauss 数据库，后续计划切换到 GreatSQL。本文示例是使用 DataX 将 openGauss 的一张业务表的数据同步到 GreatSQL 的过程，主要包括 DataX 安装、JDBC 驱动准备、目标表结构转换、任务配置以及迁移结果校验。 实际的生产数据迁移时，需要结合表数量、数据量、停机窗口、约束和索引重建策略完整评估迁移耗时。

方案概述

DataX 是阿里巴巴开源的异构数据源离线同步工具。它将数据同步过程抽象为 Reader、Framework 和 Writer 三部分：Reader 从源端读取数据，Framework 负责调度和传输，Writer 将数据写入目标端。

本次迁移链路如下：

openGauss -> DataX Reader -> DataX Framework -> mysqlwriter -> GreatSQL

GreatSQL 完全兼容 MySQL 协议和 MySQL 语法，因此目标端使用 DataX 的 mysqlwriter 插件写入。源端 openGauss 与 PostgreSQL 生态有较高兼容性，但在 JDBC 驱动、数据类型和 SQL 语法上仍需要注意差异。

DataX 概述

什么是DataX

DataX 是阿里巴巴开源的一个异构数据源离线同步工具，致力于实现包括关系型数据库(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。
• Python：DataX 启动脚本依赖 Python，Python 2 或 Python 3 均可，本文环境中 Python 2.7.5 和 Python 3.6.8 均已安装。
• 网络连通性：DataX 所在服务器需要能够访问 openGauss 和 GreatSQL 的数据库端口。
• 数据库权限：源端账号需要具备查询权限，目标端账号需要具备写入权限；如果使用 preSql、postSql，还需要相应的 DDL/DML 权限。

检查 Java 和 Python 版本：

[root@localhost ~]# 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)

[root@apsl ~]# python --version
Python 2.7.5

[root@localhost ~]# 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_record

openGauss 建表语句如下：

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 (orientation=row, compression=no);

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
) ENGINE=InnoDB;

常用字段类型转换关系如下：

编写配置文件

在 /opt/datax/job/ 目录下创建任务配置文件，例如 og2mysql_g_test_record.json。

下面配置以 gaussdbreader 为例。如果当前环境继续使用 postgresqlreader，只需要将 reader 的 name 改为 postgresqlreader，并确保 openGauss JDBC 驱动已经放到 postgresqlreader/libs 目录。

[root@apsl 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?useSSL=false&useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull",
                                "table": ["g_test_record"]
                            }
                        ]
                    }
                }
            }
        ],
        "setting": {
            "speed": {
                "channel": 1
            }
        }
    }
}

配置说明：

配置主要分为 reader 和 writer，reader用于从 openGauss 读取数据，writer 将读取的数据写入到 GreatSQL，

username 是用户名、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.121+08
-[ 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:57+08

目标端 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，目标端查询结果也能对应到源端数据。后续如果迁移多表或大表，建议补充全量校验、抽样校验、失败重跑策略和迁移窗口评估。