こんにちは、インフラエンジニアのryuです。
みなさんが運用しているサーバーのMySQLは、いまどのバージョンでしょうか？
2018年に出たMySQL 8.0は、2026年4月にリリースされた 8.0.46 を最後にサポートが終了しました。Oracleのリリースノートにも、8.0の利用者は8.4 LTSかInnovationリリースへ上げるように書かれています。
「まだ動いているから大丈夫」と思っていても、これから見つかる脆弱性には修正が出ません。この記事では、8.0のサポート終了で何が変わったのかと、移行先の8.4 LTSで気をつけたい変更点を順番に見ていきます。
MySQL 8.0のサポート終了で何が変わったの？¶
まずは、8.0がどういう状態になったのかを確認しておきます。
MySQLには、長く使う前提のLTS（Long Term Support）リリースと、新機能を早く入れるInnovationリリースの2つの系列があります。8.0はこの区別ができる前のバージョンで、8.4が最初のLTSです。
Oracleの資料では、MySQL 8.0の延長サポートは2026年4月30日まで、MySQL 8.4 LTSのサポート終了は2032年4月とされています。
つまり、8.0から8.4へ上げると、あと5年以上はサポートのあるバージョンで運用できます。
ただし、どこでMySQLを動かしているかによって、影響の出方がかなり違います。
使い方によって期限が違う¶
主な使い方ごとに、2026年10月時点の状況を表にまとめました。
| 使い方 | 8.0の状況 | 気をつけること |
|---|---|---|
| 自分でインストールしたMySQL（Community版） | 8.0.46が最後のリリース。これ以降の修正は出ない | 自分で8.4へ上げる計画が必要 |
| Amazon RDS for MySQL / Aurora | 標準サポートは2026年7月31日で終了。延長サポート（有料）に自動で登録される | 8.0のまま動かすと追加料金がかかる |
| Oracle HeatWave | 8.0のインスタンスは2027年4月までサポートを延長 | 新しく8.0のDBシステムは作れない |
| OSのパッケージ（Ubuntu・RHELなど） | ディストリビューションごとに対応が違う | パッケージの更新履歴を確認する |
いちばん影響が見えやすいのは、Amazon RDSです。
RDSでは標準サポートが終わると、データベースは自動で延長サポート（RDS Extended Support）に登録されます。データベースはそのまま動き続けますが、vCPU時間あたりの追加料金がかかります。
AWSのドキュメントでは、延長サポートへの登録でエンジンのバージョンや稼働が変わることはないと説明されています。止まらないぶん、請求書を見るまで気づかないこともあるので、8.0のインスタンスが残っていないか一度確認しておくと安心です。
AWS CLIが使える環境なら、次のコマンドでMySQLのインスタンスとエンジンのバージョンを一覧にできます。
# RDS for MySQL のインスタンス名とエンジンのバージョンを一覧にする
aws rds describe-db-instances \
--query "DBInstances[?Engine=='mysql'].[DBInstanceIdentifier,EngineVersion]" \
--output table
8.0. で始まるバージョンが表示されたら、そのインスタンスは延長サポートの対象です。リージョンごとに結果が分かれるので、使っているリージョンをすべて確認してください。検証用に作ってそのままになっているインスタンスが見つかることもあります。
OSのパッケージで入れている場合¶
UbuntuやRHELのパッケージでMySQLを入れている場合は、少し事情が違います。
OSのサポートが続いていても、パッケージの中身のMySQL 8.0は本家のサポートが終わっています。ディストリビューションが独自に修正を出し続けるかどうかは、それぞれの方針しだいです。
たとえばUbuntu 24.04のセキュリティ情報では、2026年2月に 8.0.45 への更新が出ています。それ以降も更新が出ているかは、次のようにパッケージの変更履歴で確かめられます。
# いま入っているバージョン
mysql --version
# Ubuntu / Debian：パッケージの変更履歴を確認する
apt changelog mysql-server-8.0 | head -20
# RHEL系：どのバージョンのパッケージが入っているか
rpm -qa | grep -i mysql
RHEL 9では、Red Hatのドキュメントによると9.6以降でMySQL 8.4が提供されています。8.0と8.4は同時には入れられないので、切り替えは計画的に進める必要があります。
OSのサポート終了とミドルウェアのサポート終了が別の話になるのは、以前書いた『OpenSSL 3.0のサポート終了』や『Python 3.10のサポート終了』と同じ構図です。
8.4 LTSに上げると何が変わるの？¶
8.0から8.4へは、LTSからLTSへの直接のアップグレードとしてサポートされています。
ただ、8.0の途中で非推奨になっていた機能が、8.4でまとめて削除・無効化されました。アプリケーションや運用スクリプトに影響しやすいものを、3つに分けて見ていきます。
認証プラグイン mysql_native_password が無効になった¶
いちばん問い合わせが増えそうなのが、認証まわりの変更です。
8.4では、古い認証方式の mysql_native_password がデフォルトで無効になりました。プラグイン自体は残っていますが、サーバー起動時に読み込まれません。新しく作るユーザーは caching_sha2_password を使います。
古いドライバーを使っているアプリケーションや、ユーザーを mysql_native_password で作ったままのシステムは、アップグレード後にログインできなくなることがあります。
まずは、どのユーザーがどの認証方式を使っているかを確認しておきましょう。
-- ユーザーごとの認証プラグインを確認する
SELECT user, host, plugin FROM mysql.user;
どうしても古い方式が必要な場合は、my.cnf の [mysqld] に mysql-native-password=ON を書くと有効にできます。ただ、mysql_native_password は将来のバージョンで削除される予定です。8.4への移行を機に、ユーザーを caching_sha2_password に切り替えておくほうがあとで困りません。
あわせて、8.0で認証方式の初期値を決めていた default_authentication_plugin という設定は、8.4で削除されています。my.cnf に残っていると起動時のエラーになるので、設定ファイルも見直してください。
レプリケーションのコマンドが新しい名前だけになった¶
レプリケーションを組んでいる環境では、コマンドの名前に注意が必要です。
8.0の途中から、MASTER と SLAVE という用語を使ったコマンドは非推奨になっていました。8.4では古い名前が削除され、実行すると構文エラーになります。
| 8.0まで使えた書き方 | 8.4での書き方 |
|---|---|
CHANGE MASTER TO |
CHANGE REPLICATION SOURCE TO |
START SLAVE |
START REPLICA |
STOP SLAVE |
STOP REPLICA |
SHOW SLAVE STATUS |
SHOW REPLICA STATUS |
RESET SLAVE |
RESET REPLICA |
SHOW SLAVE HOSTS |
SHOW REPLICAS |
見落としやすいのは、監視のスクリプトです。
SHOW SLAVE STATUS の結果からレプリケーションの遅延を見ている監視があると、8.4に上げた瞬間に監視だけが失敗します。出力される項目名も Seconds_Behind_Master から Seconds_Behind_Source のように変わっているので、値を取り出す部分も直す必要があります。
# 運用スクリプトや監視設定に古いコマンドが残っていないか探す
grep -rnE "SLAVE STATUS|CHANGE MASTER|START SLAVE|Seconds_Behind_Master" /etc /opt/scripts 2>/dev/null
InnoDBの設定の初期値が変わった¶
3つ目は、my.cnf で何も指定していない項目の初期値です。
8.4では、今のSSD中心のサーバーに合わせて、InnoDBのいくつかの設定の初期値が見直されました。代表的なものを表にしました。
| 設定 | 8.0の初期値 | 8.4の初期値 |
|---|---|---|
innodb_io_capacity |
200 | 10000 |
innodb_log_buffer_size |
16MB | 64MB |
innodb_adaptive_hash_index |
ON | OFF |
設定ファイルで明示的に値を書いている項目は、そのままの値が使われます。影響を受けるのは、何も書いていなかった項目です。
たとえば、古いHDDのサーバーで innodb_io_capacity が急に大きくなると、ディスクへの書き込みが増えて逆に遅くなることがあります。上げたあとにレスポンスが変わったときは、まずこの3つを疑ってみてください。
ほかにも、バックアップに使われることがあった mysqlpump や、アップグレード用の mysql_upgrade コマンドが8.4で削除されています。バックアップのスクリプトで mysqlpump を使っていないかも確認しておきましょう。
移行の前に何を確かめればいい？¶
ここまでの変更点をふまえて、実際の移行の進め方を見ていきます。
アップグレードチェッカーで事前に確認する¶
Oracleは、アップグレードの前に問題を見つけるためのツールを用意しています。MySQL Shellに入っている、アップグレードチェッカーです。
# MySQL Shell から、8.4へのアップグレードで問題がないかを確認する
mysqlsh -- util checkForServerUpgrade root@localhost:3306 --target-version=8.4.0
# MySQL Shell の対話モードで実行する場合
# util.checkForServerUpgrade({targetVersion: "8.4.0"})
このチェッカーは、削除された設定値が my.cnf に残っていないか、古い認証方式のユーザーがいないかなどを確認してくれます。
ただし、見てくれるのはサーバーと設定ファイル、スキーマ、ユーザーの範囲です。アプリケーションのコードや監視スクリプトに残った古いコマンドは見つけてくれないので、先ほどの grep のような確認は別に必要です。
本番の前に検証環境で上げてみる¶
確認ができたら、いきなり本番ではなく、検証環境で一度上げてみるのが基本です。
本番・検証・開発の環境を分けている理由については『本番・検証・開発の3つの環境の使い分け』で書いているので、あわせて読んでみてください。
検証環境では、次の流れで確認していくと漏れが少なくなります。
| 順番 | やること | 見るポイント |
|---|---|---|
| 1 | 本番のバックアップを取り、検証環境に戻す | バックアップから本当に戻せるか |
| 2 | アップグレードチェッカーを実行する | エラーと警告の内容 |
| 3 | 8.4へ上げる | 起動時のエラーログ |
| 4 | アプリケーションからつないでみる | ログインできるか、ドライバーのエラーが出ないか |
| 5 | 監視・バックアップのスクリプトを動かす | 古いコマンドで失敗していないか |
| 6 | 普段の負荷をかけて性能を見る | InnoDBの初期値の変更の影響 |
特に1番目のバックアップは大事です。MySQLは一度8.4でデータファイルを更新すると、そのまま8.0に戻すことはできません。
冗長構成にしているから大丈夫、というわけでもありません。レプリケーションは間違った変更もそのまま複製するので、戻すためのバックアップは別に必要です。このあたりは『冗長化とバックアップの違い』で詳しく書いています。
Dockerで手元に8.4を立ててみる¶
いきなりサーバーで試すのが不安な場合は、手元のDockerで8.4を立ててみるのも手です。
# MySQL 8.4 のコンテナを起動して、バージョンと認証プラグインを確認する
docker run -d --name mysql84 -e MYSQL_ROOT_PASSWORD=test mysql:8.4
docker exec -it mysql84 mysql -uroot -ptest -e "SELECT VERSION(); SELECT user, plugin FROM mysql.user;"
自分のアプリケーションの接続設定をこのコンテナに向けてみると、認証まわりの問題があるかを短時間で確かめられます。DockerでMySQLを動かす手順は『DockerでphpMyAdminとMySQLを構築する方法』も参考にしてください。
新人のインフラエンジニアが押さえておきたいこと¶
最後に、これからインフラエンジニアとして現場に入る人向けに、今回の話のポイントをまとめておきます。
データベースのバージョンアップは、OSのアップデートに比べて影響範囲が見えにくい作業です。アプリケーション、監視、バックアップと、データベースにつながっているものすべてが確認の対象になります。
サポート終了は、そのソフトウェアにつながっている仕組みを棚卸しするきっかけだと考えると、何を確認すればいいかが見えやすくなります。
そのためには、Linuxのコマンドで設定ファイルやログを確認する力と、AWSのようなクラウドのサービスごとのサポートの考え方の両方が必要です。
InfraAcademyでは、Linuxの基本操作からサーバー構築までを順番に学べる『Linuxのロードマップ』と、RDSを含むAWSのサービスを学べる『AWSのロードマップ』を用意しています。今回のような移行作業で手が止まらないように、土台から固めておきたい方はぜひ使ってみてください。
まとめ¶
MySQL 8.0のサポート終了について、ポイントを振り返ります。
- MySQL 8.0は2026年4月の
8.0.46で終了し、移行先は2032年4月までサポートのある8.4 LTS - Amazon RDSでは2026年7月31日に標準サポートが終わり、8.0のままだと有料の延長サポートになる
- 8.4では
mysql_native_passwordが無効になり、MASTER/SLAVEのコマンドは削除された - InnoDBの初期値が変わったので、設定ファイルで指定していない項目は性能に影響することがある
- アップグレードチェッカーと検証環境での確認、戻すためのバックアップを先に用意する
8.0のまま動いているサーバーがあっても、慌てる必要はありません。どこで動いているか、何がつながっているかを1つずつ確認していけば、8.4への移行は十分に計画できます。
まずは SELECT VERSION(); で、自分の環境のバージョンを確かめるところから始めてみてください。
参考¶
- MySQL 8.0 Release Notes（Oracle）
- Changes in MySQL 8.4.0（Oracle）
- Extending MySQL 8.0 support in MySQL HeatWave（Oracle MySQL Blog）
- Introducing Amazon RDS Extended Support for MySQL databases on Amazon Aurora and Amazon RDS（AWS Database Blog）
- Using Amazon RDS Extended Support（AWS ドキュメント）
- Upgrade Checker Utility（MySQL Shell 8.4 ドキュメント）
- Percona Server for MySQL - Defaults and tuning guidance for 8.4
- Using MySQL（Red Hat Enterprise Linux 9 ドキュメント）
