KUSANAGIのMariaDBを10.6から10.11へ！バックアップからアップグレードまで完全解説

はじめに：WordPressに「データベースを新しくしてね」と言われた

ConoHa VPS（KUSANAGI）でWordPressサイトを4つ動かしているのですが、WordPressの管理画面にある「サイトヘルス」を見たところ、こんなお知らせが出ていました。

「データベース（MariaDB）のバージョンを10.11以上にすることをおすすめします」

今のバージョンはMariaDB 10.6。まだ動いてはいるけれど、古くなってきているので新しくしたほうがいいよ、ということです。

そこで今回、MariaDB 10.6.25 → 10.11.18へのアップグレードに挑戦しました。

結論から言うと、準備をしっかりやれば、作業そのものはコマンド1行＋質問2つに答えるだけでした。ただ、深夜の作業で途中SSHが切れたりもしたので、そのあたりも含めて全部書いておきます。

この記事は、小学生でもわかるくらいていねいに説明しているので、「サーバーってちょっとこわい…」という人もぜひ読んでみてください。

そもそもMariaDB（マリアディービー）って何？

WordPressのサイトは、大きく分けて2つのものでできています。

つまりMariaDBは、ブログの記事や設定をしまっておく「大事なノート」のようなものです。

今回やるのは、このノートを入れておく「本棚」を新しいモデルに入れかえる作業です。ノートの中身（記事）はそのまま、本棚だけ新しくするイメージですね。

ただし、本棚の入れかえ中に何かあったら大変なので、入れかえる前にノートのコピーを何重にも取っておくのが今回のいちばん大事なポイントです。

今回の環境

作業の全体の流れ

最初に全体の流れを見ておきましょう。実際にかかった時間も書いておきます。

全部で1時間ちょっとでした。そのうち半分以上は、ConoHaのイメージ保存を待っている時間です。

本番のアップグレードそのものは、たったの3分ほど。準備のほうがずっと長いんです。

ステップ1：今の状態を確認する

まずはWindowsのPowerShellから、SSHでサーバーにログインします。

ssh -p （SSHのポート番号） root@（サーバーのIPアドレス）

ログインできたら、今の状態を1つずつ確認していきます。

MariaDBのバージョンを確認

mysql --version

結果はこうでした。

mysql  Ver 15.1 Distrib 10.6.25-MariaDB, for Linux (x86_64) using  EditLine wrapper

10.6.25であることが確認できました。

ディスクの空きを確認

バックアップやイメージ保存をするので、ディスク（保存場所）に余裕があるかも見ておきます。

df -h /

ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/vda2        99G   13G   82G   14% /

残り82GBなので余裕たっぷりです。

アップグレードコマンドの書き方を確認

ここが大事なポイントです。KUSANAGIのコマンドはバージョンによって書き方がちがうことがあるので、ネットの情報をそのまま打たずに、まずヘルプで確認します。

kusanagi upgrade --help

upgrade sub-commands:
  {mariadb,psql,kusanagi}
    mariadb             upgrade MariaDB
    psql                upgrade PostgreSQL
    kusanagi            upgrade KUSANAGI edition

「mariadb」というサブコマンドがあるので、さらにその中身も確認します。

kusanagi upgrade mariadb --help

usage: kusanagi upgrade mariadb [-h] --use {mariadb10.5,mariadb10.6,mariadb10.11,mariadb11.4,mariadb11.8,mariadb12.3}
                                [--force]

これで、「–use mariadb10.11」のようにバージョンを指定すればいいことがわかりました。

11.4や12.3という新しいバージョンも選べますが、今回は10.11を選びました。理由は、

• 10.6からの「ひとつ上の段」なので、トラブルが少ない
• WordPressのおすすめ（10.11以上）をちゃんと満たせる

からです。階段は一段ずつが安全です。

ステップ2：cron（自動で動く予約）を一時停止する

cron（クーロン）というのは、「毎日3時にこれをやってね」のように、サーバーに自動でお仕事を予約しておく仕組みです。目覚まし時計みたいなものですね。

まず、どんな予約が入っているか見てみます。

crontab -l

0 * * * * curl -s https://（サイトのURL）/wp-cron.php?doing_wp_cron > /dev/null 2>&1

0 3 * * * /root/scripts/wp-backup.sh

2つ入っていました。

作業を始めたのは夜中の2時すぎ。このままだと、アップグレードの最中に3時のバックアップが動いて、データベースをさわりに来てしまうかもしれません。

本棚を入れかえている最中に、誰かがノートを取りに来たら困りますよね。なので、作業中だけ目覚まし時計を止めておきます。

