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.paqu...@gmail.com>wrote: > On Wed, Feb 5, 2014 at 3:14 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: > > On Wed, Feb 5, 2014 at 10:30 AM, James Sewell <james.sew...@lisasoft.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.
