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

[bobytyt]

佐藤さん

谷口です。
お世話になっております。

ご回答ありがとうございます。

ログを確認してみます。

また、今後はご提案いただきましたslackに
質問をさせていただこうと思います。


何卒よろしくお願いいたします。

On 2021/07/12 13:14, Tomoaki Sato wrote:
> 佐藤です。
>
>> はじめまして
>> 谷口と申します。
>>
>> よろしくお願いいたします。
>>
>> 現在、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