From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Bad recovery: no pg_xlog/RECOVERYXLOG |
Date: | 2017-11-02 04:23:07 |
Message-ID: | c37a48d3-05f0-9041-a586-fe7591c9154c@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 02/11/17 11:18, Stephen Frost wrote:
> Not having
> a way to reliably sync the WAL files copied by archive command to disk,
> in particular, really is an issue, it's not some feature, it's a
> requirement of a functional PG backup system. The other requirement for
> a functional PG backup system is a check to verify that all of the WAL
> for a given backup has been archived safely to disk, otherwise the
> backup is incomplete and can't be used.
>
>
Funnily enough, the original poster's scripts were attempting to address
(at least some) of this: he was sending stuff to swift, so if he got a
ok return code then it is *there* - that being the whole point of a
distributed, fault tolerant object store (I do swift support BTW).
I wonder if you are seeing this discussion in the light of folk doing
backups to unreliable storage locations (e.g: the same server, NFS etc
etc), then sure I completely agree with what you are saying (these issue
impact backup designs no matter what tool is used to write them).
Best wishes
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-11-02 11:11:41 | Re: Bad recovery: no pg_xlog/RECOVERYXLOG |
Previous Message | Mark Kirkwood | 2017-11-02 03:35:18 | Re: Bad recovery: no pg_xlog/RECOVERYXLOG |