[pgpool-general-jp: 519] Re: recovery_timeoutについて

[荒川広成]

石井様

荒川です。

> 荒川様
>
> 石井です．
>
>> 石井様、
>>
>> 荒川です。
>> まず、結果から報告させて頂きます。
>> client_idle_limit が0となっていました。
>> 設定ファイルが変更できない状態だったので、関係するアプリケーションを全て再起動したところ
>> 再起動まで上手くいきました。
>
> ご報告ありがとうございます．
>
>> 以下インラインにて。
>>
>> > 石井です．
>> >
>> >> はじめまして。荒川と申します。
>> >> Powergres Plus 5とpgpool-IIを利用してレプリケーションをしています。
>> >
>> > PowerGres Plusですか？pgpool-IIでのオンラインリカバリには問題があるか
>> > も知れません（うまくいくかもしれませんが，私は未確認です）．ご契約のサ
>> > ポート窓口を通じてお問い合わせ頂いた方が良いと思います．
>>
>> サポート窓口からはpgpoolに関するサポートは難しいとのことでしたが、
>> どうやら上手くいく行った模様です。
>> PITRによるオンラインリカバリについては試していませんがrsyncによる同期はスムーズでした。
>
> そうでしたか．サポート担当と協議してみます．

サポート契約がＦさんなので。というところです。
Plusとpgpoolを併せるとかなり使い勝手が良いので、使用可能 or 不可だけでもWEB上に載ってると
嬉しい方もいらっしゃるかと思います。
PITRもそのうち試してみようと思いますが、rsyncでもうまくいくのでこちらがお手軽な気がしました。

postgresと多少ファイル構成が違いますが、
rsyncで$PGDATA以下を全て同期したのち、

pgpool_remote_start内でSSH経由にて
設定ファイルが異なるようであれば退避していたもので置き換え、
postmaster.pidを消してあげれば立ち上がります。

>> > 以下，通常のPostgreSQL(もしくはPowerGres PlusではないPowerGres)を前提
>> > としてお答えします．また，最新版のpgpool-II 2.1をお使いであると想定し
>> > ます．
>>
>> 失礼致しました。
>> 利用しているpgpool-IIのバージョンは2.1です。
>>
>> >> オンラインリカバリをpgpoolAdmin経由で使用しようとしていますが、エラー終了して
>> >> しまいます。
>> >>
>> >> アプリケーション側で接続プーリングを行なっており、切断がうまく行かず
>> >> 失敗してしまうのではないかという想定で現在調査中です。
>> >
>> > アプリケーションで接続プーリングを行なっていると，pgpoolから見ていつま
>> > でたっても接続が終了しないので，オンラインリカバリは失敗します．
>> >
>> >> データの同期はrsyncを使用して行なおうとしています。PGDATA領域をごっそり同期しています。
>> >> ファーストステージのスクリプトに関しては最後まで実行されていることを確認しましたが、その後の動作がよく見えない状況です。
>> >>
>> >> うまくいったり、いかなかったり。
>> >> という状況が続いており、タイムアウト時間を疑っています。
>> >
>> > タイムアウトの場合は，pgpool-IIのエラーログに何か出力されるはずです．
>> >
>> >> そこで、設定ファイル上の
>> >> child_life_time
>> >> と
>> >> recovery_timeout
>> >>
>> >> の因果関係について教えて頂きたく投稿させて頂きました。
>> >> 現在child_life_timeが`300`
>> >> recovery_timeoutが`100`で設定されています。
>> >>
>> >> (疑問点1)
>> >> recovery_timeoutとはオンラインリカバリ中どこからどこまでの間の期間に
>> >> 関するタイムアウト時間でしょうか？
>> >
>> > 2つあります．
>> >
>> > 一つはセカンドステージに入る前の，クライアントの接続終了待ち時間です．
>> >
>> > もう一つは，セカンドステージの最後にリカバリが終了したpostmasterの起動
>> > 完了を待つ時間です．
>> >
>> >> child_life_timeより値を大きくする必要があるのでしょうか？
>> >
>> > ありません．child_life_timeは，クライアントからの接続が切断されないと，
>> > カウントを開始しないからです．
>>
>> なるほど勘違いしてました。
>> recovery_timeoutをだいぶ長くして試したりもしましたが、切断されない理由が
>> 納得できました。ありがとうございます。
>>
>> > 接続を終了していないクライアントのアイドル時間によるタイムアウトを設定
>> > したい場合は，client_idle_limitを使用してください．その際は，
>> >
>> > client_idle_limit < recovery_timeout
>> >
>> > になるようにしてください．
>
> ちなみに，次のバージョンでは，client_idle_limitと同じ効果を持ち，かつ
> オンラインリカバリ中のみ有効なclient_idle_limit_in_recovery というディ
> レクティブが追加されます．

それとても嬉しいです。
次期バージョンも楽しみにしてます。

>> そのように致します。
>>
>> >> (疑問点2)
>> >> recovery_timeoutに0を追記した場合、
>> >> タイムアウトしない。のでしょうか。
>> >
>> > 即座にタイムアウトします．
>>
>> 色々合点しました。
>>
>> おかげさまで短時間で復旧できました。
>> 大変助かりました。ありがとうございました。
>
> どういたしまして．
>
>> １点躓いた点をログしておきます。
>> rsyncのオプションに-uをつけるとリカバリ対象のノード側にマスターより新しいデータが存在すると上書きされず、
>> 何度リカバリしても２ノードの行数が合わないという事態が発生してました。
>> アプリ側でもろもろのトランザクション管理をちゃんとやっている前提ですが、
>> 「正」となるノードを決めた後はリカバリ時に `-u`オプションをつけない方が良いようでした。
>
> なるほど．
>
> rsyncと言えば，-z(圧縮)オプションをお使いでしょうか？これはネットワー
> クが低速な場合には有効ですが，最近の高速ネットワークでは，むしろ-zを付
> けない方がrsyncの時間が短縮できるようでした．

現在-zをつけています。
ギガベース、且つpgpool専用の系間パスをひいているので-zはつけないほうがよさそうですね。
魅力的な情報ありがとうございます。リカバリの時間短縮はものすごい大きな課題でして。
その日帰れるか帰れないかとか、笑

ありがとうございましたm(_ _)m

> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
>