MySQL 5.7からMySQL 8.4へ ― データベース移行を慎重に実施

はじめに

前回は、ConoHa WING上で約3年間運用してきたNextcloudをアップデートするにあたり、まず現状確認とバックアップを行ったことを紹介しました。

今回の第2回では、Nextcloud本体のメジャーバージョンアップに進む前に行った、MySQLデータベースの移行について記録します。

作業開始時の環境では、Nextcloudは26系、データベースはMySQL 5.7系でした。

Nextcloudのアップデートを進めようとしたところ、古いMySQLがサポート対象外であることが分かりました。

そこで、

NextcloudのアップデートとMySQLの移行を同時に行わない

ことにしました。

まずデータベースだけをMySQL 8系へ移行し、

Nextcloud 26が新しいMySQLで正常に動作することを確認してから、Nextcloud 27へのアップデートへ進む

という方針です。

今回も第1回と同じく、

ChatGPTに相談 → 私自身が実行 → 結果をChatGPTに伝える → 一緒に確認 → 次へ進む

という方法で、一つずつ作業しました。

---

移行前の環境を確認

作業時点では、おおむね次の環境でした。

• Nextcloud：26.0.13
• PHP CLI：8.2.31
• データベース：MySQL 5.7.44-log
• 旧DBサーバー：ConoHa WING上のMySQL 5.7環境
• 移行先：MySQL 8.4系

まず、いきなりデータベース移行を始めるのではなく、現在の状態を確認しました。

PHPの確認：

php -v

Nextcloudの状態確認：

php occ status

Nextcloudが現在接続しているDBサーバーも確認しました。

php occ config:system:get dbhost

さらにMySQLへ直接接続し、実際のバージョンを確認しました。

mysql -h [旧DBサーバー] -u [DBユーザー] -p -e "SELECT VERSION();"

ここでMySQL 5.7.44-logが動作していることを確認しました。

---

まずデータベースをバックアップ

移行前に最も重要なのは、やはりバックアップです。

mysqldumpを利用して、Nextcloudデータベース全体を保存しました。

実際のDBサーバー名、データベース名、ユーザー名などは公開用に伏せています。

mysqldump \ -h [旧DBサーバー] \ -u [DBユーザー] \ -p \ --single-transaction \ --quick \ --skip-lock-tables \ --no-tablespaces \ [NextcloudのDB名] \ | gzip > ~/nextcloud-db-before-migration.sql.gz

ここで使用した、

--no-tablespaces

には理由があります。

ConoHa WINGのような共有サーバー環境では、MySQLの権限が専用サーバーとは異なります。

当初、mysqldump実行時にPROCESS権限に関係するエラーが発生しました。

ChatGPTにエラー内容を伝えて確認した結果、今回のバックアップでは--no-tablespacesを付けることで対応できました。

これは今回のような共有サーバー環境ならではのポイントだったと思います。

---

バックアップが本当に正常か確認

バックアップファイルを作っただけでは、まだ次へ進みません。

まずgzipファイルが正常か確認しました。

gzip -t ~/nextcloud-db-before-migration.sql.gz

問題なく終了することを確認します。

今回作成した圧縮後のデータベースバックアップは約6.9MBでした。

さらにdumpファイルの最後まで正常に作成されていることも確認しました。

そしてデータベースだけでなく、

• config.php
• Nextcloud関連データ
• データベースdump

について、別の保存先にもバックアップを確保しました。

「バックアップがある」だけではなく、「必要になったら戻せる状態になっている」

ことを確認してから次へ進みました。

---

Nextcloudをメンテナンスモードへ

バックアップが確認できたところで、Nextcloudをメンテナンスモードにしました。

php occ maintenance:mode --on

データベース移行中に、ブラウザやアプリからNextcloudへ書き込みが発生するのを避けるためです。

ここから先は、Nextcloudを通常利用しない状態で作業を進めました。

---

ConoHa WINGでMySQL 8.4へ移行

次にConoHa WINGの管理画面からデータベース移行を実施しました。

移行前：

MySQL 5.7.44-log

移行後：

MySQL 8.4.4

となりました。

今回の環境では、データベース名、DBユーザー名、パスワードはそのままで、DBサーバーのホスト名が変更されました。

そのため、Nextcloud側のconfig.phpに設定されているDB接続先を新しいMySQLサーバーへ変更する必要があります。

---

NextcloudのDB接続先を変更

Nextcloudのoccを使って、DBホストを新しいMySQL 8.4側へ変更しました。

公開記事のため実際のホスト名は伏せています。

php occ config:system:set dbhost --value="[新DBサーバー]"

変更後、本当に新しい値になったか確認します。

php occ config:system:get dbhost

さらに、新しいDBサーバーへMySQLコマンドで直接接続しました。

mysql -h [新DBサーバー] -u [DBユーザー] -p -e "SELECT VERSION();"

ここで、

8.4.4

と表示され、新しいMySQLへ接続できていることを確認しました。

---

ここで問題発生 ― UPDATE権限エラー

データベースの移行自体はできました。

しかし、その後の確認中に、気になるエラーが出ました。

Nextcloudのoc_authtokenテーブルに対するUPDATE permission deniedです。

ここで、

「Nextcloudは一応開くから大丈夫だろう」

とは判断しませんでした。

今回決めていたルールどおり、そこで止まりました。

エラー内容をChatGPTに伝え、まずMySQLユーザーにどの権限が付与されているか確認することにしました。

