Re: PostgreSQL Failback without rebuild

I've just noticed that on PostgreSQL 9.3 I can do the following with a
master node A and a slave node B (as long as I have set
recovery_target_timeline = 'latest'):

1. Stop Node A
2. Promote Node B
3. Attach Node A as slave

This is sufficient for my needs (I know it doesn't cover a crash), can
anyone see any potential problems with this approach?

Cheers,

James Sewell,
PostgreSQL Team Lead / Solutions Architect
______________________________________

Level 2, 50 Queen St, Melbourne VIC 3000

*P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099

On Wed, Feb 5, 2014 at 6:03 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com>wrote:

> On Wed, Feb 5, 2014 at 3:14 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> > On Wed, Feb 5, 2014 at 10:30 AM, James Sewell <james(dot)sewell(at)lisasoft(dot)com
> >
> >> I've seen some proposals and a tool (pg_rewind), but all seem to have
> draw
> >> backs.
> >
> > As far as I remember, one of the main drawbacks for pg_rewind was
> related to
> > hint bits which can be avoided by wal_log_hints. pg_rewind is not part of
> > core
> > PostgreSQL code, however if you wish, you can try that tool to see if
> can it
> > solve your purpose.
> For 9.3, pg_rewind is only safe with page checksums enabled. For 9.4,
> yes wal_log_hints or checksums is mandatory. The code contains as well
> some safety checks as well to ensure that a node not using those
> parameters cannot be rewinded.
> Regards,
> --
> Michael
>

--

------------------------------
The contents of this email are confidential and may be subject to legal or
professional privilege and copyright. No representation is made that this
email is free of viruses or other defects. If you have received this
communication in error, you may not copy or distribute any part of it or
otherwise disclose its contents to anyone. Please advise the sender of your
incorrect receipt of this correspondence.