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

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• MySQL 5.7 to 8.0 へ行く。
  • 1 (2021-01-17 (日) 04:14:09)
  • 2 (2021-01-17 (日) 05:46:27)
  • 3 (2021-01-17 (日) 08:57:53)
  • 4 (2021-01-18 (月) 10:09:40)
  • 5 (2021-02-12 (金) 16:47:10)
  • 6 (2021-02-15 (月) 11:37:41)
  • 7 (2021-02-16 (火) 11:59:03)
  • 8 (2024-08-01 (木) 17:51:31)
  • 9 (2024-08-02 (金) 09:30:36)
  • 10 (2024-08-02 (金) 13:26:09)
  • 11 (2024-08-03 (土) 10:55:26)

---

CONTENTS

---

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

---

MySQL 8.0 to 8.1 （smb212.smb.net）†

MySQL を、8.0から8.1へアップする。mysql80-server mysql80-client を make deinstall し、mysql81-server　を　make install clan すると、エラー！

1 problem(s) in 1 installed package(s) found.
=> Please update your ports tree and try again.
=> Note: Vulnerable ports are marked as such even if there is no update available.
=> If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes'
*** Error code 1

で、

# make DISABLE_VULNERABILITIES=yes install clean

すると完走した。同時にclient もインストールされた。

# /usr/local/etc/rc.d/mysql start

したが、/etc/rc.conf に、mysql_enable="YES" が無いといわれたので、設定して起動すると・・・

mysqld: Can't create/write to file '/var/db/mysql_tmpdir/ibzXhMAM' (OS errno 13 - Permission denied)

というエラー（/ver/db/mysql/smb212.err）で起動出来ない。なので、

/var/db/mysql_tmpdir/　の所有権者を root に成っていたところを mysql に変更し、起動し直したところ、

2024-08-01T08:43:46.418482Z 0 [System] [MY-010116] [Server] /usr/local/libexec/mysqld (mysqld 8.1.0) starting as process 61704
2024-08-01T08:43:46.510840Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-08-01T08:43:50.788500Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-08-01T08:43:56.722246Z 4 [System] [MY-013381] [Server] Server upgrade from '80035' to '80100' started.

と無事起動した模様。

---

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

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

# portinstall mysql80-client
# portinstall mysql80-server

portinstall mysql80-client --batch && portinstall mysql80-server --batch

# 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

起動した。

別の機体でも機動せず。こちらは、

2021-02-12T07:14:02.153229Z 0 [ERROR] [MY-000077] [Server] /usr/local/libexec/mysqld: Error while setting value 
'NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' to 'sql_mode'.

ということで、NO_AUTO_CREATE_USER　の記述をmy.cnf から消去。

#sql_mode = NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
sql_mode = NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

う、動いた。 https://qiita.com/gremito/items/45c327e044df2c0368cc

---

OpenPNE 3.9.6 「サーバが混み合っているか・・・・」のエラー

tail /var/log/httpd-error.log

[client xxx.yyy.zzz.aaa:123456] Couldn't locate driver named mysql

　　　　　　　　　　　　　　↓

portupgrade -rf php73-pdo_mysql-7.3.27 --batch

---

Total access 1520：本日 1：昨日 1