From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Paul Förster <paul(dot)foerster(at)gmail(dot)com> |
Cc: | James Sewell <james(dot)sewell(at)jirotech(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Safe switchover |
Date: | 2020-07-10 15:45:56 |
Message-ID: | 20200710154556.GL12375@tamriel.snowman.net |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Greetings,
* Paul Förster (paul(dot)foerster(at)gmail(dot)com) wrote:
> > On 10. Jul, 2020, at 17:29, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Patroni also has the option to use pgbackrest instead of pg_rewind.
>
> right. Sorry, I forgot about that. We use pg_rewind which works great.
Sure, if you know exactly why the former primary failed and have
confidence that nothing actually bad happened then pg_rewind can work
(though it's still not what I'd generally recommend).
If you don't actually know what happened to the former primary to cause
it to fail then I definitely wouldn't use pg_rewind on it since it
doesn't have any checks to make sure that the data is actually
generally consistent. These days you could get a bit of a better
feeling by running pg_checksums against the data dir, but that's not
going to be as good as doing a pgbackrest delta restore when it comes to
making sure that everything is valid.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | rwest | 2020-07-10 15:53:11 | PG Admin 4 |
Previous Message | Paul Förster | 2020-07-10 15:31:47 | Re: Safe switchover |