This is a community that may be useful to you
One-to-one communication/interview brochure/resume optimization/job search questions, welcome to join the “Yudao Rapid Development Platform” Knowledge Planet. The following is some information provided by Planet:
“Project Practice (Video)”: Learn from books, “practice” from past events
“Internet High Frequency Interview Questions”: Studying with your resume, spring blossoms
“Architecture x System Design”: Overcoming difficulties and mastering high-frequency interview scenario questions
“Advancing Java Learning Guide”: systematic learning, the mainstream technology stack of the Internet
“Must-read Java Source Code Column”: Know what it is and why it is so
This is an open source project that may be useful to you
Domestic Star is a 100,000+ open source project. The front-end includes management backend + WeChat applet, and the back-end supports monomer and microservice architecture.
Functions cover RBAC permissions, SaaS multi-tenancy, data permissions, mall, payment, workflow, large-screen reports, WeChat public account, etc.:
Boot address: https://gitee.com/zhijiantianya/ruoyi-vue-pro
Cloud address: https://gitee.com/zhijiantianya/yudao-cloud
Video tutorial: https://doc.iocoder.cn
Source: juejin.cn/post/
7221740907232657468
-
Start troubleshooting
-
Troubleshoot the database
-
CST time
-
Analyze again
-
-
solution
-
Solution 1: Modify database time zone
-
Here I choose option 2: Modify database connection parameters
-
-
Troubleshooting Linux
-
Troubleshooting Docker
Recently a new project was launched. When it was launched, I suddenly found that the time did not match the normal time, eight hours were missing. But I did not panic at all. Isn’t this just a time zone problem? It’s simple, but this time it gave me I’ve learned a lesson deeply, let’s take a look at the entire investigation process.
Start troubleshooting
Troubleshooting database
Generally, time zone problems are related to database configuration or data link parameter configuration problems, so I immediately located the problem. It should be that the database time zone setting was wrong, so I happily checked the database time zone.
?
Command: show variables like ‘%time_zone%’;
?
1. system_time_zone: global parameter, system time zone. When MySQL starts, it will check the time zone of the current system and set the value of the global parameter system_time_zone according to the system time zone. The value is CST, which is consistent with the time zone of the system time.
2. time_zone: global parameter, set the time zone of each connection session, the default is SYSTEM, use the value of the global parameter system_time_zone.
CST time
CST time: Central Standard Time. CST can represent 4 different time zones as follows:
-
Central Standard Time (USA) UT-6:00, United States
-
Central Standard Time (Australia) UT + 9:30, Australia
-
China Standard Time UT + 8:00, China
-
Cuba Standard Time UT-4:00, Cuba
Analyze again
Obviously, UTC time has nothing to do with it here, it’s just a time standard. Currently, system_time_zone in Mysql is CST, and CST can represent 4 different time zones. So, which time zone does Mysql treat it as?
A simple calculation shows that China time is UT + 8:00 and the United States is UT-6:00. When the Chinese time is passed in, it is directly converted to American time (without considering the time zone issue), and the time is 14 hours slower.
Now that you know the problem, you have the solution.
Backend management system + user applet implemented based on Spring Boot + MyBatis Plus + Vue & Element, supporting RBAC dynamic permissions, multi-tenancy, data permissions, workflow, three-party login, payment, SMS, mall and other functions
Project address: https://github.com/YunaiV/ruoyi-vue-pro
Video tutorial: https://doc.iocoder.cn/video/
Solution
Option 1: Modify database time zone
Since Mysql misunderstood the time zone specified by CST, set it to the correct one.
Connect to the Mysql database and set the correct time zone:
set global time_zone = ' + 8:00'; set time_zone = ' + 8:00'; flush privileges;
Execute the show command again to view: show variables like '%time\_zone%';.
Here I choose option 2: Modify database connection parameters
> Backend management system + user applet implemented based on Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element, supporting RBAC dynamic permissions, multi-tenancy, data permissions, workflow, three-party login, payment, and SMS , shopping mall and other functions > > * Project address: <https://github.com/YunaiV/yudao-cloud> > * Video tutorial: <https://doc.iocoder.cn/video/> #Original configuration serverTimezone=GMT+8 ##Modify serverTimezone=Asia/Shanghai url: jdbc:mysql://localhost:3306/aurora_admin?useUnicode=true & amp;characterEncoding=utf8 & amp;zeroDateTimeBehavior=convertToNull & amp;useSSL=true & amp;serverTimezone=Asia/Shanghai & amp;autoReconnect=true & amp;rewriteBatchedStatements=true & amp;allowMultiQueries=true
At this point, I thought that the problem must have been solved; I happily tested it; the result was still eight hours behind? But the time of the local project was normal, and I began to have an ominous premonition; so I connected to the online database locally and started testing, and found that the time was normal. At this point, we have basically found out that the problem is not MySQL.
Troubleshooting Linux
I began to wonder if there was something wrong with the time zone of the Linux system;
?
Check the hardware time: hwclock –show
?
?
Check the system time: date -R
?
I found that the Linux time was no problem for four years, so I started to check the time zone configuration of the server. Check the time zone TZ configuration: echo $TZ
It was found to be empty, so check the system configuration; check the system configuration command: env
I found that there was indeed no TZ configuration. The system did not set the TZ variable, but specified the time zone through localtime; so I modified the localtime specification.
?
First delete the TZ environment variable: unset TZ
?
?
Then execute: ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime command to create a shortcut named localtime in the etc directory and assign it to the Shanghai time zone file;
?
After the modification was completed, I decisively restarted the project test. The results were disappointing and the time remained unchanged, so I tried to directly add the TZ configuration.
?
Command: export TZ=Asia/Shanghai
?
Check it out again:
It can be seen that the TZ configuration has been set up successfully. At this point, I seem to see hope; so I tested again, and then I was dumbfounded. The time was still eight hours short; at this point, I really don’t know what else I haven’t checked. , so I went through the investigation process again in my mind.
1. The database test on the local connection is normal, so there must be no problem with the database. 2. There is no problem with the project program: @JsonFormat() does not specify other time zones, and the field types are also correct; 3. The Linux time is also correct. No problem, the time zone is also set;
Troubleshooting Docker
I suddenly thought that the project was built through Docker. Could it be that there was a problem with the time zone inside Docker? This was the only thing that had not been checked, so I checked the Dockerfile configuration file!
It is a very simple configuration, there is no reason for problems, for the sake of safety, I decided to manually specify a time zone for him, the final configuration file; add configuration:
# Install tzdata (used if setting time zone does not take effect) # RUN apk add --no-cache tzdata # Set time zone ENV TZ="Asia/Shanghai"
Rebuild the project and run it, test again, and the time is normal.
Welcome to join my knowledge planet and comprehensively improve your technical capabilities.
To join, “Long press” or “Scan” the QR code below:
Planet’s content includes: project practice, interviews and recruitment, source code analysis, and learning routes.
If the article is helpful, please read it and forward it. Thank you for your support (*^__^*)