Re: Simultaneously streaming database replication and pg_dump, yet observing zero lag

From: Andres Freund <andres(at)anarazel(dot)de>
To: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
Cc: Matt Patey <matt(dot)patey(at)ableton(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Simultaneously streaming database replication and pg_dump, yet observing zero lag
Date: 2015-04-30 14:54:20
Message-ID: 20150430145420.GD2658@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On 2015-04-30 08:08:22 -0600, Scott Ribe wrote:
> On Apr 30, 2015, at 8:00 AM, Matt Patey <matt(dot)patey(at)ableton(dot)com> wrote:
> >
> > We have a streaming replication setup, where the replication slave runs pg_dump every hour. Our lag monitor shows an expected sawtooth shape, where pg_dump runs coincide with a climbing lag, which ends abruptly when pg_dump is finished. This is, to the best of my knowledge, expected behaviour. The lag pattern occasionally disappears though, and when looking at system processes we see that the database is recovering WAL data, and pg_dump is also running. How is this even possible?
>
> Any query (and pg_dump is a series of queries) does not necessarily
> block recovery. AFAIK, it’s only when the query requires a version of
> a row which would be removed by WAL replay that the recovery gets
> blocked. So it’s possible for pg_dump to not block recovery, but in
> any reasonably active db I think it’s unlikely—exactly what you’re
> seeing.

Right. And incidences of thta can be greatly reduced by enabling
hot_standby_feedback on the standby.

Greetings,

Andres Freund

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Matt Patey 2015-04-30 15:13:21 Re: Simultaneously streaming database replication and pg_dump, yet observing zero lag
Previous Message Scott Ribe 2015-04-30 14:08:22 Re: Simultaneously streaming database replication and pg_dump, yet observing zero lag