|
Hello All,
In an attempt to offload some of the pressure off our master postgres node,
We recently decided to start running reports off of our hot-standby.
There is a desire for these reports to return fairly current data, so we have been monitoring the replication delay between the master -> standby.
We currently have max_standby_archive_delay and max_streaming_archive_delay set to -1, to avoid any timeouts in the application (when pulling reports).
hot_standby_feedback is enabled on the slave node, but we are not currently setting vacuum_defer_cleanup_age.
95% of the time, the delay is only microseconds. But we have discovered that whenever the master does an auto vacuum of a large table, the transaction replay delay can climb is high as 1 hour. These delays don’t seem to correlate with any particular queries
that are running against the master or the standby, and the delay only subsides when the vacuum completes.
Does anyone have any recommendations for a configuration that can minimize the replay delays that occur during the vacuums of large tables.
--
Thank you,
Jeff McDowell
Email: Jeff.mcdowell@xxxxxxxxxxxxxxx
|
