Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 集群版本升级后系统时区发生变化
【TiDB Usage Environment】Production Environment or Test Environment or POC
【TiDB Version】
After upgrading the cluster from 4.0.6 to 4.0.16, I checked the time zone and found it had changed to UTC.
mysql> select @@global.time_zone, @@session.time_zone;
±-------------------±--------------------+
| @@global.time_zone | @@session.time_zone |
±-------------------±--------------------+
| UTC | UTC |
±-------------------±--------------------+
1 row in set (0.00 sec)
Why is this happening?
【Encountered Problem】
【Reproduction Path】What operations were performed that caused the issue
【Problem Phenomenon and Impact】
【Attachments】
Please provide the version information of each component, such as cdc/tikv, which can be obtained by executing cdc version/tikv-server --version.
Setting the global time zone variable can fix the issue, but I don’t know why it automatically changes to UTC after the cluster version is upgraded.
Check the system configuration: /etc/localtime and see what this symlink is pointing to.
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 33 Jul 22 2019 /etc/localtime → /usr/share/zoneinfo/Asia/Shanghai
Previously, we encountered this issue with MySQL, and later we had the developers enforce timezone settings on the JDBC connection.
As cs58_dba mentioned, it is related to the server’s local TZ;
“TiDB evaluates the system’s timezone name via the TZ
environment variable and the path of the soft link of /etc/localtime
. If both of them fail, TiDB
then pushes UTC
to TiKV
.” from → tidb/docs/design/2018-09-10-adding-tz-env.md at master · pingcap/tidb · GitHub
However, I haven’t modified my TZ.
I don’t quite understand the point of contention. Following these steps should help identify where the problem lies.
This topic was automatically closed 1 minute after the last reply. No new replies are allowed.