ちょっと寄り道：SSHが切れた！

ここで実際にあったハプニングです。確認作業をしている間に、画面にこんな文字が出ました。

client_loop: send disconnect: Connection reset

これは「サーバーとの接続が切れました」という意味です。しばらく操作しなかったので、自動で切られてしまったようです。

気づかずにそのままコマンドを打ったら、サーバーではなく自分のパソコン（PowerShell）でコマンドが実行されてしまい、赤い文字のエラーがずらっと出ました。

このときは何も変更されていないので大丈夫でしたが、アップグレードの最中に切れたら大変です。そこで、切れにくくするオプションをつけて入り直しました。

ssh -o ServerAliveInterval=30 -p （SSHのポート番号） root@（サーバーのIPアドレス）

「ServerAliveInterval=30」は、30秒ごとにサーバーへ「まだいるよー」と声をかけ続けるオプションです。これで放置による切断を防げます。

コマンドを打つ前に、画面の左はしが「[root@サーバー名 ~]#」になっているか確認するクセをつけておくと安心です。「PS C:\Users\…>」になっていたら、それはパソコン側です。

cronの予約を保存してから止める

まず、今の予約をファイルにコピーして取っておきます（あとで元に戻すため）。

crontab -l > /root/crontab.bak

ちゃんとコピーできたか確認します。

cat /root/crontab.bak

さっきと同じ2行が出ればOKです。確認できたら、予約を空っぽにします。

crontab -r

止まったか確認します。

crontab -l

no crontab for root

「no crontab for root」（予約はありません）と出たら、停止完了です。

ステップ3：手動でバックアップを取る

いつも毎日3時に動いているバックアップのスクリプトを、今ここで手で動かします。

/root/scripts/wp-backup.sh

終わったら、バックアップができているか確認します。

ls -lt /root/backups/ | head -20

-rw-r--r--. 1 root root 1524  9月 23 02:22 backup.log
drwxr-xr-x. 2 root root 4096  9月 23 02:22 site4
drwxr-xr-x. 2 root root 4096  9月 23 02:20 site3
drwxr-xr-x. 2 root root 4096  9月 23 02:20 site2
drwxr-xr-x. 2 root root 4096  9月 23 02:19 site1

4サイトとも今日の日付で更新されています。念のため、ログにエラーがないかも見ます。

tail -20 /root/backups/backup.log

[2026-09-23 02:19:59] ===== バックアップ開始 =====
[2026-09-23 02:19:59] [site1] DB OK (（DB名）)
[2026-09-23 02:20:08] [site1] ファイル OK
[2026-09-23 02:20:12] [site2] DB OK (（DB名）)
[2026-09-23 02:20:56] [site2] ファイル OK
[2026-09-23 02:20:57] [site3] DB OK (（DB名）)
[2026-09-23 02:22:10] [site3] ファイル OK
[2026-09-23 02:22:12] [site4] DB OK (（DB名）)
[2026-09-23 02:22:51] [site4] ファイル OK
[2026-09-23 02:22:51] ===== バックアップ終了 =====

全部OKです。

バックアップファイルが壊れていないかチェック

1つのサイトだけ、ファイルのバックアップが前の日より小さくなっていたので、中身が壊れていないかを調べるコマンドも使いました。

tar -tzf /root/backups/site1/site1_2026-09-23_files.tar.gz > /dev/null && echo "TAR OK"

TAR OK

これは「箱（圧縮ファイル）を開けずに、中身のリストを最後まで読めるか試す」コマンドです。最後まで読めたら「TAR OK」と表示されます。

結果はOK。記事が5つくらいのテスト用サイトだったので、キャッシュが減っただけでした。サイズが急に変わったら、とりあえず壊れていないか確かめるのは良い習慣です。

ステップ4：サーバーを止めて、ConoHaでイメージ保存

ここが最強の保険です。

「イメージ保存」とは、サーバーのディスクを丸ごとコピーして写真を撮っておくようなものです。中には、

• データベース（4サイトの記事や設定）
• WordPress本体・テーマ・プラグイン・画像
• nginxやPHP、MariaDB、SSHなどの設定ファイル
• OSやKUSANAGI本体
• さっき取ったバックアップファイル

が全部入ります。万が一アップグレードで失敗しても、この写真の時点にサーバーを丸ごと戻せます。

サーバーを停止する

イメージ保存は、サーバーが止まっていないとできません。SSHで次のコマンドを打ちます。

shutdown -h now

接続が切れてPowerShellに戻りますが、これは正常です。ここからしばらく、サイトは見られなくなります。アクセスの少ない深夜にやったのはそのためです。

