1. DataX-Web集群部署核心思路搞过分布式系统的朋友都知道集群部署最怕的就是单点故障。去年我们团队就遇到过调度中心宕机导致整个数据同步业务停摆的事故所以今天重点聊聊DataX-Web的集群化部署方案。不同于单机部署集群环境需要特别注意三个关键点首先是服务发现机制执行器需要自动注册到调度中心集群其次是负载均衡策略避免所有请求都打到同一个节点最后是状态同步问题确保集群内各节点的任务状态一致。DataX-Web通过MySQL共享存储动态注册机制实现了这三点具体怎么操作咱们往下看。先说说硬件准备。根据我的踩坑经验建议至少准备2台调度中心服务器4核8G起步3台执行器服务器根据任务量配置建议8核16G1台MySQL数据库主从架构更稳妥共享存储NFS或云存储用于存放日志和JSON配置文件2. 调度中心集群搭建实战2.1 基础环境配置所有节点都需要先装好JDK1.8、MySQL客户端和Python2.7兼容Python3需要改脚本后面会讲。这里有个容易翻车的点一定要确保所有机器的时间同步我推荐用chrony做时间同步曾经因为机器时间差3秒导致任务触发紊乱排查到怀疑人生。安装完基础环境后把datax-web-2.1.1.tar.gz上传到所有调度中心节点解压到相同路径比如/opt/datax-web。然后重点修改这几个文件vim /opt/datax-web/modules/datax-admin/conf/bootstrap.properties # 关键配置示例 DB_HOSTmysql-cluster-ip DB_PORT3306 DB_USERNAMEdatax DB_PASSWORDComplexPwd123 DB_DATABASEdatax_web_cluser2.2 数据库集群化改造单机版直接用的datax_web库集群环境建议新建datax_web_cluster库。执行SQL前要注意-- 创建专用数据库用户 CREATE USER datax% IDENTIFIED BY ComplexPwd123; GRANT ALL PRIVILEGES ON datax_web_cluster.* TO datax%; FLUSH PRIVILEGES; -- 执行初始化SQL mysql -h mysql-cluster-ip -u datax -p datax_web_cluster bin/db/datax-web.sql特别提醒如果要用到邮件告警功能记得在xxl_job_group表提前配置好执行器信息不然任务触发会报空指针异常。2.3 多节点启动与验证启动顺序有讲究建议先用第一台调度中心节点初始化数据库# 节点1首次启动要加初始化参数 ./bin/start.sh -m datax-admin --init # 其他节点正常启动 ./bin/start.sh -m datax-admin验证集群是否生效可以查数据库的xxl_job_registry表应该能看到多个server节点注册。更直观的方法是连续重启某个节点观察任务是否会自动转移到其他节点执行。3. 执行器集群配置技巧3.1 动态注册机制剖析执行器集群的核心在于appname配置所有相同appname的节点会被视为同一集群。修改配置时要注意# application.yml关键配置 datax: job: admin: addresses: http://调度中心1:8080,http://调度中心2:8080 executor: appname: datax-executor-cluster logpath: /mnt/nfs/datax/logs这里有个坑logpath必须指向共享存储否则不同节点执行的日志会分散在各机器上。曾经有客户反馈看不到完整日志结果发现是用了本地路径。3.2 路由策略选择DataX-Web内置了四种路由策略轮询默认适合任务均匀分布随机简单场景使用故障转移优先用健康节点忙碌转移根据CPU负载选择生产环境我推荐用忙碌转移策略配置方法是在任务模板的高级设置里选BUSYOVER。3.3 资源隔离方案当多个业务共用集群时建议通过分组实现资源隔离。具体操作在执行器管理页面新建分组不同业务使用不同的appname前缀创建任务时绑定对应分组我们金融客户就用这套方案实现了交易数据和日志数据的物理隔离。4. 高可用保障措施4.1 双活架构设计真正的高可用不能只靠软件配置硬件层面也要做冗余。推荐这种架构调度中心集群2节点SLB ↓ 执行器集群多AZ部署 ↓ 共享存储分布式文件系统 ↓ 数据库集群主从读写分离4.2 心跳检测优化默认30秒的心跳间隔对于金融场景可能太长可以通过JVM参数调整# 在datax-executor的启动脚本中加入 -Dxxl.job.executor.heartbeat.interval104.3 故障自愈方案分享几个实战中积累的应急方案脑裂处理当调度中心集群出现网络分区时应该立即停掉疑似故障节点任务堆积在executor的application.yml中配置executor.max.pool.size200数据库故障建议配置HikariCP连接池的存活检测参数5. 常见问题排查指南5.1 集群状态异常现象执行器时有时无 排查步骤检查数据库连接池是否耗尽查看执行器节点的网络连通性确认防火墙没拦截8080和9999端口5.2 任务不触发典型日志报错No executor available 解决方案检查xxl_job_registry表是否有存活执行器确认executor.appname没有拼写错误查看执行器节点的CPU负载是否过高5.3 性能调优经验根据压测结果给出几个关键参数建议executor.memory.mb不低于4096executor.jvm.options加上-XX:UseG1GCdatax.job.logretentiondays生产环境建议7天最后提醒大家升级集群版本时一定要先停掉所有任务我们吃过先升级调度中心后升级执行器的亏导致任务状态不一致需要人工干预。
ETL可视化工具 DataX -- DataX-Web集群部署与高可用配置 (四)
1. DataX-Web集群部署核心思路搞过分布式系统的朋友都知道集群部署最怕的就是单点故障。去年我们团队就遇到过调度中心宕机导致整个数据同步业务停摆的事故所以今天重点聊聊DataX-Web的集群化部署方案。不同于单机部署集群环境需要特别注意三个关键点首先是服务发现机制执行器需要自动注册到调度中心集群其次是负载均衡策略避免所有请求都打到同一个节点最后是状态同步问题确保集群内各节点的任务状态一致。DataX-Web通过MySQL共享存储动态注册机制实现了这三点具体怎么操作咱们往下看。先说说硬件准备。根据我的踩坑经验建议至少准备2台调度中心服务器4核8G起步3台执行器服务器根据任务量配置建议8核16G1台MySQL数据库主从架构更稳妥共享存储NFS或云存储用于存放日志和JSON配置文件2. 调度中心集群搭建实战2.1 基础环境配置所有节点都需要先装好JDK1.8、MySQL客户端和Python2.7兼容Python3需要改脚本后面会讲。这里有个容易翻车的点一定要确保所有机器的时间同步我推荐用chrony做时间同步曾经因为机器时间差3秒导致任务触发紊乱排查到怀疑人生。安装完基础环境后把datax-web-2.1.1.tar.gz上传到所有调度中心节点解压到相同路径比如/opt/datax-web。然后重点修改这几个文件vim /opt/datax-web/modules/datax-admin/conf/bootstrap.properties # 关键配置示例 DB_HOSTmysql-cluster-ip DB_PORT3306 DB_USERNAMEdatax DB_PASSWORDComplexPwd123 DB_DATABASEdatax_web_cluser2.2 数据库集群化改造单机版直接用的datax_web库集群环境建议新建datax_web_cluster库。执行SQL前要注意-- 创建专用数据库用户 CREATE USER datax% IDENTIFIED BY ComplexPwd123; GRANT ALL PRIVILEGES ON datax_web_cluster.* TO datax%; FLUSH PRIVILEGES; -- 执行初始化SQL mysql -h mysql-cluster-ip -u datax -p datax_web_cluster bin/db/datax-web.sql特别提醒如果要用到邮件告警功能记得在xxl_job_group表提前配置好执行器信息不然任务触发会报空指针异常。2.3 多节点启动与验证启动顺序有讲究建议先用第一台调度中心节点初始化数据库# 节点1首次启动要加初始化参数 ./bin/start.sh -m datax-admin --init # 其他节点正常启动 ./bin/start.sh -m datax-admin验证集群是否生效可以查数据库的xxl_job_registry表应该能看到多个server节点注册。更直观的方法是连续重启某个节点观察任务是否会自动转移到其他节点执行。3. 执行器集群配置技巧3.1 动态注册机制剖析执行器集群的核心在于appname配置所有相同appname的节点会被视为同一集群。修改配置时要注意# application.yml关键配置 datax: job: admin: addresses: http://调度中心1:8080,http://调度中心2:8080 executor: appname: datax-executor-cluster logpath: /mnt/nfs/datax/logs这里有个坑logpath必须指向共享存储否则不同节点执行的日志会分散在各机器上。曾经有客户反馈看不到完整日志结果发现是用了本地路径。3.2 路由策略选择DataX-Web内置了四种路由策略轮询默认适合任务均匀分布随机简单场景使用故障转移优先用健康节点忙碌转移根据CPU负载选择生产环境我推荐用忙碌转移策略配置方法是在任务模板的高级设置里选BUSYOVER。3.3 资源隔离方案当多个业务共用集群时建议通过分组实现资源隔离。具体操作在执行器管理页面新建分组不同业务使用不同的appname前缀创建任务时绑定对应分组我们金融客户就用这套方案实现了交易数据和日志数据的物理隔离。4. 高可用保障措施4.1 双活架构设计真正的高可用不能只靠软件配置硬件层面也要做冗余。推荐这种架构调度中心集群2节点SLB ↓ 执行器集群多AZ部署 ↓ 共享存储分布式文件系统 ↓ 数据库集群主从读写分离4.2 心跳检测优化默认30秒的心跳间隔对于金融场景可能太长可以通过JVM参数调整# 在datax-executor的启动脚本中加入 -Dxxl.job.executor.heartbeat.interval104.3 故障自愈方案分享几个实战中积累的应急方案脑裂处理当调度中心集群出现网络分区时应该立即停掉疑似故障节点任务堆积在executor的application.yml中配置executor.max.pool.size200数据库故障建议配置HikariCP连接池的存活检测参数5. 常见问题排查指南5.1 集群状态异常现象执行器时有时无 排查步骤检查数据库连接池是否耗尽查看执行器节点的网络连通性确认防火墙没拦截8080和9999端口5.2 任务不触发典型日志报错No executor available 解决方案检查xxl_job_registry表是否有存活执行器确认executor.appname没有拼写错误查看执行器节点的CPU负载是否过高5.3 性能调优经验根据压测结果给出几个关键参数建议executor.memory.mb不低于4096executor.jvm.options加上-XX:UseG1GCdatax.job.logretentiondays生产环境建议7天最后提醒大家升级集群版本时一定要先停掉所有任务我们吃过先升级调度中心后升级执行器的亏导致任务状态不一致需要人工干预。
