MySQL 5.7 to 8.0 の履歴(No.4)

CONTENTS

MySQL 5.7 to 8.0
起動せず！？
- MySQL8からはクエリキャッシュが使えなくなった

Lastmodified　2024-08-05 (月) 08:44:56

MySQL 5.7 to 8.0†

Nextcloud 20.0.5 へUPしたところ、

MySQL version "5.7.32-log" is used. Nextcloud 21 will no longer support this version and requires MySQL 8 or higher.

とのこと。

【参考URL】https://gato.intaa.net/archives/12577

Mysql dump import

DB全体をバックアップ

mysqldump -v -u root -p -x --all-databases > dump_ALL.sql

特定のDBをバックアップ

mysqldump -v -u root -p database_name > dump.sql

mysqldump -v -u root -p NC > dump_NC.sql
mysqldump -v -u root -p nc > dump_nc.sql

MySQL57 から　8 にバージョンアップ

# portupgrade -o databases/mysql80-client -r databases/mysql57-client
# portupgrade -o databases/mysql80-server -r databases/mysql57-server

手元の環境(FreeBSD 11.4-RELEASE-p3)だと、上記では、インストールエラー（same place）が出るので、地味に

# cd /usr/ports/databases/mysql57-client
# make deinstall
# cd ../mysql57-server
# make deinstall

# portinstall mysql80-client
# portinstall mysql80-server

# service mysql-server restart          #MySQLサーバを再起動(ここまで旧バージョンで稼働したままで可)
# mysql_upgrade -u root -pパスワード    #データベースの確認と更新

# mysql_upgrade -u root -p

としたところ、以下の様なメッセージが。

Enter password: The mysql_upgrade client is now deprecated. The actions executed by the upgrade client are now done by the server. To upgrade, please start the new MySQL binary with the older data directory. Repairing user tables is done automatically. Restart is not required after upgrade. The upgrade process automatically starts on running a new MySQL binary with an older data directory. To avoid accidental upgrades, please use the --upgrade=NONE option with the MySQL binary. The option --upgrade=FORCE is also provided to run the server upgrade sequence on demand. It may be possible that the server upgrade fails due to a number of reasons. In that case, the upgrade sequence will run again during the next MySQL server start. If the server upgrade fails repeatedly, the server can be started with the --upgrade=MINIMAL option to start the server without executing the upgrade sequence, thus allowing users to manually rectify the problem.

mysql_upgradeクライアントは非推奨になりました。アップグレードクライアントによって実行されるアクションは、サーバーによって実行されるようになりました。アップグレードするには、古いデータディレクトリで新しいMySQLバイナリを起動してください。ユーザーテーブルの修復は自動的に行われます。アップグレード後に再起動する必要はありません。アップグレードプロセスは、古いデータディレクトリで新しいMySQLバイナリを実行すると自動的に開始されます。誤ってアップグレードしないように、MySQLバイナリで--upgrade = NONEオプションを使用してください。サーバーのアップグレードシーケンスをオンデマンドで実行するために、オプション--upgrade = FORCEも提供されています。いくつかの理由により、サーバーのアップグレードが失敗する可能性があります。その場合、アップグレードシーケンスは、次回のMySQLサーバーの起動時に再度実行されます。サーバーのアップグレードが繰り返し失敗する場合は、-upgrade = MINIMALオプションを使用してサーバーを起動し、アップグレードシーケンスを実行せずにサーバーを起動して、ユーザーが手動で問題を修正できるようにすることができます。

↑

起動せず！？†

と言うか、一端起動してプロセスは上がるが、すぐにシャットダウンする模様。

↑

MySQL8からはクエリキャッシュが使えなくなった†

とのことで、

[ERROR] [MY-000067] [Server] unknown variable 'query_cache_type=0'.
[ERROR] [MY-010119] [Server] Aborting

と言うようなエラーで落ちます。

そこで、設定ファイルからキャッシュの設定をコメントアウトする。

/usr/local/etc/mysql/my.cnf

[mysqld]
#query_cache_type                = 0
#query_cache_size                = 0

起動した。

Total access 1520：本日 1：昨日 1

Counter: 1520, today: 1, yesterday: 1