ConoHaのコントロールパネルで、サーバーのステータスが「停止」になっているのを確認します。

イメージを保存する

1. サーバーリストから、自分のサーバーのネームタグをクリック
2. 画面上のボタンから「イメージ保存」をクリック
3. わかりやすい名前をつける（今回は before-mariadb1011-20260923）
4. 実行する

「成功しました。イメージ保存」と表示されます。ただし、これは「受付完了」の意味で、実際のコピーはここから始まります。

保存が終わるまで待つ

左メニューの「イメージ」を開いて、ステータスを確認します。

「利用可能」になるまでは、絶対にサーバーを起動しないこと。コピーの途中でサーバーを動かすと、中身が書きかわって、中途半端なコピーになってしまうおそれがあるからです。

今回は約35分で「利用可能」になりました。容量は12.1GBでした。

ステップ5：サーバーを起動して、設定ファイルを控える

イメージ保存が終わったら、コントロールパネルからサーバーを「起動」します。ステータスが「起動中」になり、サイトが見られるようになったらOKです。

もう一度SSHでログインして、MariaDBが動いているか確認します。

systemctl status mariadb --no-pager | head -5

● mariadb.service - MariaDB 10.6.25 database server
     Active: active (running) since Wed 2026-09-23 03:09:14 JST; 2min 7s ago

「active (running)」（元気に動いています）なのでOKです。

MariaDBの設定ファイルを控えておく

このサーバーはメモリ1GBの小さいプランなので、前にMariaDBが使うメモリを少なめにする設定をしていました。アップグレードでこの設定が上書きされたら困るので、設定ファイルだけ別の場所にコピーしておきます。

mkdir -p /root/mariadb-conf-backup && cp -a /etc/my.cnf /etc/my.cnf.d /root/mariadb-conf-backup/

コピーできたか確認します。

ls -R /root/mariadb-conf-backup/

/root/mariadb-conf-backup/:
my.cnf  my.cnf.d

/root/mariadb-conf-backup/my.cnf.d:
client.cnf  enable_encryption.preset  mysql-clients.cnf  server.cnf  spider.cnf

今の設定の値をメモしておく

アップグレードのあとで「同じままか」比べるために、大事な設定の値を表示しておきます。

grep -rn "buffer_pool\|max_connections" /etc/my.cnf /etc/my.cnf.d/

/etc/my.cnf.d/server.cnf:14:max_connections = 900
/etc/my.cnf.d/server.cnf:33:innodb_buffer_pool_size = 128M
/etc/my.cnf.d/server.cnf:80:innodb_buffer_pool_size=64M

「innodb_buffer_pool_size」が2か所にありますが、設定ファイルはあとに書いたほうが勝つので、実際に使われているのは80行目の64Mです。

ステップ6：いよいよMariaDBをアップグレード

準備はすべて完了！いよいよ本番です。コマンドはこれ1行だけです。

kusanagi upgrade mariadb --use mariadb10.11

実行すると、英語で2つ質問されます。

質問1：アップグレードの注意事項を確認しましたか？

Did you check MariaDB upgrade instructions? [y/n]

「注意事項をちゃんと読んで、準備しましたか？」という念押しです。バックアップもイメージ保存も済んでいるので、y（はい）を入力してEnter。

質問2：Galeraクラスタを使っていますか？

Is this server using Galera cluster? [y/n]

Galera（ガレラ）クラスタとは、何台ものデータベースサーバーをつなげて一緒に動かす仕組みです。今回はVPS1台で普通に動かしているだけなので、n（いいえ）を入力してEnter。

あとは待つだけ

文字がどんどん流れていきます。途中でこんな表示が出ました。

Installed:
  MariaDB-client-10.11.18-1.el9.x86_64
  MariaDB-common-10.11.18-1.el9.x86_64
  MariaDB-server-10.11.18-1.el9.x86_64
  ...
Complete!
Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service -> /usr/lib/systemd/system/mariadb.service.
Major version upgrade detected from 10.6.25-MariaDB to 10.11.18-MariaDB. Check required!
Phase 1/8: Checking and upgrading mysql database

「Created symlink」の行は赤い文字で出ますが、これはエラーではなく「自動で起動する設定をしました」というお知らせなので安心してください。

「Major version upgrade detected … Check required!」は、「大きくバージョンが上がったので、ノート（テーブル）を全部チェックしますね」という意味です。ここから自動で全部のテーブルが検査されて、ずらっと「OK」が並びます。

（DB名）.wp_posts                                OK
（DB名）.wp_postmeta                             OK
（DB名）.wp_options                              OK
...
Phase 7/8: uninstalling plugins
Phase 8/8: Running 'FLUSH PRIVILEGES'
OK
upgrade completed.

