Re: Replication slot and pg_rewind

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: "Bhattacharyya, Subhro" <s(dot)bhattacharyya(at)sap(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Replication slot and pg_rewind
Date: 2017-06-06 03:19:35
Message-ID: CAB7nPqRPQjpSrwC+cPR6Y-VUsPBHsrDWLAfuaxfpAC6ARg6Osg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Jun 6, 2017 at 12:03 PM, Bhattacharyya, Subhro
<s(dot)bhattacharyya(at)sap(dot)com> wrote:
> We are using the replication slot and pg_rewind feature of postgresql 9.6
> Our cluster consists of 1 master and 1 slave node.
>
> The replication slot feature allows the master to keep as much WAL as is
> required by the slave.
>
> The pg_rewind command uses WALs to bring the slave in sync with the master.
> By using replication slots there are always enough WAL in the pg_xlog.
>
> In this case is it safe to use pg_rewind without WAL archiving?
> Can there be a situation where pg_rewind fails?

When pg_rewind runs it looks at the WAL from the last checkpoint
before WAL diverged on the *target* node, not the source. So retaining
the WAL data on the primary after the standby has been promoted makes
little sense from this point of view. Even worse, once the promoted
standby decides to recycle the past WAL segments you won't be able to
do a rewind of the previous primary because there is no way to know
what are the blocks modified on the standby since the point of
divergence.
--
Michael

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bhattacharyya, Subhro 2017-06-06 04:52:19 Re: Replication slot and pg_rewind
Previous Message Bhattacharyya, Subhro 2017-06-06 03:03:05 Replication slot and pg_rewind