Postgresqlのslaveサーバ上で、terminating connection due to conflict with recovery というエラーをくらった時に調べることになる、 vacuum_defer_cleanup_age, max_standby_streaming_delay, hot_standby_feedback というパラメータについて、色々と調べたので、まとめてみました。ただ、まだ最終的な解には辿り着けていません。。
説明動画
AWS re:Invent 2015 | (DAT402) Amazon RDS PostgreSQL: Lessons Learned & New Features というセッションの一部でこのパラメータについて説明されていました。
https://www.youtube.com/watch?v=tZXp19q8RFo#t=31m55s
いつも文字でパラメータの説明を読んでいて、頭がこんがらがっていましたが、うまくvisualizeしてくれていて、とても分りやすい説明でした。
以下、動画で説明されていたことの要約
vacuum_defer_cleanup_age
- vacuumで消された行をどれくらいの間残しておくか。ただし、設定が時間単位ではなく、transaction数単位で、設定が難しいのであまり使われていない
max_standby_streaming_delay, max_standby_archive_delay
- slaveで実行中のqueryが必要とする行がvacuum対象となっている時、replication streaming or wal archiveの実行を中断し、queryの実行を優先させる際の最大のdelayの許容時間。
- 大きく設定すれば、queryは流れやすくなるが、delayが大きくなる可能性がある。
- 全sessionの累積なので、全てのtransactionでその挙動が保証されるわけではない。(ここはちょっと意味が聞き取りきれず、ドキュメントでも記載を見つけれなかった。)
- primaryの挙動に影響を与えないという点で、安心感があって人気がある。
hot_standby_feedback
- slaveからprimaryに実行中のqueryの情報を定期的に送信し、primaryはその情報を元に必要とされているrowをvacuumしないようにする。
- slave上のqueryはほぼ走りきるが、vacuumをブロックするので、disk容量が膨らむ可能性がある。
- プレゼンしてる人のおすすめ
But...
ここまでの説明を見た感じ、多少vacuumが実行されるのが遅くなろうと、hot_standby_feedback が最強かなと思って使ってみたのですが、pg_dumpを流していたらこんなエラーに遭遇。。
pg_dump: Error message from server: ERROR: canceling statement due to conflict with recovery
DETAIL: User was holding a relation lock for too long.
色々と検索して、このQAを見つけたのですが、
http://postgresql.nabble.com/Query-cancellation-on-hot-standby-because-of-buffer-pins-td5838689.html
Yes, you are confusing block and relation level locks. The contention
is at block level.
block level lock というのと、relation level locksというのの違いがわからず、行き詰まる & 結局 max_standby_streaming_delay, max_standby_archive_delayを指定しなければいけないのであれば、hot_standby_feedbackの存在意義が無いような気がしてきている <- 今ここ
引き続き調べてみて、何か分かったら更新したいと思います。。