文章目录
摘要： Apache DolphinScheduler系列8-任务组因MySQL时区报错及经验总结
关键词： 大数据、数据调度、任务组、MySQL时区
整体说明
在调研了 DolphinScheduler 之后，在项目上实际使用了一段时间，遇到了任务组功能因为MySQL时区的原因报错了，解决思路分享如下。
一、问题背景
-
设置任务组调度任务
任务组是把任务分组，每批任务可以拥有自己的资源量，可以更加灵活的调配资源
-
任务组更新时间会随着任务运行更新
只要任务更新，任务运行，等等，都会使得任务组的更新时间更新，可以看到更新时间都是最新的，这个也就是触发原因。当然没有这个，也会触发，只是会晚一点
二、问题现象
-
任务调度执行报错
任务正常调度执行时，有大批量的错误，并且后台报错如下：
-
新增任务无法选择任务组
编辑任务时，无法选择具体的任务组，且会出现 “quey task group list error” 的报错信息字样
-
任务组无法查询部分数据
当我查询任务组时，前两页没问题，当要翻页到第3页时，也会报前面同样的错误。
三、问题分析
3.1、时区配置问题
由前面的报错信息，分析得知，是获得时区问题，导致无法查询 update_time 的值
[ERROR] 2025-03-11 08:41:21.824 +0800 org.apache.dolphinscheduler.api.exceptions.ApiExceptionHandler:[52] - query task group list error
org.springframework.dao.TransientDataAccessResourceException: Error attempting to get column 'update_time' from result set. Cause: java.sql.SQLException: HOUR_OF_DAY: 2 -> 3
; HOUR_OF_DAY: 2 -> 3; nested exception is java.sql.SQLException: HOUR_OF_DAY: 2 -> 3
3.2、数据库服务设置
到底设置的是什么时区呢？先查询下 MySQL 数据库的时区，执行如下 SQL ，可得知，设置的时区和系统一致，使用的是 CST
show variables like '%time_zone%';
3.3、程序连接数据库设置
那么程序设置的时区是什么呢？由程序设置可知，并没有特定指定使用什么时区
3.4、CST导致问题根本原因
那这时候程序就会解析 数据库服务的时区，作为自己的时区
那么会解析成什么呢？
查询了 CST 的定义，才发现问题的根源
CST 是多个时区的缩写：
- 中国标准时间：
UTC+8（无夏令时） - 北美中部时间：
UTC-6（有夏令时，如美国芝加哥） - 澳大利亚中部时间：
UTC+9:30（有夏令时）
如果 MySQL 的 system_time_zone 设置为 CST，但 应用或 JDBC 驱动将其错误解析为北美中部时间（而非中国标准时间），就会导致时间转换冲突
3.5、夏令时时间范围
那为什么，之前这个问题不出现，一直到 2025-03-09 这天才开始出现呢？
于是我查询了一下 夏令时 的时间范围，才恍然大悟
北美地区
- 美国（除亚利桑那州大部分地区、夏威夷等）：
- 开始：3月第二个星期日凌晨2:00（时钟拨快1小时 → 3:00）。
- 结束：11月第一个星期日凌晨2:00（时钟拨回1小时 → 1:00）。
也就是 3月的 第二个星期日，才会出现这个问题，正好和我出问题的时间一致了，所以应该是应用系统，把 CST 解析成 北美中部时间 了，导致有夏令时
3.6、UTC 和 Asia/Shanghai 区别
现在明确是 时区 的问题了，那么我改修改成哪个时区呢？
我得到了两个推荐值 UTC 和 Asia/Shanghai ，于是查了资料，得到了如下对比结果
1. 基本定义
| 时区 | 描述 |
|---|---|
| UTC | 全球标准时间基准，无夏令时，与格林尼治标准时间（GMT）基本一致。 |
| Asia/Shanghai | 中国标准时间（CST），固定为 UTC+8，无夏令时（中国自1991年起废止）。 |
2. 时区偏移
| 时区 | 与UTC的固定偏移量 | 示例（北京时间） |
|---|---|---|
| UTC | UTC±0 | UTC时间 12:00 → 北京时间 20:00（UTC+8） |
| Asia/Shanghai | UTC+8 | 本地时间 20:00 → UTC时间 12:00 |
3. 夏令时（DST）
| 时区 | 夏令时规则 |
|---|---|
| UTC | 无夏令时，全年保持固定偏移（UTC±0）。 |
| Asia/Shanghai | 无夏令时（中国自1991年起取消夏令时制度，始终固定为UTC+8）。 |
4. 使用场景
| 场景 | 推荐时区 | 原因 |
|---|---|---|
| 数据库存储 | UTC | 避免时区转换歧义，全球统一时间基准。 |
| 前端展示 | Asia/Shanghai | 直接显示用户本地时间（中国用户无需额外计算）。 |
从这个结果来看，使用 Asia/Shanghai 是最优的结果
3.7、问题分析结论
由前面的分析可得，需要把 应用的 时区，修改为 Asia/Shanghai 即可
四、解决方案
前面分析得到结果，但是具体改怎么修改应用的时区呢？
4.1、MySQL服务端
第一种就是把 服务端的时区 CST 修改为 UTC，
有多种方法，比如修改配置文件，
还有就是 执行 SQL 如下：
SET GLOBAL time_zone = 'UTC';
当然这些都是在权限足够高的情况下。
4.2、JDBC连接
第二种就是修改 JDBC 连接
在应用连接数据库的 JDBC 配置中增加 如下配置
&serverTimezone=Asia/Shanghai
效果如下：
4.3、升级JDBC 版本
如果还没有解决，可以尝试升级JDBC版本，旧版本 MySQL Connector/J（如 5.x）可能未正确处理某些时区的夏令时规则，升级到 8.x 版本 可解决多数时区问题
五、最终解决
由于生产上修改数据库的配置，可能对其他应用造成影响，所以最终选择了 修改 JDBC 连接的方式，解决了这个问题
六、经验总结
-
对时区设置理解不深
很早之前我就知道 serverTimezone=Asia/Shanghai 这个参数，但是对这个参数的作用，和带来的影响，并不太清楚，经过这次排查，彻底弄清楚了
-
连接信息必须增加时区配置
对 Java 开发的同学，这个问题，尤为重要，虽然最初的原因是数据库的时区是 CST 导致了这一系列的问题，但是我们没法保证数据库的设置，每次都能设置正确，所以在做数据库参数配置的时候，最好是加上 serverTimezone=Asia/Shanghai 这个配置，避免踩坑
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
