On Mon, May 14, 2018 at 11:33 AM, Flavio Henrique Araque Gurgel <fhagur@gmail.com> wrote:
Are you sure that wal streaming from primary is the main cause of replication lag?
Take a look at the pg_stat_replication view and compare values of sent, write and flush locations. If flush lags behind more than sent or write locations, queries running on your standby server may need rows that have been cleaned up by your vacuum process on your master and replication is held until those queries finish. If it's the case you may consider increasing parameters like vacuum_defer_cleanup_age (be aware that already deleted/updated rows will remain dead longer on your master) or consider not vacuuming too soon (you may need to modify autovacuum parameters if it's the case)
Pretty sure. The DR replica had no other activity and by HBA rule we don't allow any user activity here. There is a second cascading replica that developers can connect to for queries. It seems very plain at the time that the DR replica is just not receiving the WAL information fast enough. Once it has them it recover the changes very quickly.
wal_keep_files is set to 128 and it seems to blow through that in a minute or two when I ran the purge.
