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

[Sonoda Masaki]

園田と申します。

> 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) で
実装されると、レプリケーション速度が向上するかもしれません。
カスケードの判断は最後ですね。