【デジタル】Xserver上に設置したWPでMariaDBの更新を手動で実行した話
WordPressでブログやWebサイトを運用していると、日常のアップデートやプラグインの管理画面でダッシュボードで目にする「警告（アラート）メッセージ」。普段は通り過ぎてしまうような通知でも、インフラやセキュリティの観点から紐解いていくと、重要なシステムのアップグレードが必要な合図であることが少なくないです。僕は元々マーケティングコミュニケーションを主務にしていたのですが、最近は本業で「ITアーキテクト」兼「セキュリティ担当」みたいな感じになっていて。視点がわかってきたったのもあるのかもなーなどと。今までなら、ちょっと「見なかったことにしよう」という部分にいち早く気づくようになってきたというのがあるかなーと思います。
今回「新しい記事でも書くかなー」と思ってログインしたら、アクセス解析プラグイン「Matomo Analytics」のデータベースに関する警告が検出されていることに気づきました。
発生した現象とアラート内容
Matomoの管理画面トップ、およびシステムレポート（Matomo Diagnostics）に表示されたのは以下の警告メッセージです。
警告メッセージ（要約） 「Heads up! Matomo Analytics version 6 and later will require a newer server environment… MariaDB 10.6 or higher is required (you are currently using MariaDB 10.5.22).」 （意訳：Matomo Analytics バージョン6以降ではより新しいサーバー環境が必要です。MariaDB 10.6以上が必須ですが、現在はMariaDB 10.5.22が使用されています）
Gemini先生に「変えた方がいいよね？」って相談した時に指摘されたので、WordPressの「サイトヘルス」を確認した際にも、同様に「古いデータベースサーバー：パフォーマンスとセキュリティのため MariaDB バージョン 10.6 以上の使用を検討してください」という推奨アラートが検出されていました。「ということは、これってmatomoだけの話じゃなくてWP全体の話やん！」ってなりました。
気にしなかったら、次世代バージョンへのアップデートにおいて、ミドルウェアであるデータベース（RDBMS）の最小要求スペックを満たさなくなるところでした。。。
危なすぎる( ・∇・)
【基礎知識】なぜMySQL設定なのにMariaDBなのか？
「そもそも自分のWordPressはMySQLを使っているはずでは……？」
今回の警告を見たとき、最初に頭に浮かんだのがこの疑問でした（まぁ、そもそもちゃんと確認してなかったけどずっとそうだった記憶なので）。
エックスサーバーの管理画面（サーバーパネル）を見ても、メニューには「MySQL設定」と書かれていて。それなのに、なぜMatomoやWordPressからは「MariaDBのバージョンが古いで！」と怒られるのかと_:(´ཀ`」 ∠):。
ここには、RDBMS（関係データベース管理システム）の歴史と、レンタルサーバー側のインフラ事情という、ちょっと面白い裏話があるのです。
MySQLとMariaDBの関係性：分裂の歴史と「兄弟」の誕生
結論から言うと、MariaDBは「MySQLの設計図（ソースコード）をもとに作られた、完全互換の上位互換プロダクト」です。もともと世界中で愛用されていたオープンソースDBの「MySQL」ですが、企業買収の波を経て、最終的に巨大IT企業であるOracle（オラクル）社の所有となりました。こういうの、多いですよね。。。
このとき、「巨大企業の所有になると、将来的に有料化されたり自由な開発が制限されたりするのではないか？」と危機感を抱いたのが、MySQLの生みの親（開発者）であるミカエル・ヴァデニウス氏でした。エンジニア、それも生みの親からすると「いろいろ思想が変わると、本来目指していたことと変わりそうだなぁ」ってのがあったんでしょうね。
彼が「誰もが永遠に自由に使えて、ベンダーロックインされない完全なオープンソースのデータベースを残す」という意志のもと、MySQLから分岐（フォーク）して立ち上げたのが MariaDB です。そのため、コマンドやデータの構造、WordPressとの接続方式などはMySQLと100%の互換性を維持しながら開発が進められています。
生みの親であるエンジニアが率いているからこそできる、素敵な進化ですよね。
なぜサーバー会社はMariaDBを採用するのか？
エックスサーバーをはじめ、多くのホスティング事業者がMySQLからMariaDBへ内部的に移行しているのには、明確なメリットがあるからです。
- ライセンスの安心感と自由度：特定の巨大企業の意向に左右されない完全オープンソースであること。これ、結構重要なんですよね。大企業に吸収されて「ええー！？」ってことになった技術は数知れずなので。。。
- 圧倒的なパフォーマンス：特に複雑な検索（SELECT）や、今回のMatomoのように大量のログを同時に高速処理（INSERT）する際の最適化ロジックがMySQLより優れていること。開発のスピード感があるのも、オープンソースの強みだったりしますよね。
- 互換性の高さ：WordPress側のプログラムを一切書き換えることなく、裏側のエンジンだけを差し替えられること。
つまり、サーバー会社からすると「ユーザーのWordPress環境をそのままに、より高速で安全なデータベースを提供できる」という大きなメリットがあるというね。
エックスサーバーのDB仕様について
ここで最初の疑問に戻ります。
エックスサーバーの管理画面で「MySQL設定」と表記されているのは、ユーザーに馴染みのある名称をそのまま使っている（またはMySQL互換機能としてのUI名）からに過ぎないかなと（多分）。実際の裏側（ミドルウェアの実体）では、しっかりとパフォーマンスに優れた MariaDB が稼働していた、というのが今回のおはなし。
現象面としては、サーバーの契約時期や収容されているサーバー番号（svXXXX）の違いによって、内部で動いているMariaDBのバージョンが異なっているというはなしで。
- 旧環境（以前から利用しているサーバー）：MariaDB 10.5.x系 が稼働中
- 新環境（近年の新規・新サーバー環境）：MariaDB 10.11.x系 が標準稼働
僕の環境はまさに旧環境の「MariaDB 10.5.22」だったため、今回のMatomo v6やWordPressの「10.6以上推奨」というラインに引っかかってしまった、というわけ。
ということで、「じゃあ最新のMariaDB 10.11環境に持っていけば全部解決やん！」ということで、アプローチ方法の模索となりました。
事前調査：エックスサーバーのアナウンスと移行方針の策定
「 MariaDB 10.11 の環境に持っていきたいけれど、エックスサーバーって自分側でデータベースのバージョンだけをポチッと上げられるのかね？」そう疑問に思って調べ始めたところ、エックスサーバーの公式サイトでまさにドンピシャのアナウンスを発見しました。
すでにご利用中のサーバーへの対応について
2024年6月5日11:00 以降に発行されたサーバーアカウントにつきましては、2026年6月以降、順次、弊社にて MariaDB 10.11 への更新を実施予定です。
なお、MariaDB 10.5 以前の環境につきましても、引き続き安定してご利用いただけるよう、弊社にて必要な保守対応を継続してまいります。
MariaDB 10.11 対応サーバーの利用をご希望の場合
MariaDB 10.11 に対応したサーバー環境へ移行可能な、「新サーバー簡単移行」機能をご利用ください。
公式アナウンスの読み解きと「放置リスク」
この案内のポイントは以下の3点。
- 新環境はすでに MariaDB 10.11 になっている
- 既存環境も順次アップデート予定だが、何気にすでに２ヶ月経って未だに反映されてない（2026年6月以降〜）
- 旧環境（10.5）のまま放置しても保守はされるが、ミドルウェアのバージョン自体は上がらない
つまり、運営側で放置していても今すぐ環境が壊れるわけではありません。しかし、そのまま待っていると「Matomoのバージョン6以降への更新が止まる」「WordPressのサイトヘルスでずっと警告が出続ける」という状態がいつまで続くかよくわからない状態が続くことになるかなと。「既知の要件未達を把握していながら、いつ来るか分からない自動更新を長期間待つのはちょっとなー」と。
「自動更新待ち」vs「セルフ移行（新サーバー簡単移行）」の比較
| 比較項目 | 自動更新（放置） | 新サーバー簡単移行（セルフ移行） |
| 実施時期 | 運営側のスケジュール（数ヶ月〜年単位で待つ） | 今すぐ（自分のタイミングで実行可能） |
| 作業工数 | ゼロ（何もしなくていい） | 画面操作数クリック（データコピー＆切り替え） |
| ミドルウェア | MariaDB 10.5 のまま据え置き | MariaDB 10.11 (LTS) へ一気に無償アップグレード |
| 警告の解消 | しばらく解消されない | 即座に問題解決 |
エックスサーバーには、ボタン操作だけで最新サーバー環境へデータを丸ごとコピーしてくれる「新サーバー簡単移行」という機能が用意されています。
前にも、それやった頃があって。
「待ち」を選ぶ理由は特にないと思うので、「移行申請を出して、サクッと最新環境へ引っ越しで正解かな」という判断としました。
移行前に押さえておくべきリスクと注意点
とはいえ、データベースを含むサーバー移行です。ノーリスクというわけでもなく。作業前に以下の注意点（制約事項）を頭叩き込んでおく必要がありました。
- アクセスログ（Matomo等）の差分発生リスク
- サーバー切り替えまでの間に発生したアクセスログは、旧サーバーのDBに書き込まれるため、移行先に反映されない可能性あり。
- DNS浸透までのタイムラグ
- 「サーバー切り替え」ボタンを押してから、新サーバーへ切り替わるまでに数十分〜24時間程度の浸透待ち（DNSキャッシュ）が発生する。
まぁ、実際にその際にサイトを更新するとかそういうのはそもそも出来ないので、気をつけるのは「その間はログは残らない」ということだけ留意しつつ実践作業へ移ることにしました。
【実践手順】「新サーバー簡単移行」の実行と問題解決までのフロー
方針が決まれば、あとは作業を進めるのみということで。エックスサーバーの「新サーバー簡単移行」はかなりシンプルで、実際の操作自体はらくちん（むしろ、これでいいのか？と不安になるレベル）。ここからは、ボタンを押してからDBが最新化されるまでの手順とタイムラインをまとめていきます。
Step 1：データコピー申請（旧サーバー ➔ 新サーバー）
まずはエックスサーバーのサーバーパネルにログインし、「新サーバー簡単移行」の画面を開きます。 画面に表示されている「データコピー申請」のボタンを押すだけで、ステップ1がスタート！
ステータスが「データコピー中（sv16268 ※サーバー名はそれぞれです ➔ 未定）」に切り替わり、旧サーバー内のデータ（WordPress本体、画像ファイル、MariaDB 10.5のデータベースなど）が最新のサーバー環境へ裏側でコピーされ始めます。進捗バーとかは出ないので、ちょっと不安になるけど待つしかない感じで。
- 処理時間：サイトのファイル容量やDBサイズによりますが、バックグラウンドで処理が進み、完了するとメールで通知が届く感じです。
- 注意点：この間、ブログ自体は旧サーバーで通常通り稼働していますが、差分が発生しないよう記事の更新や大きな設定変更は控えて待機（ここ、重要！）。
Step 2：データコピー完了と「サーバー切り替え」の実行
データコピーが完了すると、管理画面のステータスが「データコピー完了」に変わり、「サーバー切り替え」ボタンが有効化されます。
本来であれば、ここで移行先のテストURLやHostsファイルを書き換えて「新環境でWordPressが正常に表示されるか」を動作確認するプロセスを挟むことができます。ただ、正直Hostsとかめんどくさいのでやりたくないのでパスw。というか、今回はデータベースのマイナーバージョンアップが主目的であり、システム構成もシンプルなので、そのまま「サーバー切り替えをする」を実行しました。事業サイトであれば、このへんのチェックは入念にやって欲しいところです。
「サーバー切り替えをする」ボタンを押すとローディングアイコンがぐるぐる回り、エックスサーバー側でDNSレコードの書き換え処理（ドメインの接続先を旧サーバーから新サーバーへ切り替える処理）が始まります。いや、マジで楽ちん。結構、このDNSレコード書き換えが手間だったりしますからね。自分で、TTLとか設定できるので、詳しい人はその方がよきなんだけど、まーそこは楽をする感じで。
Step 3：DNS浸透待ち（実測約30分）とローカルキャッシュの挙動
切り替えボタンを押した直後は、世界中のDNSサーバーやPC・スマホ側に「旧サーバーのIPアドレス（キャッシュ）」が残っているため、すぐには新環境にアクセスできず。この辺は、このてのWEB作業に慣れている方ならよくご存知の話だとは思いますが。
公式アナウンスでは「最大24時間程度かかる」とされていますが、今回の実測タイムラインは以下の通りでした。
- 切り替えボタン押下（12:55頃）
- DNS浸透・反映確認（13:25頃） ➔ 実質約30分！
なお、切り替え直後にブラウザのシークレットウィンドウやキャッシュクリアを試しても旧環境に繋がってしまうことがありますが、これはPCやご自宅のルーター側に旧IPのDNSキャッシュが強く残っているためです。 特に、汎用リゾルバのキャッシュは手元リセットができないので待つしかない感じでして。手早く確認したい場合は、スマホのWi-FiをOFFにしてモバイル回線（4G/5G）からアクセスしてみると、一足早く新サーバーへ繋がっていることを確認できたりすることもあるかなーと思いますが、そんなに変わらんと思うので待つという洗濯でいいかなって思います。
成果の検証：両ダッシュボードが「オールグリーン」に！
切り替えから約30分後、WordPressの管理画面に再ログインして各ダッシュボードをチェックしてみると、すべての警告がちゃんと消え去っていました！よかった( ´∀｀)
① Matomo Diagnostics（システムレポート）のビフォーアフター
- 画面トップのアラート：「MariaDB 10.6以上が必要です」という警告枠が消滅。
② WordPress「サイトヘルス」の確認
- ステータス：「古いデータベースサーバー（MariaDB 10.6以上が必要）」の推奨警告が解消され、健全な状態に復帰。
エックスサーバーの「MySQL設定」画面を開いてみても、データベースのヘッダーに MariaDB10.11 と表示されており、無事に最新LTS環境への引っ越しが完了したことが確認できました。
MariaDB 10.5 ➔ 10.11（LTS）の技術的メリット
さて、ここで閑話休題。無事に警告が消えて「めでたしめでたし」で終わらせても良いのですが、せっかくの機会なので、「今回のミドルウェア更新（10.5 ➔ 10.11）によってシステム的に何が得られたのか？」を把握しておきたいところです。
実は、MariaDB 10.5から10.11への移行は、単なる小規模なマイナーアップデートではなく、間にある複数のマイナーバージョン（10.6〜10.10）の改善を一気に取り込む実質6世代分のジャンプアップです（結果的に、そうなった感は否めませんが）。
そもそも論なんですが、MariaDB 10.5は公式サポートが2025年6月24日に終了していという話なので、そこも含めてサクッとやっとかなきゃという話であったりね（詳しくは、下記リンク先を確認して見てください）。
【2026年7月版】MariaDBのバージョン情報とサポート期限
今回のバージョンアップで特に押さえておきたい技術的メリットは以下の3点。
① 10.11（LTS：長期サポート版）に載ることの重要性
MariaDB 10.11は、LTS（Long Term Support）と呼ばれる長期サポートバージョンに指定されています。 LTS環境に載せることで「今後数年間にわたって既知の脆弱性パッチ（CVE対応）や不具合修正が手厚く提供され続ける」という絶大な安心感が得られます（ここ重要）。インフラのライフサイクル管理において、最も手堅い選択肢ですし、もしシステム管理やセキュリティ業務に関わっているようでしたら、この辺ちゃんと注意しておくべきポイントだったりします。
② InnoDBロックの削減による書き込み性能の向上（Matomoに最適）
MariaDB 10.6以降、内部のストレージエンジンであるInnoDBのコンテンション（ロック競合）が大幅に削減されました。 これは特にMatomoのようなアクセス解析プラグインにおいて威力を発揮します。「バックグラウンドで大量のアクセスログ（INSERT）を書き込みながら、同時にダッシュボードで重い集計（SELECT）を走らせる」という高負荷な状況でも、データベースが詰まりにくく、Web全体のレスポンス低下を防ぐことができます。あの時計の「くるくる」が激減するという話です。
③ クエリ最適化・メモリ管理・日時処理の精密化
- メモリ効率の改善：複雑な検索や集計処理を実行した際、サーバーのRAMを無駄遣いせず動的に効率良く処理できるよう最適化。
- TIMESTAMP（時間軸）処理の高速化：タイムゾーン変換やアクセスログの集計処理がマイクロ秒単位で高速化され、リアルタイムレポートの描画スピード向上に貢献。
見た目の警告が消えただけでなく、「ブログ全体のデータベース応答速度が上がり、高負荷にも耐えうる堅牢な土台が整った」というのが、今回得られた真のメリットと言えます。結構みんなせっかちになっているので、できるだけ早く表示された方がいいですもんね。この辺が、すごく大事だと思います。
まとめ：見えないインフラを点検・整備することの大切さ
今回の件は、元々はプラグインのダッシュボードに表示されたまーまー派手で目立つ「ひとつのアラート」から始まりました。
マーケティング主務だった頃の自分なら、「まあ動いているし大丈夫か」と見過ごしていたかもしれません。しかし、インフラやセキュリティの視点を持つようになってから、「アプリケーション（WordPress）の裏で動いているミドルウェア（RDBMS）の状態に目を向けること」の重要性を強く実感しています。
本来、前から目を向けておくべきだったことに視点が広がったという意味でも、今やっている仕事は自分の視野もいろげてくれてよかったなぁなんて思っていたりもします。
Webサイトやブログは、表面上のコンテンツを更新するだけでなく、それらを支えるサーバー環境やデータベースを定期的に点検し、最新・最適な状態に保ってこそ、安全かつ快適に運用し続けることができると考えます。爆速になると、離脱率も下がるし、チェックする時もさくさく動かないとストレス溜まるというのもね。
スピード感、大事！！
というわけで、最後に、今回の移行作業におけるチェックポイントをリストとしてまとめておこうと思います。備忘録も兼ねて。証跡大事！！
移行作業のチェックリスト一覧
- 現状の把握：Matomo診断レポートやWP「サイトヘルス」でDB要件を確認
- 事前調査：ホスティング会社のアナウンスを確認し、セルフ移行機能の有無を調べる
- 制約事項の確認：作業期間中のブログ更新停止、ログ差分のリスクを理解しておく
- データコピー実行：管理画面から申請し、完了通知を待つ（ブログは通常稼働）
- サーバー切り替え：DNS書き換えを実行し、浸透（実測30分程度）を待つ
- キャッシュ対策：反映待ちの際はスマホのモバイル回線（4G/5G）などで別経路確認
- 最終検証：両方のダッシュボードでバージョン表記と警告消滅（オールグリーン）を確認
もし、ご自身のWordPressやMatomoで「DBが古い」という警告が出ている方がいれば、ぜひ一度お使いのサーバー環境（エックスサーバー等）の移行機能をチェックしてみてください。これ、そんなに手間かからないのでやった方がいいと思います。
あと、サイトヘルスは少なくともちゃんと読み込みつつ、アラートは今の時代AIもあるし細かい部分はリンク先を確認してサイトをチェックして必要性を確認した上でアップデートはこまめに実行がいいかなーと思います( ・∇・)
また、今回も長文になってしまった。。。。。
