From: | Paul Förster <paul(dot)foerster(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
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-13 16:05:59 |
Message-ID: | 682CD01B-41A6-42F0-9FCB-41F35D431F3E@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Stephen,
> On 13. Jul, 2020, at 18:00, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> A pgbackrest delta restore will scan the entire data directory and
> verify every file matches the last backup, or it'll replace the file
> with what was in the backup that's being used. If there's an error
> during any of that, the restore will fail.
ok, I didn't know that. Thanks very much. I'll look into it.
> That re-validation of the entire data directory is a pretty huge
> difference compared to how pg_rewind works.
I agree.
> Ah, yes, if you rebuild the replica from a backup (or from the primary),
> then sure, that's pretty similar to the pgbackrest delta restore, except
> that when using delta restore we're only rewriting files that have a
> different SHA checksum after being scanned, and we're pulling from the
> backup repo anything that's needed and not putting load on the primary.
so, from what I understand, pgbackrest bottom line merely reduces copy overhead in such a particular case. *Kind of* like shutdown primary, rsync, and then startup.
> There's been a few discussions on -hackers about this, that'd probably
> be the place to discuss it further..
I'm not hacker, I'm just a DBA. :-)
Cheers,
Paul
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-07-13 16:07:42 | Re: Safe switchover |
Previous Message | Stephen Frost | 2020-07-13 16:00:53 | Re: Safe switchover |