はじめに
MySQL8の2038年問題を調べると、TIMESTAMP型のオーバーフローに関する情報が多数ヒットします。
ではそれだけ対応すればMySQL8でも2038年を超えられるのかな？と疑問を持って確認してみたら、やはり他にもありましたというお話。
CREATE TABLEできなくなる
サーバの時刻を2038年以降に設定して開発中のシステムの動作検証をすると、ダンプしたデータを復旧できないという問題が発生。解析するとCREATE TABLEを実行できなくなることがわかりました。
実行時のログは次のとおり。ERROR 3507が返されます。
Operation failed: There was an error while applying the SQL script to the database.
Executing:
CREATE TABLE `sys`.`new_table` (
`id` INT NOT NULL,
PRIMARY KEY (`id`));
ERROR 3507: Failed to update tables dictionary object.
SQL Statement:
CREATE TABLE `sys`.`new_table` (
`id` INT NOT NULL,
PRIMARY KEY (`id`))
でもバグじゃないらしい
Oracleに問い合わせをしてみました。回答は「Not a bug.」。
この挙動も日付のデータ型（signed 32-bit integer）が起因しているそうです。
データ型は標準SQLで定義されているためOracleはその改訂待ち。
間違いなく2030年までに改訂される見込みで、改訂されるとすぐに反映する準備ができているとのことです。
What you report is truly a bug, but the one on which we can not do anything.
As per the SQL standard, the time is defined as a signed 32-bit integer. This is in line with the ISO standard.
Hence, we are waiting on the new standard where this variable will be 64 bits wide. Our Worklog entry for that change is already prepared, but the current standard has not changed interim.
Until that is done , we can not do anything, just like it is noted in the bug report to which you refer.
Not a bug.
We can assure you that ISO committee is working on the solution.
As soon as the new standard is revealed by that committee, we shall implement it immediately.
Currently, there are two alternative solutions. One is to use unsigned 32-bit integer and the other one is to use singed 64-bit integer.
When the new standard comes out, we shall implement it immediately.
We are sure that this will happen before the year 2030.
結論
MySQLの少なくとも8以下で稼働させているシステムを2038年以降も継続して利用したい場合、必ず次期バージョンに移行させましょう。
といっても、公式のサポートが切れるまでに都度移行していれば問題は起きないでしょう。
また、MySQLのTIMESTAMP型は原則使わないようにとされていることが多いですが、アップデートによりこの範囲も改訂される可能性が高いのではないでしょうか。