必看！Apache DolphinScheduler 任务组因 MySQL 时区报错全解析与避坑指南

转载自鹏说大数据

关键词： 大数据、数据调度、任务组、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 ，于是查了资料，得到了如下对比结果

1. 基本定义

2. 时区偏移

3. 夏令时（DST）

4. 使用场景

从这个结果来看，使用 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