Re: Streaming replication failover/failback

From: Israel Brewster <israel(at)ravnalaska(dot)net>
To: Jehan-Guillaume de Rorthais <ioguix(at)free(dot)fr>
Cc: "pgsql-general(at)postgresql(dot)org general" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Streaming replication failover/failback
Date: 2016-11-17 17:32:01
Message-ID: DF6DA2C8-38C7-4880-9875-32535812855F@ravnalaska.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Nov 16, 2016, at 11:39 PM, Jehan-Guillaume de Rorthais <ioguix(at)free(dot)fr> wrote:
>
> On Wed, 16 Nov 2016 15:51:26 -0900
> Israel Brewster <israel(at)ravnalaska(dot)net <mailto:israel(at)ravnalaska(dot)net>> wrote:
>
>> I've been playing around with streaming replication, and discovered that the
>> following series of steps *appears* to work without complaint:
>>
>> - Start with master on server A, slave on server B, replicating via streaming
>> replication with replication slots.
>> - Shut down master on A
>> - Promote slave on B to master
>> - Create recovery.conf on A pointing to B
>> - Start (as slave) on A, streaming from B
>>
>> After those steps, A comes up as a streaming replica of B, and works as
>> expected. In my testing I can go back and forth between the two servers all
>> day using the above steps.
>>
>> My understanding from my initial research, however, is that this shouldn't be
>> possible - I should need to perform a new basebackup from B to A after
>> promoting B to master before I can restart A as a slave. Is the observed
>> behavior then just a "lucky fluke" that I shouldn't rely on?
>
> No, it's not a "lucky fluke".
>
> See
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=985bd7d49726c9f178558491d31a570d47340459 <https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=985bd7d49726c9f178558491d31a570d47340459>
>
> The only thing you should really pay attention is that the standby was in
> Streaming Rep when you instructed the master to shut down, and that it stays
> connected until the full stop of the master.
>
> If you really want to check everything, use pg_xlogdump on the standby and make
> sure the standby received the "shutdown checkpoint" from the master and wrote
> it in its WAL.
>
>> Or is it expected behavior and my understanding about the need for a new
>> basebackup is simply off?
>
> This is expected, but taking a new basebackup was a requirement for some time.
>
>> Does the new pg_rewind feature of 9.5 change things? If so, how?
>
> pg_rewind helps if your standby was not connected when you lost/stopped your
> master. It reverts the last transactions the master received and that was not
> streamed to the promoted standby.

Ah, ok. So kinda an emergency recovery tool then? One step before resorting to backups? In any case, it sounds like it's not something I should need in a *normal* failover scenario, where the master goes down and the slave gets promoted.

Thanks for the information!
-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
-----------------------------------------------
>
> Regards,
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org <mailto:pgsql-general(at)postgresql(dot)org>)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general <http://www.postgresql.org/mailpref/pgsql-general>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message kbrannen 2016-11-17 18:19:33 Re: help with moving tablespace
Previous Message Israel Brewster 2016-11-17 17:26:59 Re: Streaming replication failover/failback