最後に「upgrade completed.」と出たら、アップグレード成功です！ここまで約3分でした。

ステップ7：動作確認

バージョンを確認

mysql --version

mysql  Ver 15.1 Distrib 10.11.18-MariaDB, for Linux (x86_64) using  EditLine wrapper

10.11.18になりました！

ちゃんと動いているか確認

systemctl status mariadb --no-pager | head -5

● mariadb.service - MariaDB 10.11.18 database server
     Active: active (running) since Wed 2026-09-23 03:16:28 JST; 2min 5s ago

設定が消えていないか確認

grep -rn "buffer_pool\|max_connections" /etc/my.cnf /etc/my.cnf.d/

/etc/my.cnf.d/server.cnf:14:max_connections = 900
/etc/my.cnf.d/server.cnf:33:innodb_buffer_pool_size = 128M
/etc/my.cnf.d/server.cnf:80:innodb_buffer_pool_size=64M

アップグレード前とまったく同じです。設定はちゃんと残っていました。

4サイトをブラウザで確認

最後に、4つのサイトをブラウザで開いて、トップページと記事ページが普通に表示されるか確認しました。WordPressの管理画面にもログインして、「ツール」→「サイトヘルス」→「情報」→「データベース」を見てみると…

WordPress側からも、ちゃんと10.11.18として見えています。4サイトとも問題なし！

ステップ8：cronを元に戻す

止めていた目覚まし時計を元に戻します。さっき保存したファイルを読み込むだけです。

crontab /root/crontab.bak

元に戻ったか確認します。

crontab -l

0 * * * * curl -s https://（サイトのURL）/wp-cron.php?doing_wp_cron > /dev/null 2>&1

0 3 * * * /root/scripts/wp-backup.sh

最初と同じ2行が出たので、復旧完了です。

ちなみに、今日の3時のバックアップは止めていたので動いていませんが、作業前の2時19分に手動で取っているので問題ありません。明日からはいつもどおり自動で動きます。

ステップ9：メモリ節約の設定が本当に効いているか確認

ステップ7で「設定ファイルに書いてあること」は確認しましたが、ファイルに書いてあることと、実際に動いているMariaDBがその値を使っているかは別の話です。なので、動いているMariaDBに直接聞いてみます。

mysql -e "SELECT @@innodb_buffer_pool_size/1024/1024 AS buffer_pool_MB;"

+----------------+
| buffer_pool_MB |
+----------------+
|    64.00000000 |
+----------------+

64MB。ちゃんと節約設定が効いています。

サーバー全体のメモリも確認しておきます。

free -h

               total        used        free      shared  buff/cache   available
Mem:           762Mi       626Mi        61Mi       267Mi       472Mi       136Mi
Swap:          2.0Gi       285Mi       1.7Gi

1GBプランでWordPress4サイトなので、ギリギリ気味だけど普通に回っている状態です。数日様子を見て、サイトが重くなったり余裕（available）が100Miを切る日が続くようなら、またチューニングを考えます。

後片付け：イメージはいつ消す？

ConoHaの「イメージ」画面には、今回保存した before-mariadb1011-20260923 が残っています。

これはアップグレード直前（2時33分）のサーバーそのものなので、もし数日以内に「なんだか調子がおかしい」となったときに、丸ごと元に戻せる保険です。

ただし、イメージから戻すと、保存した時間より後の変更（アップグレードも、その後に書いた記事やコメントも）は全部消えます。戻すのは本当に困ったときの最終手段です。

1週間くらい様子を見て、問題がなければ削除する予定です。

サーバーの中に作った控えのファイル（/root/crontab.bak と /root/mariadb-conf-backup/）は小さいので、そのまま置いておいても問題ありません。

つまずきやすいポイントまとめ

まとめ

今回、ConoHa VPS（KUSANAGI）のMariaDBを10.6.25から10.11.18へアップグレードしました。

やってみてわかったのは、アップグレード本番はコマンド1行と質問2つだけ。大事なのは「その前の準備」ということです。

• cronを止めて、作業中に邪魔が入らないようにする
• 手動バックアップを取って、中身もチェックする
• ConoHaのイメージ保存で、サーバーを丸ごと保険に入れる
• 設定ファイルと、その値を控えておく
• 終わったら、設定が本当に効いているかまで確認する

この準備さえしておけば、もし失敗しても何度でもやり直せます。「データベースのアップグレードってこわそう…」と思っている人も、ぜひこの手順を参考にチャレンジしてみてください。