企业官网建设流程全解析

简介：针对DataX对接MySQL 8.x的读写插件资源包，面向大数据开发、数据同步及ETL工程师，解决官方DataX默认插件对MySQL 8驱动支持不足、需手动改造编译的痛点。包内包含可直接放入DataX plugins目录下的mysqlreader与mysqlwriter插件，其中JAR文件涵盖插件主体及其依赖库（含mysql-connector-java 8.0.25），JSON文件提供任务模板与资源配置样例，有助于快速理解Reader分片并行读取、Writer主键冲突检测与批量写入等核心机制。资源共36个文件，压缩包约19.23MB，整体结构清晰、部署便捷。已有1765人学习下载，适合需要为DataX扩展MySQL8同步能力、或希望深入学习插件配置方式与排错思路的开发者。 先说一个可能让不少人头大的场景：你高高兴兴把MySQL8装好，数据也导进去了，结果拿DataX做同步，Reader和Writer一通配置跑起来，直接报错“Access denied for user 'root'@'localhost' (using password: YES)”，或者“Public Key Retrieval is not allowed”，又或者“The server time zone value ... is unrecognized”。这几个错误我全都踩过，而且每次都发生在“MySQL8 + 老驱动 + 默认配置”的组合上。这篇文章就围绕DataX读写MySQL8的插件适配问题，把驱动替换、连接参数、核心配置和排坑心得一次讲清楚，适合正在用DataX同步MySQL8数据、或者刚把业务库升级到MySQL8没多久的同学们参考。

这类问题说白了不是DataX本身多难，而是MySQL8的默认认证方式和连接协议变了，老版本JDBC驱动和旧配置习惯跟不上，导致插件明明能用却连不上、写不进、同步乱。下面把整套适配流程拆开讲。

1. 为什么MySQL8会让DataX插件“失灵”

1.1 根因：认证插件从mysql_native_password换成caching_sha2_password

MySQL5.7以及更早的版本，默认认证插件是mysql_native_password，用户密码校验走的是老一套SHA1算法。MySQL8.0开始，默认认证插件换成了caching_sha2_password，服务端返回的认证报文结构、公钥交换方式都变了。老版本mysql-connector-java（5.1.x）完全不认识这种新报文，所以在建立连接的早期阶段就被服务端拒绝，表现就是明明密码没错，却报Access denied。

DataX发行包自带的mysql驱动普遍偏老，直接拿默认的mysqlreader和mysqlwriter去连MySQL8，大概率会撞上这堵墙。很多人第一反应是“密码写错了”，改了十遍也没用，其实是驱动和认证方式不匹配。

1.2 第二个坑：连接URL缺少关键参数

即使你把驱动换成8.x，如果jdbcUrl还是老写法，比如只写jdbc:mysql://127.0.0.1:3306/test?useUnicode=true&characterEncoding=utf8，同样可能报Public Key Retrieval is not allowed。

这是caching_sha2_password机制导致的：客户端第一次连接需要向服务端获取RSA公钥来加密密码传输，默认策略下客户端不允许自动获取公钥，必须在连接参数里显式放开。另外MySQL8服务端默认时区经常和运行环境不一致，不指定serverTimezone也可能报时区无法识别。

1.3 核心结论：插件本身没坏，是配套环境没跟上

DataX的mysqlreader和mysqlwriter插件骨架是通用的，真正干活的是底层JDBC驱动。MySQL8适配的关键并非开发一个新插件，而是做到三点：驱动替换、连接参数补齐、写入模式调整。理解了这一点，后面所有操作就都顺理成章了。

2. 环境准备：驱动替换与插件目录调整

2.1 检查当前插件目录结构

先找到DataX安装目录，正常情况下插件都在plugin目录下区分reader和writer：

datax/ ├── bin/ ├── lib/ └── plugin/ ├── reader/ │ ├── mysqlreader/ │ │ ├── libs/ │ │ ├── plugin.json │ │ └── mysqlreader-0.0.1-SNAPSHOT.jar └── writer/ ├── mysqlwriter/ │ ├── libs/ │ ├── plugin.json │ └── mysqlwriter-0.0.1-SNAPSHOT.jar

mysqlreader和mysqlwriter的libs目录下，各自带着一份老版本mysql驱动。因为DataX插件是隔离加载的，所以两边都要换，只换一边不行。

2.2 下载并替换MySQL8驱动

下载mysql-connector-java-8.0.x.jar，注意版本别太老，8.0.20以上更稳。下载好后分别复制到mysqlreader/libs和mysqlwriter/libs目录下，同时把原来的老驱动jar包删除或改名备份。

