Delaying, pausing, and synchronizing replication
Some advanced features and thoughts for replication are covered here.
Getting ready
If you have multiple standby servers, you may want to have one or more servers operating in a delayed apply state—for example, one hour behind the primary. This can be useful to help recover from user errors such as mistaken transactions or dropped tables without having to perform a PITR.
How to do it…
Normally, a standby will apply changes as soon as possible. When you set the recovery_min_apply_delay
parameter in postgresql.conf
, the application of commit records will be delayed by the specified duration. Note that only commit records are delayed, so you may receive Hot Standby cancelations when using this feature. You can prevent that in the usual way by setting hot_standby_feedback
to on
, but use this with caution since it can cause significant bloat on a busy primary if recovery_min_apply_delay
is large.
If something...