MySQL 8.0 EOL到来｜Linux管理者のためのMySQL 8.4 LTS移行判断フレーム

「MySQL 8.0のEOL（End of Life）が来てしまったけれど、移行先は8.4と9.7のどちらを選ぶべきだろう？」
2026年4月、MySQL 8.0は公式サポートを終了し、Oracleの「Sustaining Support」のみに移行しました。新規セキュリティパッチもバグ修正も提供されない状態です。さらに同月、新しいLTS（長期サポート版）であるMySQL 9.7がリリースされ、選択肢が一気に複雑になりました。

この記事では、Linuxサーバー上でMySQLを運用してきた管理者に向けて、MySQL 8.0からのバージョン移行判断フレームを実務観点で整理します。

MySQL 8.0 EOLの現状｜2026年4月で何が変わったか

MySQL 8.0は、2018年4月のリリースから約8年間、もっとも長く使われてきたMySQLメジャーバージョンの一つです。2026年4月のEOLにより、次のフェーズに移行しました。

1. OracleのMySQLサポートフェーズ

OracleのLifetime Supportポリシーでは、製品は次の3段階のサポートを受けます。

・Premier Support：通常のセキュリティパッチ・バグ修正・新機能
・Extended Support：追加料金で延長、セキュリティ修正中心
・Sustaining Support：既存パッチへのアクセスのみ、新規修正なし

MySQL 8.0はPremier Supportが2025年4月、Extended Supportが2026年4月で終了し、現在はSustaining Supportの段階です。これは「すでに公開された修正には引き続きアクセスできるが、今後発見される脆弱性には対応されない」という意味です。

2. HeatWaveユーザー向けの例外

Oracle Cloud上のMySQL HeatWaveユーザーに関しては、Oracleが2027年4月までMySQL 8.0インスタンスの延長サポートを提供すると公式にアナウンスしています。クラウドサービス側のみの特例で、オンプレミスや他クラウドのMySQL 8.0は対象外です。

移行先候補｜MySQL 8.4 LTSとMySQL 9.7 LTSの比較

2026年5月時点で、MySQLの選択肢は次のように整理できます。

項目	MySQL 8.0	MySQL 8.4 LTS	MySQL 9.7 LTS
初回リリース	2018年4月	2024年4月	2026年4月
Premier Support	2025年4月終了	2029年4月まで	2034年4月まで
Extended Support	2026年4月終了	2032年4月まで	2037年4月まで
現在の状態	Sustaining Support	Premier Support中	Premier Support中
移行元 8.0からの直接アップ	—	可能	不可（8.4経由必須）

長期運用を見据えるなら9.7 LTSが圧倒的に長持ちしますが、8.0からの直接移行ができないため、まず8.4に上げてから9.7に進むという2段階移行が必要です。実務では、まず8.4に移行してしばらく安定運用させ、必要に応じて9.7に進むのが現実的です。

MySQL 8.0→8.4で発生する破壊的変更｜事前に潰しておくポイント

8.0から8.4への移行は「マイナーアップグレード相当に見える」名前ですが、実際には大きな変更が含まれます。アプリケーションが動かなくなる典型パターンを整理します。

1. mysql_native_password認証プラグインの無効化

8.4ではmysql_native_passwordプラグインがデフォルトで無効化されました。古いMySQLクライアントライブラリやレガシーアプリケーションでは、これにより認証エラーで接続できなくなります。

回避策：
・my.cnfにmysql_native_password=ONを明示
・アプリ側をcaching_sha2_password対応に更新
・接続ライブラリ（PHP mysqli、Python mysqlclient等）を最新版に更新

ただしmysql_native_passwordは将来のバージョンで完全削除予定のため、長期的にはcaching_sha2_passwordへの移行が必要です。

2. innodb_log_file_sizeの廃止

InnoDBのREDOログ設定が大幅に変わりました。
・削除：innodb_log_file_size、innodb_log_files_in_group
・新規：innodb_redo_log_capacity（REDOログの合計サイズを直接指定）

my.cnfに古い設定が残っていると起動時に警告が出ます。8.4起動前に該当行をコメントアウトし、新形式で書き直す必要があります。

3. slave_*変数のreplica_*への改名

レプリケーション関連の変数名が一括変更されました。
・slave_compressed_protocol → replica_compressed_protocol
・master_info_repository → source_info_repository
・SHOW SLAVE STATUS → SHOW REPLICA STATUS

監視スクリプトやレプリケーション運用ツール（ZabbixテンプレートやPMM、独自シェル）でこれらを使っている場合、すべて書き換えが必要です。

4. 細かいSQL構文・予約語の追加

8.4では新たに予約語に昇格した識別子があります。たとえばINTERSECT、EXCEPTなどです。テーブル名・カラム名に使っている場合はバッククォートで囲むか、リネームが必要です。

移行手順｜In-Place Upgradeの基本フロー