# 假设datax安装在/opt/datax cd /opt/datax/plugin/reader/mysqlreader/libs rm -f mysql-connector-java-5.1.*.jar cp /tmp/mysql-connector-java-8.0.28.jar . cd /opt/datax/plugin/writer/mysqlwriter/libs rm -f mysql-connector-java-5.1.*.jar cp /tmp/mysql-connector-java-8.0.28.jar .

这里有个容易忽略的点：驱动jar包文件名最好不要带8.0.28这种版本号以外的奇怪后缀，DataX插件加载有时候会扫描libs目录下的所有jar，命名规范点省得出幺蛾子。替换后建议先写一个最小同步任务验证驱动是否生效，别直接上全量数据。

2.3 单独做一套mysql8插件副本（可选但推荐）

如果你同时有MySQL5.7和MySQL8.0两套环境，一个DataX实例来回切换就很痛苦。因为mysqlreader内部连接的driverClassName并没有写死，但默认行为对老版本更友好，换完驱动后可能影响老库任务。

我实际用的做法是：复制mysqlreader目录为mysql8reader，mysqlwriter目录为mysql8writer，保留原mysqlreader/mysqlwriter给5.7用。复制后重点检查两个地方：

• plugin.json里的name要和目录名一致；
• 新副本中只保留MySQL8驱动jar包。

这样在job.json里就能用"name": "mysql8reader"和"name": "mysql8writer"显式区分，哪个任务用哪个插件一目了然，互不干扰。

3. 核心配置实战：两个关键JSON参数

3.1 一份能直接跑通的MySQL8读写模板

下面这个JSON模板是我在同步MySQL8实践后精简出来的，核心就是reader和writer两段配置：

{ "job": { "setting": { "speed": { "channel": 3 } }, "content": [ { "reader": { "name": "mysql8reader", "parameter": { "username": "root", "password": "your_password", "column": ["id", "name", "created_at"], "splitPk": "id", "connection": [ { "table": ["source_table"], "jdbcUrl": [ "jdbc:mysql://127.0.0.1:3306/source_db?useUnicode=true&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true" ] } ], "where": "created_at >= '2024-01-01 00:00:00'" } }, "writer": { "name": "mysql8writer", "parameter": { "username": "root", "password": "your_password", "column": ["id", "name", "created_at"], "writeMode": "insert", "batchSize": 1024, "connection": [ { "table": ["target_table"], "jdbcUrl": "jdbc:mysql://127.0.0.1:3306/target_db?useUnicode=true&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true" } ] } } } ] } }

这个模板的关键点在于jdbcUrl里的四个参数：useSSL=false避免SSL握手干扰，allowPublicKeyRetrieval=true解决认证公钥获取问题，serverTimezone=Asia/Shanghai统一时区，rewriteBatchedStatements=true让批量写入真正生效。

3.2 writer里的writeMode：insert、replace和update怎么选

DataX对接MySQL时，writeMode是一个高频热搜词，不同模式踩的坑不太一样。

• insert：最简单，直接走INSERT INTO，要求目标表不能有主键或唯一索引冲突，否则任务报错。
• replace：走REPLACE INTO，遇到主键或唯一键冲突时先删旧行再插新行。副作用是如果表里有自增主键，id会跳号，而且会触发额外的删除操作，对性能有影响。
• update：走INSERT ... ON DUPLICATE KEY UPDATE，需要DataX额外配置updateKey字段，否则官方插件不生效。适合只更新部分列的增量同步。

实际业务中，大部分场景用insert配合分区表或临时表最稳，等数据校验完再切表。如果一定要用update，务必先在测试表上跑一遍，确认更新列符合预期再上生产。

3.3 字段分隔符容易搞混的概念

“字段分割符是什么，如何改”这个问题经常和MySQL8同步一起被问到。其实DataX的MySQL插件本身没有字段分隔符概念，列与列的关系是通过column数组顺序一一映射的。字段分隔符是txtfilereader、csvfilereader这类文本插件才有的配置项，对应参数是fieldDelimiter。

如果你需要把MySQL8数据同步成文本文件再落到其他系统，用的是txtfilewriter：

"writer": { "name": "txtfilewriter", "parameter": { "path": "/data/export/", "fileName": "user_data", "writeMode": "truncate", "format": "yyyy-MM-dd HH:mm:ss", "fieldDelimiter": "\t", "column": [ {"name": "id", "type": "int"}, {"name": "name", "type": "string"} ] } }

想把默认分隔符从逗号改成竖线，直接改fieldDelimiter值就行。注意写\t或|这类特殊字符时需要按照JSON转义规则来。

