Re: Streaming replication failover/failback - Mailing list pgsql-general

From Israel Brewster
Subject Re: Streaming replication failover/failback
Date
Msg-id 73180B27-D2C2-48DF-AC07-381B3BCCD0AA@ravnalaska.net
Whole thread Raw
In response to Re: Streaming replication failover/failback  (Jehan-Guillaume de Rorthais <ioguix@free.fr>)
List pgsql-general
On Nov 18, 2016, at 5:48 AM, Jehan-Guillaume de Rorthais <ioguix@free.fr> wrote:

On Thu, 17 Nov 2016 08:26:59 -0900
Israel Brewster <israel@ravnalaska.net> wrote:

On Nov 16, 2016, at 4:24 PM, Adrian Klaver <adrian.klaver@aklaver.com>
wrote:

On 11/16/2016 04:51 PM, Israel Brewster 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  

You don't say how active the database is, but I going to say it is not
active enough for the WAL files on B to go out for scope for A in the time
it takes you to do the switch over.  

Yeah, not very - this was just in testing, so essentially no activity. So
between your response and the one from Jehan-Guillaume de Rorthais, what I'm
hearing is that my information about the basebackup being needed was
obsoleted with the patch he linked to, and as long as I do a clean shutdown
of the master, and don't do too much activity on the *new* master before
bringing the old master up as a slave (such that WAL files are lost)

Just set up wal archiving to avoid this (and have PITR backup as a side effect).

Good point. Streaming replication may not *need* WAL archiving to work, but having it can provide other benefits than just replication. I'll have to look more into the PITR backup though - that's something that sounds great to have, but I have no clue, beyond the concept, how it works. :-)

-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
-----------------------------------------------



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: pg_basebackup on slave running for a long time
Next
From: Subhankar Chattopadhyay
Date:
Subject: Re: pg_basebackup on slave running for a long time