MySQL 8.0から8.4へのアップグレードには、In-Place（同一サーバーでバイナリ入替）と Logical Dump（mysqldumpで全データを出し入れ）の2方式があります。実務では速度の点でIn-Placeを選ぶケースが多いですが、その分リスクも高いです。

1. 事前確認：MySQL Shell Upgrade Checker

MySQL Shellに同梱されているUpgrade Checkerは、現状DBの状態を解析して8.4で問題が起きそうな箇所を一覧化してくれます。

mysqlsh root@localhost -- util check-for-server-upgrade --target-version=8.4.0

このコマンドの出力で「error」と判定された項目はゼロにしてから移行に進むのが鉄則です。「warning」は許容可能だが、本番投入前に把握しておきます。

2. フルバックアップ

In-Place Upgradeはロールバックできません。失敗した場合はバックアップからの復旧しか道がないため、バックアップが取れていない状態での実行は厳禁です。

推奨方式：
・mysqldump --all-databases --single-transaction --master-data=2（小規模向け）
・mysqlsh util dump-instance（並列・圧縮対応、大規模向け）
・Percona XtraBackup（オンライン物理バックアップ）

3. アップグレード実行

パッケージマネージャー経由で実施します。
・APT系（Ubuntu/Debian）：MySQL APT repositoryで8.4を有効化しapt upgrade
・YUM/DNF系（RHEL/AlmaLinux）：MySQL Community YUM repositoryで8.4を有効化しdnf upgrade

8.4初回起動時にmysql_upgrade相当の処理が自動実行され、システムテーブルが更新されます。

4. 起動後の確認

・SELECT VERSION();で8.4系であることを確認
・SHOW WARNINGS;で起動時警告を確認
・主要テーブルへのSELECT、レプリケーション動作（あればSHOW REPLICA STATUS）
・アプリケーション側からの接続テスト

移行判断フレーム｜どの環境を、いつ、どこに上げるか

全システムを一斉に上げる必要はありません。むしろ、優先度を切り分けて段階的に進めるのが現実的です。

1. 優先度の判断軸

次の3軸でシステムを格付けします。

・外部公開度：インターネットに公開しているDBは最優先（脆弱性の影響大）
・データ感度：顧客情報・決済情報を持つDBは早期移行
・変更頻度：新機能開発が続くシステムは8.4の新機能恩恵が大きい

2. 段階的移行計画の例

1人～数人体制で運用する小規模事業者の場合、次のような段階移行が実行可能です。

・第1フェーズ（～2026年8月）：外部公開のWebサービス用DBを8.4へ
・第2フェーズ（～2026年12月）：社内システム・分析用DBを8.4へ
・第3フェーズ（～2027年4月）：レガシー業務システム（mysql_native_password依存）を順次対応
・第4フェーズ（2027年以降）：必要に応じて8.4→9.7へ二段階移行

3. ディストロ標準パッケージとの関係

ディストリビューションが提供するMySQLパッケージは、ベンダー独自のフォーク・ビルドが入っていることがあります。
・Ubuntu 24.04標準：MySQL 8.0系（universeリポジトリ）
・RHEL 9標準：MySQL 8.0系（AppStream）またはMariaDB
・Oracle公式リポジトリ：8.4・9.7とも対応

ディストロ標準のMySQL 8.0は、ディストロ側の延命パッチに依存するため、ディストロのEOLポリシー（Ubuntu 24.04なら2029年4月、RHEL 9なら2032年5月）まで継続供給されます。ただし、これはOracleの公式パッチではないため、リスク評価が別途必要です。

監視・運用ツール側の対応｜後から困らないためのチェックリスト

DBエンジン本体を上げるだけでは終わらないのが、現場での実態です。周辺の監視・運用ツールを並行して確認しましょう。

1. 監視テンプレートの修正対象

ZabbixやNagios、Prometheus mysqld_exporterなどで使っているクエリ・変数名を点検します。

・SHOW SLAVE STATUSを使っているテンプレート → SHOW REPLICA STATUSに変更
・slave_*変数を参照しているスクリプト → replica_*へ変更
・パフォーマンス取得SQL（performance_schema） → 一部カラム名が変更されているため要再確認

2. バックアップツールの互換性

Percona XtraBackup、mysqldump、mysqlpumpなどの対応バージョンも確認が必要です。

・Percona XtraBackup 8.4以降がMySQL 8.4をサポート（古いXtraBackup 8.0系では不可）
・mysqlpumpは8.4以降で非推奨化、mysqlsh util dump-instanceへの移行推奨
・mysqldumpは引き続き利用可だが、新機能（一部の制約構文）の出力に注意

3. ORM・接続ライブラリのバージョン

アプリ側で使っているORMや接続ライブラリも、認証プラグイン変更の影響を受けます。

・PHP（mysqli/PDO_MySQL）：PHP 7.4以降推奨、caching_sha2_password対応
・Python（mysqlclient/PyMySQL）：mysqlclient 2.0以降、PyMySQL 1.0以降
・Java（mysql-connector-j）：8.x系の最新版に更新
・Node.js（mysql2）：mysql2 2.x以降を使う（mysqlパッケージは非推奨）

