Re: Calculating Replication Lag - units

From: David Kerr <dmk(at)mr-paradox(dot)net>
To: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Calculating Replication Lag - units
Date: 2012-06-25 23:21:09
Message-ID: 20120625232107.GB44266@mr-paradox.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jun 25, 2012 at 02:17:22PM -0700, Steve Crawford wrote:
- On 06/25/2012 01:17 PM, David Kerr wrote:
- >Howdy,
- >
- >When calculating Replication lag, I know that we have to compare the
- >pg_current_xlog_location
- >to pg_last_xlog_receive_location, etc. but what I'm trying to figure out
- >is what are
- >the units that I'm left with after the calculation.
- >
- >(i.e., does the xlog_location imply some time value?)
- >
- >Here's the output of the (slightly modified script)
- >Master: 5003964876715
- >Receive: 5003964876715
- >Replay: 5003964765203
- >
- >receive.value 0
- >apply.value 111512
- >
- >111512 isn't inherently useful to me on its own.
- >
- >Any tips?
- >
- How about now()-pg_last_xact_replay_timestamp() (however this can be a
- large number if there have not been any recent transactions on the
- master). I suppose you could do something like:
-
- case when pg_last_xlog_receive_location() =
- pg_last_xlog_replay_location() then '0 seconds'::interval
- else now()-pg_last_xact_replay_timestamp() end as log_delay;

i don't know for sure that 111512 is a time value.. that's kind of
what i'm wondering. If i knew that it was like miliseconds or something
that would be helpful.

- But I'm wrapping my head around some replication issues myself so others
- may have better ideas or corrections.

I've been fairly successful with replication so I'm happy to help there.
Just trying to shore up my monitoring now!

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steve Crawford 2012-06-25 23:47:10 Minimal streaming replication
Previous Message Mark Rostron 2012-06-25 23:08:27 Re: db server processes hanging around