pg_basebackupはこんな感じ。
# sudo -u postgres pg_basebackup -h xxx.xxx.xxx.xxx -p 5432 -D /var/lib/postgresql/14/main/ -U replication_user -R -P --checkpoint=fast -X stream -v && pg_ctlcluster 14 main start
xxx.xxx.xxx.xxxは元サーバのIPアドレス。ポートも指定してるけど、5432ならいらないかな。
rootになって、pg_basebackupから、完了後のstartまで一気にやる。これはUbuntu / Debian系ね。
pg_lsclusterしたらもうmainがいたりするけど、いたら止める。
sudo pg_ctlcluster 14 main stop
いないなら作る。
sudo pg_createcluster 14 main
データ消す。
sudo rm -fr /var/lib/postgresql/14/main
pg_hba.conとかconf.d/に置く設定は割愛。あ、これは書いとくか。
hot_standby = on
レプリカがホットスタンバイで動くようにする設定。
(中略)
元DBで select * from pg_stat_replication; すると、実行中のレプリケーション接続がリストされるので、これで状況みる。
昇格はこう。
sudo pg_ctlcluster 14 main promote
レプリケーションやめて、こっちが本体になる。
@noellabo@fedibird.com pgpool-II突っ込んで設定しておくとダウンタイム0でスイッチできるよ
仮想IP喋ってくれるからそこにアプリケーション接続しておけばアプリケーション側の設定も不要で便利
@AureoleArk ダウンタイムゼロまで持っていくと格好いいよね! 切り替わったことだれも気付かないw
@noellabo@fedibird.com 動かしたままpg_basebackupして、ストリーミングレプリケーションを構築しながらpgpool-IIを使うなどがよさそう
@AureoleArk Mastodonはドキュメントに案内があってpgbouncer使ってる人が多いんだけど、
こいつもpauseして接続先切り替えてresumeするようにすると具合がいい。
Mastodonのプロセスからコネクション維持されててちょっと応答が遅延したぐらいにしか見えないので、擬似的にダウンタイムゼロにみえる。
@noellabo@fedibird.com なるほどすぎる
@noellabo ダジャレを検出しました(検出ワード: REPLICATION)
listen_addresses = 'xxx.xxx.xxx.xxx,localhost'
リモートサーバじゃなくて、元サーバのインタフェースに振ってあるアドレス。面倒なら
listen_addresses = '*'
でいい。
replication_userつくる。パスワードつける。
CREATE ROLE replication_user LOGIN REPLICATION PASSWORD 'xxxxxxxxx';
pg_hba.confこんな感じ。
host replication replication_user xxx.xxx.xxx.xxx/32 md5
replication.confとか作ってconf.d/ においとくといい。
synchronous_commit = off
wal_level = replica
max_wal_senders = 3
ファイアーウォールはたとえばこう。
ufw allow from xxx.xxx.xxx.xxx to any port 5432 proto tcp