记一次 TiDB 时区设置异常问题排查
💡
原文中文，约8600字，阅读约需21分钟。
📝
内容提要
本文讨论了TiDB集群中时区设置异常的问题。两个配置相同的集群在执行SELECT NOW();时，结果却不同。经过排查，发现TiDB无法正确识别时区，导致回退至UTC。最终确认是因为/etc/localtime文件不是软链接，影响了时区设置。解决方法包括更新mysql.tidb中的system_tz值或设置time_zone变量。
🎯
关键要点
- 两个配置相同的TiDB集群在执行SELECT NOW();时结果不同，A集群时间正常，B集群时间少了8小时。
- 经过排查发现TiDB无法正确识别时区，导致回退至UTC。
- 问题源于/etc/localtime文件不是软链接，影响了时区设置。
- 可以通过更新mysql.tidb中的system_tz值或设置time_zone变量来解决问题。
- TiDB在启动时会从mysql.tidb加载system_tz值并设置系统时区。
- 日志记录了错误信息，帮助排查问题，强调了查看日志的重要性。
❓
延伸问答
TiDB集群中时区设置异常的主要原因是什么？
主要原因是/etc/localtime文件不是软链接，导致TiDB无法正确识别时区，回退至UTC。
如何解决TiDB时区设置异常的问题？
可以通过更新mysql.tidb中的system_tz值或设置time_zone变量来解决问题。
在排查TiDB时区问题时，日志的重要性体现在哪里？
日志记录了错误信息，帮助排查问题，强调了查看日志的重要性。
TiDB在启动时如何设置系统时区？
TiDB在启动时会从mysql.tidb加载system_tz值并设置系统时区。
为什么两个配置相同的TiDB集群会出现时区不同的情况？
因为在初始化过程中，/etc/localtime被替换为文件而非软链接，导致时区设置异常。
TiDB的system_tz和time_zone变量有什么关系？
system_tz用于存储系统时区信息，而time_zone变量在新建连接时依赖于system_tz的值。
➡️
