From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | James Sewell <james(dot)sewell(at)jirotech(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_rewind issue |
Date: | 2017-09-07 23:04:30 |
Message-ID: | CAB7nPqR+dKUm8bmt4bab3jxYxk5HhSE6txvQBzWjuSbRA4KCgA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Sep 7, 2017 at 9:06 PM, James Sewell <james(dot)sewell(at)jirotech(dot)com> wrote:
> A client has have been having problems with pg_rewind.
>
> They have two PostgreSQL (Oracle Enterprise Linux 7, 9.6.4) nodes in
> streaming replication and follow these steps:
>
> 1. Stop the master
> 2. Promote the standby
> 3. After successful failover wait some time (a lot of data is written)
> 4. Issue a checkpoint on the new master
> 5. Issue a pg_rewind on the old master
> 6. Start up the old master with a recovery.conf pointing at the new master.
How are you stopping the primary at step 1)? If you stopped it
cleanly, then it had the occasion to send to the standby the WAL
record corresponding to the shutdown checkpoint, so at step 2) the
standby would use a WAL history that has not forked from the primary
when it is promoted, so the ex-primary could be reused as-is as a
standby. Hence step 5 would not be necessary.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Johnson | 2017-09-08 03:48:52 | B-tree index on a VARCHAR(4000) column |
Previous Message | Jeff Janes | 2017-09-07 22:23:09 | Re: Performance with high correlation in group by on PK |