読者です 読者をやめる 読者になる 読者になる

postgresqlの "terminating connection due to conflict with recovery" に対応するためのパラメータ

FATAL: terminating connection due to conflict with recovery というエラーについて前書いてたけど、
PostgreSQLのFATAL: terminating connection due to conflict with recovery - seikoudoku2000のブログ
今更ながらに2015のRDS postgresqlのsessionを見てたら、2014の時よりしっかりと説明がされてたので、更新 & 自分の文字での情報を増やしてみた。
AWS re:Invent 2015 | (DAT402) Amazon RDS PostgreSQL: Lessons Learned & New Features - YouTube

この問題は、以下の3つのパラメータで対応可能。

  • vacuum_defer_cleanup_age
    • vacuumで消された行をどれくらいの間残しておくか。ただし、設定が時間単位ではなく、transaction数単位で、設定が難しいのであまり使われていない。
  • max_standby_streaming_delay
    • slaveで実行中のqueryが必要とする行がvacuum対象となっている時、replication streamingの実行を中断し、queryの実行を優先させる際の最大のdelayの許容時間。
      • 大きく設定すれば、queryは流れやすくなるが、delayが大きくなる可能性がある。
    • 全sessionの累積なので、全てのtransactionでその挙動が保証されるわけではない。(ここはちょっと意味が聞き取りきれず、ドキュメントでも記載を見つけれなかった。要確認。)
    • primaryの挙動に影響を与えないという点で、安心感があって人気がある。
  • hot_standby_feedback
    • slaveからprimaryに実行中のqueryの情報を定期的に送信し、primaryはその情報を元に必要とされているrowをvacuumしないようにする。
    • slave上のqueryはほぼ走りきるが、vacuumをブロックするので、disk容量が膨らむ可能性がある。
    • プレゼンしてる人のおすすめ

さらなる詳細は貼付けた動画+公式ドキュメントへ。


2016/05/12 追記。
あれこれと調べていたら、max_standby_streaming_delay が上手く動かない場合に関する、こんな記述を見つけた。`cumulative delay`ってのを上手く訳せないが、connection単位でのdelayではなく、流れているqueryの累計になるから、運が悪いとqueryはcancelされちゃうよってことかな。
https://books.google.co.jp/books?id=RmpGCgAAQBAJ&pg=PA100&lpg=PA100&dq=max_standby_streaming_delay+cumulative&source=bl&ots=RdP2-O09Yf&sig=8t_Ktyk7l-UxXql9j2wuNjOVzKg&hl=ja&sa=X&ved=0ahUKEwjjtI3Kg9TMAhWlqqYKHaZrA7kQ6AEIIDAB#v=onepage&q=max_standby_streaming_delay%20cumulative&f=false
```
These settings cover a cumulative delay.
That is, if there are ten queries pending, they don't get 30 seconds each to delay replication.
So a query might run for 10 milliseconds and got cancelled because it was unlucky to be at the end of the delay, causing the user to wonder what happened.
```