做数据同步这行的人多少都听过 DataX 这个名字。它是阿里开源出来的一套离线数据同步框架，主打在异构数据源之间做批量搬运——MySQL、Oracle、SQLServer、PostgreSQL、Hive、HDFS、MongoDB、达梦、人大金仓这些，基本覆盖了日常会遇到的数据源。但纯命令行的 DataX 用起来有个很现实的痛点：任务配置全是 JSON 文件，跑一次要在 Linux 终端敲一长串python datax.py xxx.json，任务多了以后文件散落一地，谁改了哪个配置、昨天那个任务跑成功没有，全靠人肉记忆。DataX-Web就是为了解决这个事出现的，它给 DataX 套了一层 Web 管理界面，把任务配置、定时调度、执行日志、失败重试这些统一管起来。
这篇内容我打算把linux 部署安装 DataX 和 DataX-Web这件事从头到尾讲透。不是那种复制官方文档的流水账，而是我自己在几台机器上反复装过、踩过坑之后整理出来的可复现路径。看完之后你应该能做到：在一台干净的 Linux 服务器上，半小时内把 DataX 跑通一个同步任务，再把 DataX-Web 的管理端和执行器都拉起来，最后在浏览器里点几下就能配出一个每天凌晨自动跑的增量同步任务。适合正在做数据仓库入湖、做报表系统数据准备、或者单纯需要把几个库的数据凑到一起的人参考。
1. 整体方案设计与选型思路拆解
1.1 DataX 和 DataX-Web 到底各管什么
先把两者的分工说清楚，不然后面部署的时候容易糊涂。DataX 本体是一个"执行引擎"，它的核心是一个 Java 写的进程，配上 Python 写的外层调用脚本。你给它一个 JSON 文件，它读里面的 reader 配置去源库拉数据，按 writer 配置写进目标库，中间在内存里走一个 channel 通道模型做流式搬运。它自己不知道什么叫"每天凌晨两点跑一次"，也不知道什么叫"失败了发个通知"——这些它一概不管。
DataX-Web 补的就是这一层。它本质上是一个 Spring Boot 后端加 Vue 前端的常规 Web 应用，拆成两个进程：一个是datax-admin，管的是页面、用户、数据源、任务模板、调度配置；另一个是datax-executor，管的是真正去调 DataX 命令、回收日志、上报执行结果。两者之间通过一个内部通信机制交换任务信息。所以你会看到它要连一个 MySQL 数据库——那是用来存元数据的，存任务定义、调度记录、执行日志摘要这些东西。
想明白这个分层，后面很多现象就顺了。比如你在页面上点"执行一次"，实际上是 admin 把任务信息丢给 executor，executor 在它自己的机器上生成一个 JSON 临时文件，然后 shell 调python datax.py，跑完之后把状态回写。如果 executor 那台机器上没装 DataX，或者 DataX 路径配错了，页面就会一直转圈然后报执行失败。
1.2 为什么这套组合几乎只在 Linux 上跑
DataX 官方给的运行环境要求里，操作系统那一栏写的就是 Linux。理论上 Windows 也能跑，但实际项目里没人这么干，原因有三个。
第一是路径和脚本的问题。DataX 的datax.py里大量用了/分隔的路径拼接，还有 shell 脚本做启动包装，在 Windows 上要么改脚本要么装 Cygwin，纯属给自己找麻烦。第二是调度习惯，DataX-Web 的调度依赖 cron 表达式，而 cron 本身就是 Unix 体系的东西，Linux 上跟系统的 crontab、日志轮转、进程守护结合得最自然。第三是资源和稳定性，数据同步这种活儿通常是长时任务，跑几个小时甚至十几个小时都正常，Linux 的内存管理和进程模型更适合这种场景，而且出问题的时候tail -f、ps -ef、jstack这一套排查手段最顺手。
1.3 单机部署还是拆开部署
DataX-Web 的 admin 和 executor 是可以分开部署在不同机器上的，这是它设计上比较灵活的一点。小规模场景我建议直接单机，admin 和 executor 装同一台，配置简单，出问题好查。当任务量上来以后——比如几十个任务同时调度，或者某些任务特别吃 CPU 和网络带宽——就可以把 executor 单独拆到几台机器上做水平扩展，admin 只保留一个。
判断标准其实很直白：看你的 executor 机器在执行高峰期top里的负载。如果 CPU 长期跑满、IO wait 很高，说明该拆了。另外一个信号是任务排队时间变长，明明调度时间到了但任务迟迟不开始执行，那就是 executor 忙不过来。
提示：第一次部署别想着一步到位搞集群，先把单机跑通，把任务 JSON 配置、增量抽取逻辑、异常处理都验证一遍，再去考虑扩展。很多坑在单机阶段暴露出来成本最低。
2. 环境准备与依赖梳理
2.1 JDK 版本选择与安装
DataX 和 DataX-Web 都是 Java 体系，JDK 是绕不过去的。版本上我的建议是统一用 JDK 1.8。DataX 3.0 编译目标就是 1.8，DataX-Web 2.x 系列也是基于 1.8 开发的。用 JDK 11 或 17 理论上有能跑通的案例，但你会遇到反射相关的模块访问警告，甚至某些老版本依赖直接报InaccessibleObjectException，排查起来不划算。
安装用包管理器最省事。CentOS 系：
yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-develUbuntu / Debian 系：
apt update apt install -y openjdk-8-jdk装完验证一下：
java -version javac -version两行都要能输出 1.8 才对。有个细节提醒：javac这一项容易被忽略。DataX 本身不需要编译，但 DataX-Web 需要你自己用 Maven 打包，打包过程中会编译代码，只有 JRE 没有 JDK 的话会在打包阶段报错。所以-devel或-jdk这个包一定要装上。
如果机器上已经装了别的 JDK 版本，用alternatives --config java或者手动设置JAVA_HOME来切换。我习惯在/etc/profile.d/java.sh里写死：
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk export PATH=$JAVA_HOME/bin:$PATH注意JAVA_HOME一定要指向 JDK 根目录，而不是bin目录。这个错误我见过太多次了，配错了以后 Maven 打包会报 "JAVA_HOME is not defined correctly"。
2.2 Python 环境这块要格外小心
DataX 的运行离不开 Python，这是它比较特别的地方。datax.py这个文件是 Python 脚本，负责解析参数、拼装 Java 命令、启动 JVM。官方推荐的版本是Python 2.7。原因很直接：datax.py里用的还是 Python 2 的语法，最典型的就是print "xxx"这种不带括号的写法。
那 Python 3 行不行？答案是能行，但要改脚本。改动量不大，主要是把datax.py和datax-executor相关的几个脚本里的 print 语句加上括号，另外注意字符串编码处理。如果你不想动脚本，最稳的办法是单独装一个 Python 2.7 到/usr/local/python2.7，然后在调用的时候显式用绝对路径。
python2.7 /opt/datax/bin/datax.py /opt/datax/job/mysql2mysql.jsonCentOS 7 自带 Python 2.7，直接用就行。CentOS 8 和比较新的 Ubuntu 已经不带 Python 2 了，需要自己编译或者找对应的包。这里有个取巧的思路：DataX-Web 的 executor 调 DataX 时，命令模板是可以配置的，你可以在配置文件里指定用python2.7还是python3，这样就避免了改系统默认 Python 带来的连锁反应。
注意：不要轻易把系统的
python软链接从 python2 改到 python3。Linux 上很多系统工具（yum 就是典型代表）依赖 python2，一改就可能把包管理器搞崩，到时候修起来很痛苦。用 which python 确认一下当前指向，心里有个数。
2.3 Maven 与 Git 的安装
DataX-Web 官方不直接提供编译好的二进制包，得自己从源码编译，所以 Maven 是必须的。版本上 3.6 以上就够了。
# CentOS yum install -y maven git # Ubuntu apt install -y maven git装完配置一下国内镜像，不然拉依赖会慢到怀疑人生。编辑~/.m2/settings.xml，在<mirrors>里加一个：
<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>aliyun maven</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>这一步省下来的时间是以小时计的。我第一次没配镜像，mvn package跑了四十分钟还没拉完依赖，换了镜像之后六分钟搞定。
2.4 元数据库准备与目录规划
DataX-Web 需要 MySQL 存元数据，版本 5.7 或 8.0 都行。建库的时候字符集直接选utf8mb4，排序规则utf8mb4_general_ci。库名我用的是datax_web，简单好记。
CREATE DATABASE datax_web DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER 'datax'@'%' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON datax_web.* TO 'datax'@'%'; FLUSH PRIVILEGES;目录规划这件事很多人不重视，后面运维起来会很乱。我习惯这样放：
| 用途 | 路径 | 说明 |
|---|---|---|
| DataX 本体 | /opt/datax | 解压后的目录 |
| DataX-Web 源码 | /opt/src/datax-web | 编译用 |
| DataX-Web 安装目录 | /opt/datax-web | 编译产物放这 |
| DataX 任务 JSON | /opt/datax/job | 手写测试任务的存放点 |
| 日志 | /data/logs/datax | 单独挂盘，避免写满系统盘 |
日志目录单独挂盘是我吃过亏之后养成的习惯。DataX 跑大批量任务的时候日志涨得飞快，一个跑几小时的任务日志能到几个 G，跟系统盘放一起很容易把根分区撑爆，然后整台机器上什么服务都写不了日志，问题会被放大好几倍。
另外建议专门建一个运行用户，不要用 root 跑：
useradd -m datax chown -R datax:datax /opt/datax /opt/datax-web /data/logs/datax用非 root 跑的好处是权限边界清晰，DataX-Web 的 executor 会以自己的身份去执行 shell 命令，用 root 万一脚本写错了破坏力太大。
3. DataX 单机部署全流程实操
3.1 下载解压与目录结构解读
DataX 的发布包是个 tar.gz，从官方仓库下载比较合适。放到/opt下解压：
cd /opt tar -zxvf datax.tar.gz mv datax datax-3.0.0 ln -s /opt/datax-3.0.0 /opt/datax用软链接是个小技巧，以后升级版本只要改软链接指向，配置文件里的路径不用动。解压完看一眼目录结构：
/opt/datax/ ├── bin/ # datax.py 和辅助脚本 ├── conf/ # core.json 等全局配置 ├── job/ # 任务 JSON 存放位置 ├── lib/ # 所有 jar 依赖 ├── plugin/ # reader / writer 插件 ├── script/ # 各插件的 Python 模板 └── log/ # 运行日志plugin目录是重点，进去看一眼reader和writer下面有哪些插件。默认包里通常包含 mysqlreader、txtfilereader、hdfsreader、oraclereader、streamreader 等，writer 侧对应 mysqlwriter、hdfswriter、txtfilewriter 等等。你要用的数据源如果不在里面，就需要单独找插件包放进去。
3.2 自检跑通第一个任务
DataX 自带一个自检功能，能验证核心 jar 和插件是否完整：
cd /opt/datax python bin/datax.py --jvm="-Xms1G -Xmx1G" bin/datax.py更常用的自检命令是直接跑官方的测试任务配置：
python bin/datax.py job/job.json如果看到控制台打印出任务统计信息，跳过多少条、读了多少条、耗时多少，就说明基础环境没问题了。
接下来配一个真实的 MySQL 到 MySQL 同步任务。新建/opt/datax/job/mysql2mysql.json：
{ "job": { "setting": { "speed": { "channel": 3 }, "errorLimit": { "record": 0, "percentage": 0.02 } }, "content": [ { "reader": { "name": "mysqlreader", "parameter": { "username": "readonly", "password": "xxxxxx", "column": ["id", "order_no", "amount", "create_time"], "splitPk": "id", "connection": [ { "table": ["t_order"], "jdbcUrl": ["jdbc:mysql://10.0.0.11:3306/biz_db?useUnicode=true&characterEncoding=utf8"] } ] } }, "writer": { "name": "mysqlwriter", "parameter": { "username": "writeuser", "password": "yyyyyy", "column": ["id", "order_no", "amount", "create_time"], "writeMode": "replace", "connection": [ { "jdbcUrl": "jdbc:mysql://10.0.0.12:3306/dw_db?useUnicode=true&characterEncoding=utf8", "table": ["t_order"] } ] } } } ] } }几个参数值得展开讲。channel是并发通道数，默认 1，代表单线程。设成 3 意味着 DataX 会起 3 个并发任务去拉数据，前提是splitPk配置了切分字段。这里用id做主键切分，DataX 会按 id 范围把数据切成若干片分给不同 channel。如果表没有合适的数值型主键，切分就退化成单通道，速度上不去。
writeMode有三个值：insert、replace、update。replace在 MySQL 里对应REPLACE INTO，主键冲突就覆盖；insert遇到冲突直接报错。做增量同步的时候replace更省心，不用自己处理重复数据。
errorLimit是脏数据容忍度。record: 0表示一条错误都不能有，有错就任务失败。生产环境我通常不设 0，而是根据数据量设置一个比例，比如percentage: 0.02允许 2% 的失败率，超过才中断。这样偶尔几条脏数据不会让整个任务白跑。
跑起来：
python bin/datax.py job/mysql2mysql.json3.3 插件与驱动的常见坑
第一类坑是驱动包缺失或版本不符。DataX 自带的 MySQL 驱动通常是较老的 5.1.x 版本，连 MySQL 8.0 的时候可能报Unknown system variable 'query_cache_size'或者 SSL 相关错误。解决办法是把新版本的mysql-connector-java-8.0.xx.jar丢到plugin/reader/mysqlreader/libs/和plugin/writer/mysqlwriter/libs/下面，同时把旧版本的 jar 删掉，避免类加载冲突。
第二类是时区问题。MySQL 8 默认可能用 UTC 时区，跑同步的时候create_time字段会莫名其妙差 8 小时。在 JDBC URL 里加上serverTimezone=Asia/Shanghai就能解决。
第三类是字段类型不匹配。源库的datetime往目标库的varchar写，或者bigint往int写溢出，DataX 会直接抛出类型转换异常。这种情况要么在 SQL 层面做转换（reader 支持配querySql自定义查询），要么把目标表结构改对。我倾向于改表结构，性能更好也更好维护。
第四类，如果数据源是 Oracle，还要额外注意字符集。Oracle reader 需要 characterEncoding 和 session 相关的设置，而且 Oracle 的驱动包通常需要手动放，因为版权原因不在默认包里。
实操心得：每次配新数据源，先用小表跑一个全量任务验证连通性和字段映射，确认无误了再放大到生产表。千万别拿一张千万级的表当第一个测试对象，一个字符集问题就能让你等上半小时才看到报错。
4. DataX-Web 部署与调度打通
4.1 源码编译与数据库初始化
从仓库拉源码，切到你需要的分支。执行编译：
cd /opt/src git clone https://gitee.com/xxx/datax-web.git cd datax-web mvn clean package -DskipTests-DskipTests一定要加，测试用例里有连数据库的部分，不跳过会有一堆失败。编译成功后在build目录下会看到产物。
接下来装数据库表结构。源码里通常带了bin/db/datax_web.sql，直接导入：
mysql -udatax -p datax_web < bin/db/datax_web.sql如果你的 MySQL 版本比较高，可能会遇到建表语句里datetime默认值语法不兼容的问题。检查一下sql_mode是不是包含了NO_ZERO_DATE，或者直接临时放宽：
SET GLOBAL sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';导完之后用show tables;看一眼，应该有二十来张表，job_info、job_log、datasource这些是后面会用到的核心表。
4.2 配置文件的关键修改点
DataX-Web 的配置集中在两个模块。先看 admin 侧，文件一般在datax-admin/src/main/resources/application.yml，需要改的地方有：
server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/datax_web?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai username: datax password: 你的密码再看 executor 侧，文件在datax-executor/src/main/resources/application.yml：
server: port: 8081 datax: job: admin: addresses: http://127.0.0.1:8080 executor: appname: datax-executor address: ip: port: 9999 logpath: /data/logs/datax-web/jobhandler logretentiondays: 30 executor: jsonpath: /opt/datax-web/executor/json pypath: /usr/bin/python2.7 datapath: /opt/datax这里的pypath和datapath是两个高频出错点。pypath要写 Python 解释器的绝对路径，datapath要指向 DataX 的安装目录。注意 executor 上面必须真的装了 DataX，因为它是通过 shell 调本地的datax.py来执行的。
logpath建议单独配到一个大容量目录，logretentiondays设成 30 天意味着自动清理一个月前的日志，不然磁盘很快就会满。
改完配置后重新打包，或者直接改编译产物里的配置也行。然后启动服务：
# 启动 admin cd /opt/datax-web/datax-admin/bin ./start.sh # 启动 executor cd /opt/datax-web/datax-executor/bin ./start.sh启动脚本的参数（堆内存大小之类）在bin/env.properties或者脚本头部可以调。默认堆可能偏小，任务多的时候会 OOM，我一般把 admin 调到-Xmx1g，executor 调到-Xmx2g。
验证启动成功：
tail -f /opt/datax-web/datax-admin/logs/datax-admin.log看到 "Started DataxAdminApplication" 之类的字样就对了。然后浏览器打开http://服务器IP:8080，默认账号密码通常是admin/123456，进去第一件事就是改密码。
4.3 页面配置数据源与任务
登录之后按这个顺序配。先是"数据源管理"，新增一个 MySQL 数据源，填 JDBC URL、用户名、密码，点测试连接。能连上再保存。注意这里的数据源是给"数据源查询"和"字段映射"用的，任务实际执行时用的连接信息仍然来自任务 JSON 里的配置。
然后是"任务管理"，新建任务，选择执行器，配置任务类型。如果是 DataX 类型，就要填 JSON 脚本。DataX-Web 提供了向导式配置，选源数据源、目标数据源、选表、做字段映射，它会帮你生成 JSON。但向导功能有限，复杂场景（比如自定义 querySql、多表 union）还是得手写 JSON 粘进去。
接着是"任务调度"，给任务绑定 cron 表达式。比如每天凌晨两点跑：
0 0 2 * * ?DataX-Web 用的是 Quartz 的 cron 语法，比 Linux 系统 cron 多一位（秒），这点要注意。0 0 2 * * ?表示每天 2:00:00 触发。
调度配好之后记得启调度器，在"调度中心"页面能看到调度器状态。如果显示离线，检查 executor 是不是真的连上了 admin。
4.4 增量同步的实现套路
全量同步在 DataX-Web 上直接配就行，但生产环境绝大多数任务需要增量。DataX-Web 原生没有现成的"增量"开关，得用几种变通方式。
第一种是querySql配合变量。DataX-Web 支持在任务里配置动态参数，把上次执行时间传进去。比如 reader 用：
"querySql": ["select id, order_no, amount, create_time from t_order where create_time > '${lastTime}' and create_time <= '${currentTime}'"]然后在任务的"动态参数"里配这两个变量，从调度记录里取上次执行时间。
第二种是自增 ID 水位线。目标端维护一张控制表，记录每个源表同步到的最大 id，每次跑之前先查水位线，同步完更新。这种方式最可靠，但对表结构有要求（必须有单调递增的主键）。
第三种适用于数据量不大的场景：直接全量覆盖。用writeMode: replace，每次全跑一遍，简单粗暴但绝对不出错。数据量在百万级以内、网络带宽够的时候，这种方式反而比维护增量逻辑省心。
提示：无论用哪种增量方式，都要在任务上加"失败重试"。DataX-Web 的重试配置在任务编辑页，可以设重试次数和间隔。源库偶发连接抖动是很常见的事，重试两次基本能覆盖。
5. 常见问题排查与避坑清单
5.1 启动阶段的典型问题
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| admin 启动报数据库连接失败 | 配置里的库名、账号、密码不对，或者 MySQL 没开远程访问 | 用mysql -h IP -u 账号 -p手动连一次验证 |
| 启动直接 OOM 退出 | 默认堆内存太小 | 调整启动脚本里的-Xms/-Xmx |
| 端口被占用 | 8080 被其他服务占了 | netstat -tlnp | grep 8080找到进程处理 |
| executor 注册不上 | admin 地址配错，或者 admin 没启动完 | 先看 admin 日志，再检查 executor 的 addresses 配置 |
端口占用这个事特别常见，因为 8080 是个万能端口。如果你机器上跑着 Tomcat、Jenkins 或者别的 Web 服务，换个端口就行，没必要去动别人的服务。
5.2 任务执行阶段的典型问题
任务跑不起来，或者跑起来马上失败，通常集中在几类。
第一类是"DataX 命令找不到"。executor 日志里会打印完整的执行命令，比如python /opt/datax/bin/datax.py -p xxx。把这条命令复制到终端手动跑一遍，报什么错立刻清楚。常见的是datapath配错导致路径拼出来是/opt/datax/datax/bin/datax.py，多了一层目录。
第二类是 Python 版本问题。报SyntaxError: invalid syntax并且指向print那一行，说明用 Python 3 跑了 Python 2 的脚本。改pypath指向 python2，或者去改脚本。
第三类是 JSON 解析失败。DataX-Web 存在数据库里的 JSON 可能被你用编辑器改过，多了个逗号或者引号没配对，执行时就报解析错误。我一般习惯先把 JSON 复制到本地用格式化工具校验一遍再粘回去。
第四类是内存不足。日志里出现java.lang.OutOfMemoryError: Java heap space，说明单次拉取的数据量太大。解决办法是把channel调大、批量大小调小，让数据流得更平缓；或者直接给 DataX 加堆内存。DataX 的启动参数可以在core.json里配，也可以在执行命令里用-jvm="-Xmx4g"指定。
第五类是日志文件暴涨。DataX 每跑一条记录都会写日志（可以调级别），大表跑完日志能到几个 G。解决办法是把 DataX 的日志级别从 info 调到 warn，在conf/logback.xml里改。这个改动对性能也有帮助，写日志本身是 IO 操作。
5.3 调度不生效的排查
调度配置好了但任务不跑，按这个顺序查：
先确认调度器状态是"在线"。调度中心页面会列出所有 executor 实例和它们的最后心跳时间。心跳断了说明网络或者配置有问题。
再确认任务的 cron 表达式合法。Quartz 的 cron 里不支持*/n之外的奇怪写法，0 0 2 * * *和0 0 2 * * ?都合法，但0 0 2 * * * ?多一位就非法了。
然后看任务是不是被禁用了。DataX-Web 的任务有几个状态：启用、停止、运行中。如果任务是停止状态，再正确的 cron 也不会触发。
最后看线程池。executor 的执行线程池是有上限的，默认可能只有十几到二十几个。如果同时有大量任务到点触发，超过线程池容量的任务会被排队或者直接丢弃。这种情况要么错开调度时间，要么扩大线程池配置。
实操心得：调度类问题最难查的原因是"没日志"。任务压根没触发的时候，是没有任何任务日志的。这时候要去 executor 的调度日志里找，那里会记录每次触发尝试和结果。养成看调度日志的习惯能省掉大量猜测。
6. 性能调优与生产化经验
6.1 并发参数不是越大越好
channel这个参数很多人喜欢往大了设，觉得并发高就快。实际上它有个平衡点。channel 太大带来的问题：源库压力陡增，可能把线上库拖慢；executor 机器的 CPU 和内存被吃光，影响其他任务；网络带宽打满，反而降低整体吞吐。
我的经验值是这样的：如果源库是线上生产库，channel 控制在 3-5 之间；如果是只读从库或者离线库，可以放到 8-16。同时要注意目标端的写入能力，MySQL 单表的写入并发是有限的，channel 开到 16 但目标端只有 4 个写线程，多出来的 channel 就是纯浪费。
另外splitPk的选取也很关键。理想情况是选一个分布均匀的数值型主键。如果主键是 UUID 这种字符串，DataX 没法切分，channel 设再大也是单通道。这种情况下可以找一个分布均匀的数值字段来做 splitPk，哪怕它不是主键。
6.2 批量提交与切分策略
MySQL writer 有一个batchSize参数（不同版本叫法可能不同），控制多少条记录提交一次。默认值偏小，适当调大能显著提升写入速度。我一般设到 1000 或 2000。但要注意：batchSize 太大加上事务提交，中途失败回滚的代价也大，需要权衡。
同理 reader 侧如果用的是 querySql，可以自己加 limit 分批，配合 DataX-Web 的多任务并发来实现更细粒度的控制。
6.3 日志治理和监控
生产上跑一段时间后，最先出问题的往往是磁盘。三件事必须做：DataX 的运行日志定期清理，DataX-Web 的任务执行日志按logretentiondays自动清理，MySQL 里的job_log表定期归档或者删除历史记录。job_log这张表涨得特别快，每个任务每次执行都会写若干条记录，几个月下来能到几百万行。写个定时 SQL 删掉 90 天前的数据，或者按分区表管理。
监控方面，最低限度要监控三个东西：executor 进程是否存活、调度器是否在线、最近一次任务是否有失败。前两个可以写个简单的 shell 脚本配 crontab 定时检查，第三个数据在 DataX-Web 的库里有，写 SQL 查job_log里最近 24 小时状态为失败的记录，有就直接告警。
6.4 关于任务 JSON 的版本管理
最后说一个容易被忽略但很要命的事情：任务 JSON 的版本管理。DataX-Web 存在数据库里的 JSON 是没法做 diff 的，你改了字段映射、改了 SQL 条件，改完就改了，想回滚只能凭记忆。我的做法是，所有任务的 JSON 在本地或者 Git 仓库里留一份副本，按任务名建目录，改之前先提交一次。看起来麻烦，但真出事的时候能救命。特别是那种从几十张表同步的复杂任务，靠人脑记住改过什么是不现实的。
我在实际运维这套组合的过程中，感觉最值钱的不是部署步骤本身——那个照文档走基本都能过——而是对"数据同步出错了怎么办"这套反射。比如说某天早上发现报表数据不对，第一反应应该是去 DataX-Web 上看对应任务昨天有没有跑、跑成功了没有、同步条数和平时比是不是少了一个量级。这三个信息一摆出来，问题范围立刻就缩小了。再往下才是查源库数据、查字段映射、查增量逻辑。这个排查路径清晰了，剩下的都是体力活。
