Technology Sharing | Will MySQL be affected by the "Unix millennium bug"

Author: Wang Xiang

A member of the Aikesheng DBA team, responsible for the operation and maintenance of the company's DMP products and the handling of customer MySQL issues. Good at database fault handling. Have a strong interest in database technology and python.

Source of this article: original submission

* Produced by the Aikesheng open source community, original content is not allowed to be used without authorization, please contact the editor and indicate the source for reprinting.

---

Contents of this article:

Preface

What is the "Unix millennium bug"

Will MySQL be affected by the millennium bug in 2038?

Experimental results

problem causes

Sphere of influence

solution

Preface

During the May 1st holiday, I had nothing to do and brushed the forum blog; I saw a lot of people discussing the "Unix millennium bug" crisis in 2038! . I am interested, so I tested whether MySQL will die under the influence of the "Unix millennium bug"

What is the "Unix millennium bug"

In ancient times, the "millennium bug" bug once caused a lot of panic, and even many film and television dramas have exaggerated descriptions. However, after urgent consultations and "patching", the millennium bug crisis in which hardware and software "cannot properly handle the year 2000 problem" has passed smoothly. But... is this really the case? For Unix-like operating systems, they actually face the same problem, that is-the crisis of 2038! (Also known as "Unix millennium bug")! !

The screenshot is from Du Niang Baike:

Will MySQL be affected by the millennium bug in 2038?

Start testing MySQL and monitor the error log

Feel free to adjust the system time to 2038

What do you see? MySQL shuts down directly

Experimental results

If the time travel comes to 2038 or the date of the operating system is adjusted to 2038, such as 2038-10-20, you will find that the running MySQL will automatically give up the treatment, and it will also automatically shut down after restarting. It cannot be used. MySQL does not support Dates after 2038.

2038-10-20T00:01:01.976322+08:00 2 [Warning] Current time has got past year 2038.
Validating current time with 5 iterations before initiating the normal server
shutdown process.
2038-10-20T00:01:01.976465+08:00 2 [Warning] Iteration 1: Current time obtained
from system is greater than 2038
2038-10-20T00:01:01.976484+08:00 2 [Warning] Iteration 2: Current time obtained
from system is greater than 2038
2038-10-20T00:01:01.976538+08:00 2 [Warning] Iteration 3: Current time obtained
from system is greater than 2038
2038-10-20T00:01:01.976560+08:00 2 [Warning] Iteration 4: Current time obtained
from system is greater than 2038
2038-10-20T00:01:01.976580+08:00 2 [Warning] Iteration 5: Current time obtained
from system is greater than 2038
2038-10-20T00:01:01.976634+08:00 2 [ERROR] This MySQL server doesn't support
dates later than 2038

problem causes

The maximum time range supported by MySQL timestamp is from '1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.999999'. There is a paragraph in the dispatch_command() function of the source code sql/sql_parse.cc Code to detect whether the current time exceeds 2038, and if it exceeds, MySQL will be stopped immediately.

/*
If the time has gone past 2038 we need to shutdown the server. But
there is possibility of getting invalid time value on some platforms.
For example, gettimeofday() might return incorrect value on solaris
platform. Hence validating the current time with 5 iterations before
initiating the normal server shutdown process because of time getting
past 2038.
*/
/*
If the time has got past 2038 we need to shut this server down.
We do this by making sure every command is a shutdown and we
have enough privileges to shut the server down

TODO: remove this when we have full 64 bit my_time_t support
*/

From the above two comments, it should be that the MySQL internal variable my_time_t does not support 64 bits. After reaching 2038,
MySQL can't execute any commands, it just shuts down.

Sphere of influence

The current latest versions of 5.7 and 8.0 include this piece of code logic, that is, existing versions will be affected and will be automatically stopped in 2038.

• 5.7.34 (currently the latest version of 5.7)
• 8.0.25 (the latest version of the current 8.0)

solution

I look forward to the official follow-up of MySQL as soon as possible to develop a version that fully supports my_time_t 64-bit, and you can upgrade to this version before 2038.

Today is 2021.06.22, and there are still 17 years to 2038. All currently used MySQL versions need to be upgraded before 2038 arrives.