From: | Dan Herzog <dherzog(at)marchex(dot)com> |
---|---|
To: | 'Murthy Nunna' <mnunna(at)fnal(dot)gov>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: How to determine replication lag |
Date: | 2014-08-07 19:59:31 |
Message-ID: | D577A90562E85348AD1D635F142053ABCFB8E2@exchbesea01.windows.marchex.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
I used the SQL from this link to determine replication lag:
http://www.dansketcher.com/2013/01/27/monitoring-postgresql-streaming-replication/
SELECT
CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location()
THEN 0
ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp()) END AS log_delay;
The one caveat is that if nothing else is committing changes and you have long running transactions that are generating wal, but have not committed, you will show a replication lag. As I understand it pg_last_xact_replay_timestamp() shows the last committed xact timestamp.
And Josh Berkus has done some nice write ups on replication lag:
http://www.databasesoup.com/2014/04/simplifying-replication-position.html
From | Date | Subject | |
---|---|---|---|
Next Message | Vasilis Ventirozos | 2014-08-08 08:00:23 | Re: How to determine replication lag |
Previous Message | Joseph Mays | 2014-08-07 19:39:29 | postgres-xc |