[pgsql-jp: 42079] Re: リカバリモードでの起動に１分以上かかる原因についてご教授ください

[Tomoaki Sato]

佐藤です。

> はじめまして
> 谷口と申します。
> 
> よろしくお願いいたします。
> 
> 現在、PostgreSQL 12を使って
> ストリーミングレプリケーションを構成しており、
> スタンバイの昇格後に、
> 降格したプライマリをリカバリモードで起動したときに
> 起動に１分以上かかる現象が発生しております。
> 
> これについて考えられる原因をご教授いただけないでしょうか。

WAL ファイルの数はたいして多くないとのことですが、普通に考えると、WAL
適用に時間がかかったためだと思います。ログを確認し、WAL 適用がいつ完了
したかを見れば、切り分けができると思います。

最近では、Slack で聞いたほうが、反応があるかもしれません。

  https://slofile.com/slack/postgresql-jp

> 【環境】
> 　ー　２サーバ(プライマリ - スタンバイ)の
> 　　　ストリーミングレプリケーション構成
> 　　　非同期=synchronous_standby_namesなし
> 　ー　いずれのサーバも以下のスペック
> 　　　CPU　　：4
> 　　　メモリ　：64GB
> 
> 【手順】
> 　１．プライマリで下記設定のもとDB更新を行う
> 　　　max_wal_size = 1GB　（デフォルト）
> 
> 　　　DB更新が高頻度であったため、チェックポイントが多発し、
> 　　　max_wal_sizeを大きくする旨の警告が表示されました
> 
> 　２．プライマリでpg_ctl stop -m immediate
> 
> 　３．スタンバイでpg_ctl promote　→　新プライマリに昇格
> 
> 　４．旧プライマリで pg_basebackup を実行し
> 　　　新プライマリからバースバックアップを取得
> 
> 　５．リカバリモードでpg_ctl start
> 　　　→　１分以上後にタイムアウトが発生しました(pg_ctlの仕様)
> 　　　　　起動はバックグラウンドで徐々に進行し、最終的には起動が完了
> 　　　　　しました。
> 　　　　　このとき、walは２０ファイル程度であったことを確認
> 
> 【推測】
> 　リカバリモードでのwalからのトランザクションの組み立てに時間を要して
> 　いるのかもしれません。
> 　しかし、walのファイル数はそれほど大量ではなく
> 　タイムアウトが発生した原因であると断定できません。


----
Tomoaki Sato <sato ＠ sraoss.co.jp>
SRA OSS, Inc. Japan