CentOS7でMariaDBのバージョンを5.5から最新(11.2)にアップデートする
このWordPressのサイトを構成しているDBのバージョンが古くて、ヘルスステータスで指摘されていて、
元々私もDBのバージョンが古いからアップデートしたかったので、意を決して、アップデートしました。
WordPressのバージョンアップは手軽にしても良いけど、基盤側のPHPやDBのアップデート(しかも、メジャーバージョンのアップデート)は問題が起こりやすいので、気合いが必要なのです。
その際に、沼ったところがあったので、その解決に関するメモ的な記事になります。
DBアップデート
CentOS7でMariaDBのバージョンを10系にアップデートする記事はネットに散見されるので、そこはさらっと流しますが…
通常なら、`yum install mariadb-server`とか`yum update mariadb-server
`でアップデートできるのですけど、
CentOS7では何もしなければ、5.5までしかサポートされていないので、最新を入れられるようにyumリポジトリを設定します。
# curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
そして、アップデート実行!(パッケージ名のmariadbからMariaDBになるのでそこは注意)
# yum update MariaDB-server
以上!!
…本来ならこれでアップデートは完了ですが……そうは行かなかった
※ 安全にアップデートするなら、DBのバックアップとかサービスの停止とかやった方が良いので、そこは各自で考えてね
エラー発生
何が起きたかと言うと、アップデートをした時にエラーが発生しました。
# yum update MariaDB-server
~~~ 前略 ~~~
エラー: パッケージ: MariaDB-server-11.2.2-1.el7.centos.x86_64 (mariadb-main)
要求: pv
どうやら、`pv`というパッケージの依存関係でエラーに出たっぽい。pvが見つからない感じ。
ネットで情報を探していると、EPELリポジトリを入れると解決するとあったので試してみましたが…
# yum install epel-release
一致したパッケージ epel-release-7-11.noarch はすでにインストールされています。更新を確認しています。
何もしません
既に適用されていました…😖
リポジトリの有効化
色々と探って考えました結果…リポジトリが無効になってました!!! ナゼ!?
# yum repolist all
~~~略~~~
!epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 無効
epel-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Debug 無効
epel-source/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Source 無効
epel-testing/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 無効
epel-testing-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Debug 無効
epel-testing-source/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Source 無効
~~~略~~~
普通に`epel/x86_64
`が無効になってます。
と言うことで、有効化します。
# yum-config-manager --enable epel
再度確認(epelだけ表示したかったのでgrep掛けてます)
# yum repolist all | grep epel
epel/x86_64 Extra Packages for Enterprise L 有効: 13,789
epel-debuginfo/x86_64 Extra Packages for Enterprise L 無効
epel-source/x86_64 Extra Packages for Enterprise L 無効
epel-testing/x86_64 Extra Packages for Enterprise L 無効
epel-testing-debuginfo/x86_64 Extra Packages for Enterprise L 無効
epel-testing-source/x86_64 Extra Packages for Enterprise L 無効
ちゃんと有効になりました。
これで、あとは普通に`yum update
`で無事にアップデート成功!!!🎉
念の為のバージョン確認で11.2.2になりました。ヨカッタ
# mariadb --version
mariadb from 11.2.2-MariaDB, client 15.2 for Linux (x86_64) using readline 5.1
余談 fail2banの暴走
DBを更新後、なんかsshでの反応が遅くておかしいなぁ〜と思ったので、サーバーを再起動させたのですが…
再起動後にDBサーバーが起動せずに少しあたふたしました。
# systemctl start mariadb
Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.
# systemctl status mariadb
● mariadb.service - MariaDB 11.2.2 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: failed (Result: exit-code) since 水 2023-11-29 18:13:00 JST; 12s ago
Docs: man:mariadbd(8)
https://mariadb.com/kb/en/library/systemd/
Process: 1118 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
Process: 1108 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
Process: 1106 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Main PID: 1118 (code=exited, status=1/FAILURE)
Status: "MariaDB server is down"
sh[1108]: WSREP: mktemp failed
mariadbd[1118]: 2023-11-29 18:13:00 0 [Warning] Can't create test file '/var/lib/mysql/tk2-201-10313.lower-te...device")
mariadbd[1118]: 2023-11-29 18:13:00 0 [Note] Starting MariaDB 11.2.2-MariaDB source revision 929532a9426d0851...ess 1118
mariadbd[1118]: 2023-11-29 18:13:00 0 [ERROR] mariadbd: Can't create/write to file './ddl_recovery.log' (Errc...device")
mariadbd[1118]: 2023-11-29 18:13:00 0 [ERROR] DDL_LOG: Failed to create ddl log file: ./ddl_recovery.log
mariadbd[1118]: 2023-11-29 18:13:00 0 [ERROR] Aborting
systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start MariaDB 11.2.2 database server.
systemd[1]: Unit mariadb.service entered failed state.
systemd[1]: mariadb.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
少し探った結果…ディスクの空きが無くなっていました
どこでそんなに容量を使っているのか探った結果。`/var/lib/fail2ban
`が限界まで使っている事を発見。
[fail2ban]# ls -la
合計 12568948
drwxr-xr-x. 2 root root 4096 11月 29 18:11 .
drwxr-xr-x. 35 root root 4096 11月 25 02:26 ..
-rw------- 1 root root 2054175744 11月 29 18:00 fail2ban.sqlite3
-rw------- 1 root root 2054175744 11月 29 18:00 fail2ban.sqlite3.20231129-090011
-rw------- 1 root root 2054175744 11月 29 18:01 fail2ban.sqlite3.20231129-090126
-rw------- 1 root root 2054175744 11月 29 18:02 fail2ban.sqlite3.20231129-090203
-rw------- 1 root root 2054175744 11月 29 18:02 fail2ban.sqlite3.20231129-090230
-rw------- 1 root root 2054175744 11月 29 18:03 fail2ban.sqlite3.20231129-090254
-rw------- 1 root root 404467712 11月 29 18:03 fail2ban.sqlite3.20231129-090307
-rw------- 1 root root 140955648 11月 29 18:11 fail2ban.sqlite3.20231129-091104
恐らく、DBサービスを止めずにアップデートしたから、何か動きがおかしくなったのでしょうね。
(よくアップデートのログをみると、DBアップデート時にfail2banも更新していました。)
と言うことで、潔く削除してリセットしちゃいます。
# fail2ban-client stop
Shutdown successful
# rm -f *
# fail2ban-client start
Server ready
これで、ちゃんとDBサービスが起動してくれました ヨカッタ😌
これでこのサイトの大きなアップデートは全部完了です🎉
結論
- リポジトリは無効になっていることもあるので確認しましょう!
- 動いているサービスのアップデートはちゃんとサービスを止めてからしましょう!
ディスカッション
コメント一覧
まだ、コメントがありません