MariaDBへの移行という選択肢

MySQL 8.0からMariaDBへの移行を検討する管理者も少なくありません。一見「同じ系統だから簡単」に見えますが、現実は注意点が多い領域です。

1. 互換性は完璧ではない

MariaDB 11.x系はMySQL 8.0と完全互換ではありません。GTID、レプリケーション、JSON型、認証プラグインなどで挙動の違いがあり、アプリケーション側の修正が必要なケースがあります。

2. 公式OracleではなくMariaDB Foundation

MariaDBはMariaDB Corp.とMariaDB Foundationが開発・サポートします。ライセンス的にはGPLで自由ですが、商用サポートはMariaDB Corp.経由となり、Oracleのサポート契約とは別の契約体系になります。

3. 既存資産がMySQL中心ならMySQL 8.4が安全

小規模事業者で「とにかく安全に移行を済ませたい」場合は、互換性リスクの少ないMySQL 8.4 LTSへの直線的移行を推奨します。MariaDBへの移行は、運用ノウハウの蓄積コストも含めて再検討する必要があります。

よくある質問｜MySQL 8.0 EOL対応で迷うポイント

Q1. すぐに8.4に上げる時間がない場合、当面どうするべき？

A. 短期的には次の3点を実施します。1つ目に、外部からのアクセスをファイアウォール・iptablesで最小限に絞る（DBへの直接接続を禁止）。2つ目に、アプリケーション側のSQLインジェクション対策・WAF導入を強化する。3つ目に、定期バックアップとログ監視を強化し、異常検知を早める。これらはあくまで「移行までの応急処置」であり、根本対策ではない点を経営層にも明示しておきます。

Q2. mysqldumpで取ったバックアップで戻せる？

A. 8.0時点で取ったmysqldumpファイルは、新しい8.0インスタンスを構築してmysql < dump.sqlでリストアできます。ただし、巨大DBでは復旧時間が10～20時間以上かかるため、Percona XtraBackup等の物理バックアップとの併用が現実的です。

Q3. アプリケーションが古くて8.4に上げると動かない場合は？

A. 選択肢は3つあります。①アプリ側を改修する（最も安全）、②MariaDBや旧版互換のあるディストロ標準パッケージで延命する（リスク評価必須）、③Oracle MySQL HeatWaveの有償延長を利用する（クラウド前提）。改修工数とリスクのバランスを、システム単位で個別判断します。

Q4. 8.4の次の9.7 LTSにいきなり進むべき？

A. 9.7 LTSへの移行は「8.0→8.4→9.7」の2段階が必須です。9.7はリリースされて間もないため、本番投入は8.4で安定運用してから検討するのが安全です。次のLTSが出るのは早くて2028年なので、しばらくは8.4で十分対応できます。

参考書籍｜MySQL運用とSQL基礎を体系的に学ぶ

※本セクションには広告（PR）リンクを含みます

MySQLの運用とSQL基礎を体系的に学べる定番書を紹介します。8.4移行後の運用設計の前提として役立ちます。

・SQL 第2版 ゼロからはじめるデータベース操作（翔泳社）：MySQL・PostgreSQL・SQL Serverを横断的にカバーするSQL入門の決定版
・Linux教科書 LPICレベル1 Version5.0対応（翔泳社）：MySQLが動くLinuxサーバーの基本（権限、サービス管理、ログ運用）を網羅

本記事のまとめ

ポイント	内容
MySQL 8.0の状態	2026年4月でEOL到達、Sustaining Supportへ移行（新パッチなし）
主な移行先	8.4 LTS（～2029年4月Premier）または9.7 LTS（～2034年4月Premier）
移行経路	8.0→8.4は直接可、8.0→9.7は8.4を経由する2段階移行が必要
主な破壊的変更	mysql_native_password無効化、innodb_log_file_size廃止、slave_*→replica_*
必須の事前準備	MySQL Shell Upgrade Checker実行＋フルバックアップ取得
移行優先度	外部公開度・データ感度・変更頻度の3軸で段階的に
HeatWave特例	OCI MySQL HeatWaveのみ2027年4月までの延長サポートあり

MySQLのバージョン移行は、DB管理者にとって数年に1度の大仕事です。EOLに追われて慌てて移行するより、検証環境で8.4を立ち上げてアプリ側の挙動を1ヶ月単位でじっくり観察し、本番には満を持して投入する流れが、20年以上Linuxサーバーを運用してきた経験から言っても、結局いちばん速い道です。

---

• 次のページへ：Ubuntu 24.04でLet's Encrypt自動更新を確実に動かす｜Certbot snap/systemd-timer/cron 3パターン徹底比較
• 前のページへ：Ubuntu Core 26で2041年まで使える"不変Linux"｜EU CRA対応とTPM/LUKS2鍵管理を読み解く
• この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る