Re: Streaming Replication Networking Best Practices?

On Mon, May 14, 2018 at 11:33 AM, Flavio Henrique Araque Gurgel <
fhagur(at)gmail(dot)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.

--
Don Seiler
www.seiler.us