自宅インフラの中核を成しつつあるMAAS。そのバックエンドで使われているDBがpostgresqlなので、重い腰をあげて勉強中。前回にストリーミングレプリケーション構成は作れたので、今回はフェールオーバや旧マスターの復旧などを自動化してみる。あまり知識はないんだけど、ググった感じだとpgpool2を使うのが一番やりたいことに近そう。という訳で、pgpool2のインストールから。aptリポジトリはpostgresql11を入れたのと同じところ。

echo "deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main" | sudo tee -a /etc/apt/sources.list.d/pgdg.list
curl -s https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -
apt update
apt install -y pgpool2
mv /etc/pgpool2/pgpool.conf /etc/pgpool2/_pgpool.conf
zcat /usr/share/doc/pgpool2/examples/pgpool.conf.sample-stream.gz > /etc/pgpool2/pgpool.conf
sed -i 's/nobody/pgpool/g' /etc/pgpool2/pgpool.conf
cd /usr/local/src
git clone https://github.com/pgpool/pgpool2
cd pgpool2/src/sql/pgpool-recovery
psql template1
create extension pgpool_recovery;

pgpool.confを適当に直していくんだけど、結構修正点が多くて面倒。上記のようにストリーミングレプリのサンプルをテンプレにして修正していく。pcp_socket_dirはよくわからないけど/tmpにしないと動かなかった。続いてbackend系の情報を2台分登録。重要なのがfailover_commandとfollow_master_command。前者が異常時に新マスターに対して昇格処理を行い、後者が旧マスターに対して復帰処理を行う。以下のように設定してみた。

failover_command = 'sudo ssh %H pg_ctlcluster 11 main promote'
follow_master_command = 'pcp_recovery_node -Upcp -w %P'

pgpoolサービスはpostgresユーザーで動くので、root権限が必要な作業についてはsudoで処理する必要がある。この昇格コマンドについては前回のレプリ試験で実証済みのもの。続くpcp_recovery_nodeコマンドは今回初めて使う。対象ノードのデータディレクトリにあるpgpool_remote_startコマンドをキックしてくれるようだ。このスクリプトに必要な処理を書いておけば、自動で旧マスターがスレーブとしてサービスインしてくれる。前回の検証を踏まえて以下のように作成。

vi /var/lib/postgresql/11/main/pgpool_remote_start
    :
#!/bin/bash
HOST=$1
sudo ssh ${HOST} "
sudo -u postgres cp /var/lib/postgresql/11/main/recovery.done /var/lib/postgresql/11/main/recovery.conf
systemctl start postgresql
"

pgpool周りでとにかく面倒なのは認証周り。OS認証なのかDB認証なのかpgpoolの認証なのかわかりづらい。自分でも何をどこに設定したか覚えていないくらいなんだけど、エラーを見ながら根気よく直していけば動くはず。pcp_recovery_nodeの認証を通すにはpcpのパスワードを空にするくらいしかわからず、やむなく一旦そういう設定を入れて動かしました。後日よりよいやり方を確立して早く直したいところ。

echo pcp:`pg_md5 ''` >> /etc/pgpool2/pcp.conf

この2つの設定がうまくいけばprimaryノードを落とした後、フェールオーバが実行され、しばらくすると片肺からprimary/standby構成に復帰する。出来てしまえばフェールオーバ構成もしっかり動いてくれるんだけど、MySQLのシンプルさに比べるとやっぱり面倒。どちらかというとMySQLが簡単過ぎなだけで、これくらいが普通な気もするけどね。ちなみにpgpoolでノードの状態を確認するのは以下のコマンド。

psql -p5433 -c'show pool_nodes'

これで2台ともupになっていればいいんだけど、何かをきっかけに実態と表示が異なってしまうことがあった。つまり実際はDBが上がっているのにdownと表示されてしまうってこと。こうなるとDBを再起動してもupに変化してくれない。結論から言うと、双方のpgpool2を止めて、/var/log/postgresql/pgpool_statusを削除してから、pgpoolを起動し直すことで正しい状態に復帰した。直し方を忘れるといつまでもはまります。。。

これで自動的な冗長化が実現出来たんだけど、このDBを利用するMAASをpgpoolの5433ポートに向けると、更新処理が重複してしまうようでエラってconnectionが枯渇する。MAASも2系統動かしているし、何か使い方を間違えているのかな。本質的な問題を修正しないとconnection増やしたところで意味はなさそうだし。また、時間のあるときに調べるしかないか。MAASの完全な冗長化はもう少し先になりそうです。