SHOW GRANTS FOR CURRENT_USER();

権限を確認した後、実際にUPDATE操作が可能なのか、データを変更しないテストを行いました。

START TRANSACTION; UPDATE oc_authtoken SET id=id WHERE 1=0; ROLLBACK;

WHERE 1=0としているため、実際の行は更新されません。

つまり、

UPDATE権限が機能するかだけを安全に確認するテスト

です。

最終的に必要な権限が確認でき、この0行UPDATEテストも正常に通ることを確認できました。

---

ブラウザからも実際の操作を確認

コマンドが正常だからといって、すぐに移行完了とはしませんでした。

今度は実際のNextcloudの操作を確認しました。

ブラウザから、

• ファイルのアップロード
• ファイル名の変更
• ファイルの削除

などを試しました。

これらが正常に動作し、データベース関連の新しいSQLSTATEエラーや権限エラーが発生しないことを確認しました。

ここまで確認して、ようやく、

「MySQL 8.4への移行は正常に完了した」

と判断しました。

---

移行後にも、もう一度バックアップ

ここも今回重要だと感じたポイントです。

移行前にバックアップしたから終わりではありません。

MySQL 8.4で正常に動作している状態ができたので、今度はこの正常な状態を新しい復旧ポイントとして保存しました。

新しいMySQL 8.4側から再びデータベースをdumpし、更新されたconfig.phpもバックアップしました。

さらにNextcloud本体やデータについても、別のストレージへバックアップしました。

これで、

MySQL 5.7時代のバックアップ

と、

MySQL 8.4への移行が正常に完了した後のバックアップ

の両方を確保できました。

---

なぜNextcloudのアップデートと同時にやらなかったのか

今回、ChatGPTと相談しながら特に意識したのが、

一度に複数の大きな変更をしない

ということでした。

仮に、

MySQL 5.7 → 8.4

と同時に、

Nextcloud 26 → 27

まで実施して、その後エラーが出たとします。

すると、

「MySQLが原因なのか？」

「Nextcloud 27が原因なのか？」

「アプリの互換性なのか？」

「PHPなのか？」

と、原因の切り分けが難しくなります。

そこで、

① MySQLだけ変更する

↓

② Nextcloud 26のまま正常動作を確認する

↓

③ 新しい正常状態をバックアップする

↓

④ その後Nextcloud 27へ進む

という順番にしました。

時間はかかりますが、問題が発生したときの原因を特定しやすくなります。

---

ChatGPTと作業して便利だったこと

今回のMySQL移行では、第1回以上にChatGPTとのやり取りが役に立ちました。

特に、

• mysqldumpの権限エラー
• 共有サーバー環境でのオプション
• MySQL移行後の権限確認
• UPDATE操作の安全なテスト方法
• どの段階で「移行成功」と判断するか

などは、自分だけで作業していたら、かなり調べる時間が必要だったと思います。

一方で、ChatGPTからコマンドを教えてもらっても、私はできるだけ一つずつ実行しました。

そして結果をChatGPTへ返し、

「この結果なら次へ進んで大丈夫ですか？」

と確認しました。

今回改めて感じたのは、AIを使うメリットは、単に答えを早く得られることだけではないということです。

作業中に発生した状況を伝え、その時点から次の判断を一緒に考えられる。

これは、今回のようなサーバーメンテナンスでは非常に便利でした。

---

第2回のまとめ

今回のMySQL移行では、

MySQL 5.7.44-log

から、

MySQL 8.4.4

へ移行することができました。

しかし、今回一番重要だったのは「8.4になった」という結果そのものではなかったと思います。

移行前に確認する。

バックアップする。

バックアップ自体を検証する。

メンテナンスモードにする。

データベースだけを移行する。

新DBへ接続できていることを確認する。

権限を確認する。

実際のNextcloud操作を試す。

正常な状態を、もう一度バックアップする。

そして、

分からない結果が出たら、そこで止まってChatGPTに相談する。

この積み重ねによって、次のNextcloud本体のアップデートへ進める状態になりました。

---

次回予告

【第3回】いよいよNextcloud 26から27へ

MySQL 8.4への移行が完了し、Nextcloud 26が新しいデータベース上で正常に動作することを確認できました。

次はいよいよNextcloud本体のメジャーバージョンアップです。

Nextcloud 26系の最終バージョンからNextcloud 27へ。

ここでも一気に進めるのではなく、

バックアップ → アップデート → occによる確認 → データベースの確認 → Web画面での動作確認

という手順を繰り返しました。

次回は、実際にNextcloud 27.1.11へアップデートした手順と、その際に行った確認について紹介します。

---

免責事項

この記事は、Namiki Associatesで実際に使用しているConoHa WINGおよびNextcloud環境で行った作業をもとにした記録です。

Nextcloud、PHP、MySQL、ConoHa WINGなどの仕様や対応バージョンは変更される可能性があります。また、サーバー環境によって必要な手順や使用できるコマンド、権限などは異なります。

同様の作業を行う場合は、Nextcloud、MySQL、ConoHa WINGなどの最新の公式情報を確認し、データベース、設定ファイル、データディレクトリなどのバックアップを取得したうえで、ご自身の環境に合わせて慎重に作業してください。

また、ChatGPTを含むAIの回答が常に正しいことを保証するものではありません。重要なサーバー操作では、AIの回答をそのまま無条件に実行するのではなく、バックアップを取得し、一つずつ実行結果を確認しながら作業することをおすすめします。