この記事では、ConoHa WINGでMySQL 5.7からMySQL 8.4へ移行したときの流れを記録します。
きっかけは、WordPressのサイトヘルスでした。
ログインするたびに、データベースサーバーが古いという内容の警告が表示されるようになり、気になってConoHaへ問い合わせました。
そのとき返ってきた内容は、ざっくり言えば「MySQL 5.7でもただちに影響はない」というものでした。
ただ、この世界に足を踏み入れたばかりのころの自分には、「MySQL…はぁ？」という状態です。
サーバー、PHP、WordPress、テーマ、プラグイン。それだけでも分からないことが多いのに、今度はデータベースです。
とはいえ、WordPressを動かしている以上、データベースは避けて通れません。記事本文、設定、カテゴリー、ユーザー情報など、WordPressの中身はデータベースに保存されています。
そこで、ConoHa WINGのデータベースマイグレーション機能を使い、MySQL 5.7からMySQL 8.4へ移行することにしました。
この記事の移行作業と画面確認は、2026年4月に行ったものです。ConoHa WINGの管理画面や案内文は、今後変更される可能性があります。
MySQLとは何か
MySQLは、WordPressのデータを保存・管理するために使われるデータベース管理システムです。
WordPressの記事や固定ページは、単なるHTMLファイルとして置かれているわけではありません。投稿本文、タイトル、カテゴリー、コメント、各種設定などは、データベースに保存されています。
ページを表示するとき、WordPressは必要な情報をデータベースから取り出し、テーマやプラグインの処理と組み合わせて、公開ページとして表示します。
- 記事本文やタイトル
- カテゴリーやタグ
- WordPressの各種設定
- テーマやプラグインが保存している設定
- ユーザー情報やコメント
こうした情報を保存している場所がデータベースです。
そのため、MySQLの移行は、見た目のテーマ変更よりも慎重に扱う必要があります。
ConoHa WINGでは契約時期によってMySQLのバージョンが違う
ConoHa WINGでは、契約時期やデータベースマイグレーションの有無によって、利用しているMySQLのバージョンが変わります。
- 2026年4月7日より前に契約した環境：MySQL 5.7
- 2026年4月7日以降に契約した環境、またはデータベースマイグレーションを実施した環境：MySQL 8.4
これはConoHa WINGの公式FAQでも案内されています。
ミコトホドは2026年4月7日より前に契約した環境だったため、移行前のMySQLは5.7でした。
MySQL 5.7のまま使い続ける不安
MySQL 5.7を使っているからといって、今日すぐWordPressが動かなくなるわけではありません。
ただし、MySQL 5.7はすでに古い世代のバージョンです。OracleのEOL告知では、MySQL 5.7は2023年10月25日時点でOracle Sustaining Supportの扱いになっています。
MySQL Product Support EOL Announcements
ここで重要なのは、「今すぐ壊れるかどうか」ではありません。
WordPressをこれからも運用していくなら、古いデータベース環境のままにしておくより、サーバー側で用意された新しい環境へ移れるときに移っておく方が安心です。
WordPress公式の推奨環境でも、データベースはMySQL 8.0以上が案内されています。
もちろん、推奨環境に満たないからといって、すぐにサイトが止まるとは限りません。
ただ、サイトヘルスに古いデータベースとして表示され続ける状態は、運営していて気持ちのよいものではありませんでした。
MySQL 8.4へ移行する前に確認したこと
MySQL 8.4は、MySQL 8系の長期サポート版です。
ConoHa WINGでは、データベースマイグレーションを実施した環境もMySQL 8.4として案内されています。
ただ、データベースの移行はボタンを押すだけで気軽に試す作業ではありません。
移行中に wp-config.php の編集が必要になると分かり、そこは特に慎重になりました。
wp-config.php は、WordPressがデータベースへ接続するための情報を書いている重要なファイルです。
何かやらかして接続エラーを起こすたびに開くアレです。
今回はMySQLの移行に合わせて、古くなっていたテーマの見直しも行いました。
使っているプラグインの更新を確認し、サイト全体のバックアップを取り、PCにもバックアップをダウンロード。さらに、データベースもエクスポートしてから作業に入りました。
ConoHa WINGではWebデータやデータベースの自動バックアップが取得されていますが、データベースマイグレーションを実行すると、その自動バックアップは移行先へ引き継がれません。
そのため、サーバー側の自動バックアップだけに頼らず、Webデータとデータベースを自分のPCにも保存しておく必要があります。
ConoHa WINGサポート｜データベースマイグレーションについて
移行前に行った準備は、主に次の通りです。
- WordPress本体・テーマ・プラグインの状態を確認する
- 使っていないテーマやプラグインを整理する
- バックアップを作成する
- WebデータをPCにも保存する
- データベースをエクスポートしてPCに保存する
wp-config.phpを編集する可能性があることを確認する
MySQLの移行前には、必ず自分でバックアップを取ってください。ConoHa WINGの自動バックアップは移行先へ引き継がれないため、WordPress本体・テーマ・プラグイン・アップロード画像などのWebデータと、データベースの両方を手元に保存してから作業します。
MySQL 5.7から8.4への移行フロー
ここからは、ConoHa WINGの管理画面で実際に行った流れです。画面表示や文言は、作業当時のものです。
ConoHa WINGの管理画面から、サーバー管理へ進みます。
その中にあるデータベースマイグレーションから「マイグレーション」を選びました。
最初の画面では、案内に従って「次へ」をクリックします。
次の画面で「開始」ボタンを押すと、データベースの移行が始まります。
画面には、「このデータベースでデータ移行を実行します。移行中のサーバーへの情報更新は反映されません。よろしいでしょうか？」という内容の確認が表示されました。
ここは軽く流さない方がいいです。
移行中の更新は反映されないと案内されているため、開始後は記事の更新、設定変更、プラグイン更新などを行わず、完了するまで待ちます。
最初は残り時間が約5分と表示されました。
ただ、99%まで進んだところで、残り時間が0分から5分に戻るような表示もありました。
この段階で自分にできることは、余計な操作をせずに待つことです。焦って画面を閉じたり、別の作業を始めたりしない方が安全です。
移行が進むと、wp-config.php の内容を修正するよう案内が表示されます。
ここで少し迷いやすかったのが、ファイルマネージャーの開き方です。
別のタブでConoHaへログインし直しても、再び同じ移行画面が表示されることがありました。
自分の場合は、確認手順の項目に表示されている「ファイルマネージャー」をクリックすると、別タブでファイルマネージャーを開けました。
次に確認するのは、移行先として表示されている新しいデータベースホスト名です。
ConoHa WINGの画面に表示されている移行先のホスト名を確認し、wp-config.php 内の DB_HOST を新しいホスト名へ書き換えます。
wp-config.php はWordPressの重要な設定ファイルです。変更するのはホスト名の部分だけです。余分な記号を消したり、必要な引用符まで削除したりしないように注意します。
ファイルマネージャーで wp-config.php を開きます。
自分の環境では、ファイル編集をACE Editorで開きました。
画面を開くと、比較的上の方にデータベース接続に関する設定が並んでいます。
その中にある DB_HOST の値を、新しいデータベースホスト名へ変更します。
前の画面に表示されていた、今まで使用していたデータベースホスト名がここに入っているはずです。
そこを、新しいデータベースホスト名だけに置き換えます。
修正後は保存して、サイトの表示とWordPress管理画面を確認しました。
表示崩れやデータベース接続エラーが出ていないことを確認してから、移行画面に戻ります。
問い合わせフォームや会員機能など、サイトで重要な機能を使用している場合は、この段階で動作も確認します。
MySQL 8.4への移行を完了すると、元のデータベースバージョンへ戻すことはできません。動作確認で問題が見つかった場合は移行を完了させず、wp-config.php の DB_HOST を移行元のホスト名へ戻してから、マイグレーションをキャンセルします。
確認が終わり、移行先のデータベースで問題なく動いていると判断できたら、移行画面に表示されている「事前確認を完了した」にチェックを入れ、「次へ」をクリックします。
ここまで進むと、移行作業はほぼ完了に近づいています。
ただし、自分の場合は、作業中に画面をしばらく開いたままにしていると、タイムアウトエラーの表示が出ました。
そのときは、画面を更新すると次の画面へ進める状態になりました。
同じような表示が出た場合でも、すぐに失敗と決めつけず、画面更新後に移行状況を確認してください。
最終的に、サイトの表示と管理画面を確認し、問題なく動いていることを確認できました。
まとめ｜MySQL 5.7から8.4へ移行して感じたこと
MySQL 5.7からMySQL 8.4へ移行したあと、念のためPageSpeed Insightsでも確認しました。
ミコトホドの環境では、スコアに大きな変動は見られませんでした。
少なくとも、自分の環境では「MySQL 8.4へ移行しただけでPageSpeed Insightsの数値が大きく上がる」という結果にはなっていません。
ただ、今回の移行で大きかったのは速度ではありません。
古いMySQL 5.7環境から、ConoHa WING側で用意されたMySQL 8.4環境へ移れたことです。
体感速度が大きく変わらなくても、データベース環境についてはWordPressの推奨条件を満たす状態にできたため、運用面の不安は減りました。
MySQLの移行は、テーマの変更やプラグインの追加よりも慎重に扱う作業です。
特に、wp-config.php の修正が必要になる場面では、変更する場所を間違えないように注意が必要です。
また、ConoHa WINGの自動バックアップは移行先へ引き継がれず、移行完了後は元のデータベースバージョンへ戻せません。手元へのバックアップと、完了前の動作確認は省略できない作業です。
それでも、ConoHa WINGの管理画面に沿って進めれば、作業の流れ自体は分かりやすいものでした。
ConoHa WINGでMySQL 5.7の環境が残っていて、8.4への移行に不安がある方にとって、この記録が確認材料のひとつになればと思います。
補足：移行当時に動作確認したプラグイン一覧
以下は、MySQL 8.4への移行後、ミコトホドで動作確認したプラグインです。
同じプラグイン名でも、バージョンやサイト環境によって結果は変わります。あくまで、ミコトホドで確認した当時の記録として残します。
- AddToAny Share Buttons (v.1.8.17)
- Ad Inserter (v.2.8.13)
- Category Order and Taxonomy Terms Order (v.1.9.5)
- Contact Form 7 (v.6.1.5)
- Highlighting Code Block (v.2.1.3)
- IP Location Block (v.1.3.8)
- SEO SIMPLE PACK (v.3.6.3)
- SiteGuard WP Plugin (v.1.7.11)
- UpdraftPlus – Backup/Restore (v.1.26.2)
- WP Mail SMTP (v.4.8.0)
- WP Multibyte Patch (v.2.9.3)
- XML Sitemap Generator for Google (v.4.1.23)
補足：移行当時に動作確認したテーマ
SWELL (v.2.16)
コメント