レプリケーションも、つまるところpg_basebackupで一気にコピーしてしまうだけなので、むしろdump, restoreより楽まであるよ

データベースでかくなると、pg_basebackupが終わる前にどんどん新しい更新が溜まっていって、あとからではWAL転送が追いつかなくなってしまうことがあるので、同時にWALもストリーミング受信して、完了時に追いついているようにする。(そういうオプションがある)

完了したら直ちに起動したいので、そこまで一気に実行するようにコマンド書く。

レプリケーションはじまってしまえば、あとは落ち着いていつでも元をとめて、新環境をpromoteできる。

元のサーバでやること

・外からつながるようにインタフェースをlistenする(そのままだとlocalhostしかlistenしてない)

・replication_user作る(名前は別になんでもいい)

・pg_hba.confで、新鯖からのreplication_userでの接続を許可する

・その他のレプリケーション設定パラメータを足す(wal_level = replicaなど)

・ファイアーウォールでも接続許可する

新規のサーバでやること

・一旦データベース初期設定して、整えとく。停止状態。

・データは消しちゃう(rm -fr /var/lib/postgresql/14/main みたいな)

・元サーバのpgtune.confなど、パラメータをある程度一致させとく(コネクション数とか元と違うと蹴られたり)

・もちろんpg_hba.confなどセキュリティ設定は済ませておく

・とりあえずpsqlコマンドでreplication_userで繋がるか事前にテスト

・pg_basebackupで一気に持ってくる

・起動

・レプリケーションできてることを確認する

・(元のサーバに新規書き込みするのやめて、転送しきったら元DB止める)

・promoteする(昇格してこっちが本体になる)

・新規DBサーバへの読み書きを開始する

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系ね。

pgpool-II突っ込んで設定しておくとダウンタイム0でスイッチできるよ
仮想IP喋ってくれるからそこにアプリケーション接続しておけばアプリケーション側の設定も不要で便利

フォロー

@AureoleArk ダウンタイムゼロまで持っていくと格好いいよね! 切り替わったことだれも気付かないw

動かしたままpg_basebackupして、ストリーミングレプリケーションを構築しながらpgpool-IIを使うなどがよさそう

@AureoleArk Mastodonはドキュメントに案内があってpgbouncer使ってる人が多いんだけど、

こいつもpauseして接続先切り替えてresumeするようにすると具合がいい。

Mastodonのプロセスからコネクション維持されててちょっと応答が遅延したぐらいにしか見えないので、擬似的にダウンタイムゼロにみえる。

ログインして会話に参加
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。