转载自鹏说大数据
关键词: 大数据、数据调度、任务组、MySQL时区
整体说明
在项目上实际使用了 DolphinScheduler 一段时间后,我遇到了任务组功能因为 MySQL 时区的原因报错的问题。经过探索这个问题已经解决了,解决思路分享如下。
问题背景
- 设置任务组调度任务
任务组是把任务分组,每批任务可以拥有自己的资源量,可以更加灵活的调配资源。
- 任务组更新时间会随着任务运行更新
只要任务更新,任务运行,等等,都会使得任务组的更新时间更新,可以看到更新时间都是最新的,这个也就是触发原因。当然没有这个,也会触发,只是会晚一点
问题现象
- 任务调度执行报错
任务正常调度执行时,有大批量的错误,并且后台报错如下:
- 新增任务无法选择任务组
编辑任务时,无法选择具体的任务组,且会出现 “quey task group list error” 的报错信息字样
- 任务组无法查询部分数据
当我查询任务组时,前两页没问题,当要翻页到第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
2. 数据库服务设置
到底设置的是什么时区呢?先查询下 MySQL 数据库的时区,执行如下 SQL ,可得知,设置的时区和系统一致,使用的是 CST
show variables like '%time_zone%';
3. 程序连接数据库设置
那么程序设置的时区是什么呢?由程序设置可知,并没有特定指定使用什么时区。
4. CST导致问题根本原因
那这时候程序就会解析 数据库服务的时区,作为自己的时区
那么会解析成什么呢?
查询了 CST 的定义,才发现问题的根源
CST 是多个时区的缩写:
- 中国标准时间:UTC+8(无夏令时)
- 北美中部时间:UTC-6(有夏令时,如美国芝加哥)
- 澳大利亚中部时间:UTC+9:30(有夏令时)
如果 MySQL 的system_time_zone
设置为CST
,但应用或 JDBC 驱动将其错误解析为北美中部时间(而非中国标准时间),就会导致时间转换冲突。
5. 夏令时时间范围
那为什么,之前这个问题不出现,一直到 2025-03-09 这天才开始出现呢?
于是我查询了一下 夏令时 的时间范围,才恍然大悟
北美地区
- 美国(除亚利桑那州大部分地区、夏威夷等):
- 开始:3月第二个星期日凌晨2:00(时钟拨快1小时 → 3:00)。
- 结束:11月第一个星期日凌晨2:00(时钟拨回1小时 → 1:00)。
也就是 3月的 第二个星期日,才会出现这个问题,正好和我出问题的时间一致了,所以应该是应用系统,把 CST 解析成 北美中部时间 了,导致有夏令时
6.UTC 和 Asia/Shanghai 区别
现在明确是 时区 的问题了,那么我改修改成哪个时区呢?
我得到了两个推荐值 UTC 和 Asia/Shanghai ,于是查了资料,得到了如下对比结果
-
基本定义
-
时区偏移
-
夏令时(DST)
-
使用场景
从这个结果来看,使用 Asia/Shanghai 是最优的结果
7. 问题分析结论
由前面的分析可得,需要把 应用的 时区,修改为 Asia/Shanghai 即可
解决方案
前面分析得到结果,但是具体改怎么修改应用的时区呢?
1. MySQL服务端
第一种就是把 服务端的时区 CST 修改为 UTC,有多种方法,比如修改配置文件,还有就是 执行 SQL 如下:
SET GLOBAL time_zone = 'UTC';
当然这些都是在权限足够高的情况下。
2. JDBC连接
第二种就是修改 JDBC 连接。
在应用连接数据库的 JDBC 配置中增加如下配置:
&serverTimezone=Asia/Shanghai
效果如下:
3. 升级JDBC 版本
如果还没有解决,可以尝试升级JDBC版本,旧版本 MySQL Connector/J(如 5.x)可能未正确处理某些时区的夏令时规则,升级到 8.x 版本 可解决多数时区问题
最终解决
由于生产上修改数据库的配置,可能对其他应用造成影响,所以最终选择了 修改 JDBC 连接的方式,解决了这个问题。
经验总结
-
对时区设置理解不深。
很早之前我就知道serverTimezone=Asia/Shanghai
这个参数,但是对这个参数的作用,和带来的影响,并不太清楚,经过这次排查,彻底弄清楚了。 -
连接信息必须增加时区配置
对 Java 开发的同学,这个问题,尤为重要,虽然最初的原因是数据库的时区是 CST 导致了这一系列的问题,但是我们没法保证数据库的设置,每次都能设置正确,所以在做数据库参数配置的时候,最好是加上serverTimezone=Asia/Shanghai
这个配置,避免踩坑。
原文链接:https://blog.csdn.net/pengpenhhh/article/details/146187437