[pgsql-jp: 41771] Re: レプリケーション構成でスタンバイ系に反映されるまで時間がかかる

[suzutsuki0220 .]

涼月です

> 園田様
確認が遅くなりまして、すみません

アドバイスありがとうございます。
パフォーマンスチューニングの余地はありそうですので、
設定を変えながら確かめていきたいと思います

>更新クエリが多い構成のようですので、
>非同期(synchronous_commit=local) ＋ アーカイブ(archive_mode=on) で
>実装されると、レプリケーション速度が向上するかもしれません。
>カスケードの判断は最後ですね。
→ そうなのですか、remote_writeが万能な感じがしてました。
　 確認してみます


> 高塚様

DB側で再試行が繰り返されると、レスポンスタイムが増えてしまう懸念が
あることから、Webクライアントから再度リクエストを投げてもらうようにしま
した。その方がエラーになったことが分かりやすいのもあります。

どうもありがとうございました。



>園田と申します。
>
>> SQL [SELECT * FROM pg_stat_replication] を実行するとstatusがstreamingと
>> なっていることからレプリケーションの状態は正常であると判断しました
>> しかしながら、マスタと各スタンバイの登録件数をCOUNT関数で確認すると、
>> 件数が異なってしまい、数10?100件程少ない状態です
>pg_stat_replication 結果の streaming は、更新をリアルタイムに反映中 を意味します。
>完全に同期されたかどうかを確認するには、同クエリの *location の値が
>全て一致していることで判断します。
>また、9.2 からは、pg_xlog_location_diff も実装されています。
>
>あと、max_standby_*_delay を変更される前に、
>レプリケーション速度を向上できる方法を探るとすると、
>以下、気になる点です。
>
>・max_connections は変更されているため、
>　shared_buffers など最適に調整する。
>（パフォーマンスチューニング）
>
>・レプリケーション時、マスタの負荷が高いのであれば、
>　カスケードレプリケーションを利用してレプリケーションを
>　分散させる。（非同期モードであることが前提）
>　※実際試したことはないので要検証
>
>また、スタンバイに反映が遅れているのであれば、
>WALアーカイブモードを有効に(archive_mode=on)
>した方が良いかと思います。スタンバイを長時間停止後に
>復旧させる場合などにも有効です。
>archive_mode=off は、スタンバイへの更新が遅れてしまうと、
>エラーにはなりませんが、レプリケーションをされなくなって
>しまう可能性があります。
>archive_command は転送速度が速いコマンドで。
>
>更新クエリが多い構成のようですので、
>非同期(synchronous_commit=local) ＋ アーカイブ(archive_mode=on) で
>実装されると、レプリケーション速度が向上するかもしれません。
>カスケードの判断は最後ですね。