Re: Measuring replay lag

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Measuring replay lag
Date: 2016-12-28 12:28:54
Message-ID: CAEepm=2=jCZ35+mhRYE1yN+F97p5BYo+V+Kx71Wu2xKaa3dQDg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Thu, Dec 22, 2016 at 10:14 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Thu, Dec 22, 2016 at 2:14 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> I agree that the capability to measure the remote_apply lag is very useful.
>> Also I want to measure the remote_write and remote_flush lags, for example,
>> in order to diagnose the cause of replication lag.
>
> Good idea. I will think about how to make that work.

Here is an experimental version that reports the write, flush and
apply lag separately as requested. This is done with three separate
(lsn, timestamp) buffers on the standby side. The GUC is now called
replication_lag_sample_interval. Not tested much yet.

postgres=# select application_name, write_lag, flush_lag, replay_lag
from pg_stat_replication ;
application_name | write_lag | flush_lag | replay_lag
------------------+-----------------+-----------------+-----------------
replica1 | 00:00:00.032408 | 00:00:00.032409 | 00:00:00.697858
replica2 | 00:00:00.032579 | 00:00:00.03258 | 00:00:00.551125
replica3 | 00:00:00.033686 | 00:00:00.033687 | 00:00:00.670571
replica4 | 00:00:00.032861 | 00:00:00.032862 | 00:00:00.521902
(4 rows)

--
Thomas Munro
http://www.enterprisedb.com

Attachment Content-Type Size
replay-lag-v15.patch application/octet-stream 37.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2016-12-28 12:31:33 Re: Support for pg_receivexlog --format=plain|tar
Previous Message Fabien COELHO 2016-12-28 12:11:40 Re: BUG: pg_stat_statements query normalization issues with combined queries