LASSIC Media らしくメディア
MySQL 5.7終了、8.0へのDB移行を外注で対応
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- MySQL 5.7は2023年10月25日公開の5.7.44を最後に、Oracleの延長サポートを終えました。
- MySQL 8.0でも認証方式やSQL構文の既定値が変わっており、非互換の事前確認が移行の前提になります。
- 移行方式の検証や切替設計を内製で担うには専門知識と工数が必要で、外部委託も選択肢になります。
目次
2023年10月25日、MySQL 5.7がOracle延長サポート終了
MySQL 5.7のサポート終了とは、Oracleが2023年10月25日公開の5.7.44を最後に延長サポートを終えた状態を指します*1*3。以降は新たなセキュリティ修正が提供されないため、稼働を続けるには8.0や8.4 LTSへの移行を検討する必要があります。
MySQL 5.7は2015年10月21日にGA(一般提供開始)を迎え、8年にわたり国内外の企業システムで利用されてきました*2。Oracleのサポートポリシーには、公開から一定期間の延長サポートを経て、既存の修正のみを扱うSustaining Supportへ移行する仕組みがあります*1。MySQL 5.7はこの仕組みに沿って2023年10月25日に当該の段階へ移行し、以後は新規のセキュリティパッチが提供されていません*1*3。
サポート終了はMySQL 5.7だけの出来事ではありません。上位バージョンにもいずれ同じ節目が訪れるため、移行先を選ぶ際にはサポート期間の見通しも欠かせない判断材料になります*1。主要バージョンの提供開始とサポート終了の時期を整理すると、次の通りです*1*2*3*4*9。
| バージョン | 提供開始(GA) | サポート終了(Sustaining移行) | 備考 |
|---|---|---|---|
| 5.7 | 2015年10月21日 | 2023年10月25日 | 新規の修正提供なし |
| 8.0 | 2018年4月19日 | 2026年4月21日 | 新規の修正提供なし |
| 8.4(LTS) | 2024年4月30日 | 未到達 | Premier5年+Extended3年の枠を適用 |
セキュリティ修正停止と非互換蓄積——移行を先送りするリスク
MySQL 5.7はOracleのSustaining Supportの段階に入っており、新たに見つかった脆弱性への公式な修正は提供されません*1。この状態で稼働を続けると、既知・未知を問わず脆弱性への対応窓口を自社で持たない状況が続くことになります。個人情報や決済情報を扱うシステムでは、この状況自体が監査や取引先からの指摘対象になりかねません。
移行の着手が遅れるほど、稼働中のバージョンと最新バージョンの間に積み重なる仕様変更の量は増えていきます*1。5.7から8.0への差分に加え、8.0の内部でも認証方式やSQL構文の既定値が変わっているため、確認すべき項目は単純な新機能の把握にとどまりません*5。稼働年数が長いシステムほど、影響範囲の洗い出しに時間を要する傾向があります。
OS・接続ドライバ・ORM(プログラムのオブジェクトとデータベースを対応付ける仕組み)など、周辺ソフトウェアの側も対応を順次終えていきます。古いMySQLバージョンへの対応終了はデータベース単体の話にとどまりません。接続するアプリケーション全体を含めた確認が欠かせません。
認証方式・SQL既定値の変更——MySQL 8.0移行で確認すべき非互換
MySQL 8.0では、既定の認証プラグインがcaching_sha2_passwordに変わりました*6。これはパスワードをキャッシュ付きSHA-256方式で確認する仕組みです。既存アカウントの認証方式はアップグレード後もそのまま引き継がれますが、新規に作成するアカウントは既定でこの方式が使われます*6。
5.7以前のlibmysqlclientでビルドされたクライアントやドライバが存在します。これらはcaching_sha2_password方式のアカウントに接続できないことがあります*6。接続ライブラリ・ドライバのバージョンは事前に確認しておく必要があります。対応が必要な箇所の洗い出しが移行計画の前提になります。
認証方式以外にも、SQL構文や文字コードの既定値がMySQL 8.0で変わりました*5。主な変更点を比較すると次の通りです。
| 項目 | MySQL 5.7 | MySQL 8.0 |
|---|---|---|
| 既定の認証プラグイン | mysql_native_password | caching_sha2_password*6 |
| 既定の文字コード/照合順序 | latin1または環境設定に依存/utf8mb4_general_ci | utf8mb4/utf8mb4_0900_ai_ci*5 |
| 既定のSQL mode | 環境ごとの設定に依存 | ONLY_FULL_GROUP_BY,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION*5 |
| 予約語 | 8.0時点の追加分を含まない | 新たな予約語が複数追加*5 |
MySQL Shell(公式の運用ツール)には、非互換を検出するutil.checkForServerUpgradeというユーティリティが用意されています*7。移行対象のサーバーに接続して実行すると、警告やエラーをレポート形式で出力します。移行計画の初期段階で対象システムの互換性を確認する用途に使えます*7。
8.0か8.4 LTSか——MySQLのリリースモデルと移行先の選び方
MySQL 8.0も2026年4月21日にOracleのSustaining Supportへ移行し、新規のセキュリティ修正が提供されない段階に入りました*1。5.7からの移行先を8.0とする場合、いずれこの節目に直面することになります。
Oracleは2024年以降、MySQLのリリース形態をInnovationリリースとLTS(長期サポート)リリースの2系統に整理しています*8。LTSリリースはOracle Lifetime Support Policyの対象です。Premier Support 5年とExtended Support 3年を合わせた期間、サポートされます*8。一方でInnovationリリースは、次のInnovationリリースが公開されるまでの間のみサポートされる位置づけです*8。
MySQL 8.4はこの新方式で最初に位置づけられたLTSリリースで、2024年4月30日にGAを迎えました*9。5.7や8.0からの移行先としては、次の節目までのサポート期間を長く確保できるLTSリリースを軸に検討することが現実的といえます。
LTSリリースは仕様変更を必要最小限にとどめる方針で提供されます*8。そのため8.0からLTSへの追加検証は、8.0への新規移行に比べて小さく済む見込みです。ただし5.7から直接LTSへ移行する場合は、8.0で生じた非互換をまとめて確認する必要がある点に変わりはありません。
MySQL移行を内製で担う負荷と外部委託という選択肢
MySQL 5.7から8.0または8.4 LTSへの移行を内製で進める場合、バージョン差分の把握や互換性調査が必要です。加えて、検証環境の構築や切替手順の設計といった作業も欠かせません。これらをまとめて1名の兼務で担当する体制では、通常業務と並行しての対応が負荷になりやすい傾向があります。
util.checkForServerUpgradeでレポートが得られても、実際の修正やアプリケーション側の改修、切替のリハーサルは別途工数を要する作業です*7。検証環境での移行リハーサルと、本番切替時の監視体制の準備には、それぞれ人員を割り当てる必要があります。
外部パートナーに委託する場合は、非互換の洗い出しから検証環境の構築、切替時の対応、切替後の監視までを一括して依頼できるかどうかが選定の分かれ目です。内製は既存体制をそのまま活用できる一方、外部委託は専門知識を持つ体制に短期間で対応を任せやすいという違いがあります。自社の運用体制とスケジュールの余裕を踏まえて判断することが大切です。
まとめ：MySQL 8.0移行で押さえる3つの判断軸
本稿ではMySQL 5.7のサポート終了(EOL)を起点に、移行先の選び方と技術的な非互換を整理しました。要点は3つに集約できます。第一に、MySQL 5.7は2023年10月25日にOracleの延長サポートを終え、以後は新規のセキュリティ修正が提供されていません。第二に、MySQL 8.0も2026年4月21日にSustaining Supportへ移行しました。そのため、移行先には8.4 LTSも選択肢に含めて検討する必要があります。第三に、認証方式・SQL既定値の非互換を洗い出し、検証から切替までを内製で担うには専門知識と工数が必要で、社内リソースとの兼ね合いで外部委託も判断材料になります。
よくある質問
MySQL 5.7を今のまま使い続けるとどうなりますか。
MySQL 5.7は2023年10月25日でOracleの延長サポートが終了しています*1*3。そのため、新たに脆弱性が見つかっても公式のセキュリティ修正を受けられません。稼働を続けるほど周辺ソフトウェアの対応終了も重なりやすく、早めの移行計画が求められます。
移行先はMySQL 8.0と8.4 LTSのどちらを選ぶべきですか。
MySQL 8.0は2026年4月21日にOracleのSustaining Supportへ移行しており、新規のセキュリティ修正はすでに提供されていません*1。次の移行までのサポート期間を長く確保したい場合は、LTS(長期サポート)リリースであるMySQL 8.4を軸に検討することが現実的です*8*9。
5.7から8.0への移行で特に注意すべき非互換は何ですか。
既定の認証プラグインがcaching_sha2_passwordに変わっている点と*6、SQL modeや文字コードの既定値が変わっている点です*5。事前にMySQL Shellのutil.checkForServerUpgradeを実行し、対象システムの非互換を洗い出すことをおすすめします*7。
移行を外部委託する場合、何を確認すればよいですか。
検証環境の構築範囲、非互換の洗い出し方法、切替時の立ち会い体制、障害時の切り戻し手順を委託先とすり合わせることが大切です。契約前に成果物と検証項目を明確にしておくと、後工程の手戻りを防ぎやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：MySQL「MySQL Product Support EOL Announcements」（MySQL Product Support EOL Announcements（www.mysql.com/support/eol-notice.html））
- *2 出典：MySQL 5.7 Release Notes「Changes in MySQL 5.7.9 (2015-10-21, General Availability)」（https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-9.html）
- *3 出典：MySQL 5.7 Release Notes「Changes in MySQL 5.7.44 (2023-10-25)」（https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-44.html）
- *4 出典：MySQL 8.0 Release Notes「Changes in MySQL 8.0.11 (2018-04-19, General Availability)」（https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-11.html）
- *5 出典：MySQL 8.0 Reference Manual「3.5 Changes in MySQL 8.0」（https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html）
- *6 出典：MySQL Blog Archive「Upgrading to MySQL 8.0 : Default Authentication Plugin Considerations」（https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-default-authentication-plugin-considerations/）
- *7 出典：MySQL Shell 8.0「11.1 Upgrade Checker Utility」（https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-upgrade.html）
- *8 出典：MySQL 8.4 Reference Manual「1.3 MySQL Releases: Innovation and LTS」（https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html）
- *9 出典：MySQL 8.4 Release Notes「Changes in MySQL 8.4.0 (2024-04-30)」（https://dev.mysql.com/doc/relnotes/mysql/8.4/en/news-8-4-0.html）
