mariaDBのGaleraクラスタの起動に失敗した場合の復旧方法について
今回は以前投稿したmariaDBのGaleraクラスタの起動に失敗した場合の復旧方法について紹介します。
以前の記事ではGaleraクラスタの再開方法として、最後に停止したmariaDBから起動すると記載しましたが、今回は最後に停止したmariaDBから起動できないというケースに遭遇しました。
停電やKernelのアップデートなどで、mariaDBを「systemctl コマンド」で停止することを失念して、Linuxサーバをシャットダウンやリブートしまった場合など、この事象が発生するかもしれません。
(※筆者もまさに本日Kernelアップデートでうっかりmariadbを停止せずに再起動した結果、3台のmariadbのいずれからもgalera_new_clusterコマンドで起動できなくなってしまいました。
虚しく以下のメッセージが表示されるだけでした。
起動できない際のステータス
$ sudo systemctl status mariadb
× mariadb.service - MariaDB 10.8.6 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: failed (Result: exit-code) since Fri 2022-12-23 22:12:43 JST; 6s ago
Docs: man:mariadbd(8)
https://mariadb.com/kb/en/library/systemd/
Process: 1162 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
Process: 1163 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 1165 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: 1251 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
Main PID: 1251 (code=exited, status=1/FAILURE)
Status: "MariaDB server is down"
CPU: 596ms
12月 23 22:12:43 db0 mariadbd[1251]: 2022-12-23 22:12:43 0 [Note] WSREP: ####### Assign initial position for certification: 755c9a30-6ae7-11ed-8c3b-2adf09c42458:416453, protocol version: -1
12月 23 22:12:43 db0 mariadbd[1251]: 2022-12-23 22:12:43 0 [Note] WSREP: Start replication
12月 23 22:12:43 db0 mariadbd[1251]: 2022-12-23 22:12:43 0 [Note] WSREP: Connecting with bootstrap option: 1
12月 23 22:12:43 db0 mariadbd[1251]: 2022-12-23 22:12:43 0 [Note] WSREP: Setting GCS initial position to 755c9a30-6ae7-11ed-8c3b-2adf09c42458:416453
12月 23 22:12:43 db0 mariadbd[1251]: 2022-12-23 22:12:43 0 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .
12月 23 22:12:43 db0 mariadbd[1251]: 2022-12-23 22:12:43 0 [ERROR] WSREP: wsrep::connect(gcomm://192.168.1.131,192.168.1.132,192.168.1.133) failed: 7
12月 23 22:12:43 db0 mariadbd[1251]: 2022-12-23 22:12:43 0 [ERROR] Aborting
12月 23 22:12:43 db0 systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
12月 23 22:12:43 db0 systemd[1]: mariadb.service: Failed with result 'exit-code'.
12月 23 22:12:43 db0 systemd[1]: Failed to start MariaDB 10.8.6 database server.
復旧方法
上記エラーの中の以下がヒントになっています。
[ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .
要するに「grastate.dat」というファイルの中の「safe_to_bootstrap」に「1」をセットしろと言っています。
「grastate.dat」ファイルはubuntu linux 22.04の場合は以下にありました。
$ sudo vi /var/lib/mysql/grastate.dat
中身は以下の内容となっておりました。
<修正前>
# GALERA saved state
version: 2.1
uuid: 755c9a30-6ae7-11ed-8c3b-2adf09c42458
seqno: -1
safe_to_bootstrap: 0
従ってこの対応方法は、上記の「safe_to_bootstrap: 0」を「safe_to_bootstrap: 1」ということになります。
<修正後>
# GALERA saved state
version: 2.1
uuid: 755c9a30-6ae7-11ed-8c3b-2adf09c42458
seqno: -1
safe_to_bootstrap: 1
これで保存して、以下コマンドで再開可能となりました。
$ sudo galera_new_cluster
まとめ
今回はmariadbのGaleraクラスタで再開に失敗した場合の復旧方法について紹介しました。
何かの参考になれば幸いです。