4. 自研MySQL8插件的思路（当现成插件不够用的时候）

4.1 DataX插件的基本工作方式

DataX所有读写能力都抽象为插件，每个插件必须实现两段逻辑：Job阶段负责切分任务、生成通道，Task阶段负责真正读写数据。插件目录外的那个plugin.json就是插件的“身份证”，声明了插件名和类入口。

当你需要定制MySQL8读写行为，比如自动映射JSON字段、处理特殊类型、写入时加解密，这时候直接改现成插件源码比自己从零写要快得多。官方mysqlreader和mysqlwriter源码在GitHub上都能找到，结构很清晰，Reader侧重点在doInit和startRead，Writer侧重点在startWrite。

4.2 改造成自定义插件的实操路径

我的习惯做法是：拷贝官方mysqlreader源码，包名从com.alibaba.datax.plugin.reader.mysqlreader改成com.alibaba.datax.plugin.reader.mysql8reader，类名和plugin.json里的name同步修改，然后做三处定制：

• 将driverClassName固定为com.mysql.cj.jdbc.Driver；
• 在jdbcUrl拼装逻辑里强制补上serverTimezone和allowPublicKeyRetrieval；
• 在writer端把rewriteBatchedStatements=true默认加上，省得每个任务都手写。

然后用Maven打包，把生成的jar包放进新的插件目录：

mvn clean package -DskipTests cp target/mysql8reader-0.0.1-SNAPSHOT.jar /opt/datax/plugin/reader/mysql8reader/

这样做的最大好处是团队的同步任务配置可以很干净，不用每个任务都写一长串jdbcUrl参数，连接行为统一由插件内部控制，其他人使用门槛低很多。

4.3 成本提醒：别一上来就自研

自研插件听着很厉害，但如果只是驱动不兼容或参数缺失，优先通过替换驱动和补参数解决，半小时就能搞定。自研适合有多个任务、有固定团队、且需要对连接行为做统一治理的场景。一个人临时跑数据，真没必要为同步任务维护一套代码。

5. 常见问题与排查技巧实录

5.1 错误速查表

以下是我在实际操作中遇到最多的问题，整理成表方便对照：

5.2 排查步骤的先后顺序

遇到同步失败，别急着改密码，我的排查顺序是固定的：

1. 先看DataX日志里最底层的Caused by，DriverManager报的错才是根源；
2. 确认驱动版本，在插件libs目录下看mysql-connector-java的jar包版本号；
3. 确认jdbcUrl是否包含allowPublicKeyRetrieval和serverTimezone；
4. 用MySQL客户端工具测一下同一地址、同一用户名密码能否连通；
5. 如果客户端能连通而DataX不行，基本可以断定是驱动或参数问题；
6. 若都正常，再查目标表结构和writeMode是否匹配。

这套流程走下来，90%以上的MySQL8连接问题都能定位。

5.3 一个容易忽略的细节：任务并发数和数据库负载

很多人调完驱动后用一个简单查询测试，通了就开开心心上全量，结果跑到一半连接数打满，MySQL直接拒绝新连接。DataX的setting.speed.channel不是越大越好，MySQL8默认最大连接数一般151，一个DataX任务占几个连接，乘以任务数再预留业务连接，别一股脑全占了。我通常控制在2到4个channel，配合batchSize 1024，全量同步速度和数据库压力都能接受。

6. 关于批量写入和时区，再多说几句

6.1 rewriteBatchedStatements为什么重要

如果没有这个参数，JDBC驱动会把addBatch中的每条SQL单独发给数据库，批量成了“假批量”。加上后驱动才会真正拼成多VALUES语句一次发送。MySQL8对多VALUES的优化比老版本更明显，尤其是数据量大时，这个参数对写入速度影响相当大。

6.2 时区问题看似不起眼，影响却很大

MySQL8的timestamp存的是UTC时间，展示时依赖会话时区。如果DataX客户端时区和服务端不一致，写入后查出来可能差8小时。直接在jdbcUrl里固定serverTimezone=Asia/Shanghai，比在MySQL里改全局时区更省事，也不会影响其他应用。

最后的经验提醒

用DataX同步MySQL8，我踩过最深的坑就是“拿老经验套新版本”。很多报错一眼看上去是权限问题、网络问题，结果换驱动加参数之后立刻解决。所以如果你现在也被MySQL8的同步问题卡住，先做三件事：换驱动、补jdbcUrl参数、确认writeMode。这三步处理完，大概率问题已经解决一大半。剩下的，就是多看一眼日志最底层的异常，别被上面一堆堆栈吓住。

本文还有配套的精品资源，点击获取