| From: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Calculating Replication Lag - units |
| Date: | 2012-06-25 21:17:22 |
| Message-ID: | 4FE8D562.8030609@pinpointresearch.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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;
But I'm wrapping my head around some replication issues myself so others
may have better ideas or corrections.
Cheers,
Steve
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Rostron | 2012-06-25 23:08:27 | Re: db server processes hanging around |
| Previous Message | David Kerr | 2012-06-25 20:17:22 | Calculating Replication Lag - units |