Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG
От | Mark Kirkwood |
---|---|
Тема | Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG |
Дата | |
Msg-id | c37a48d3-05f0-9041-a586-fe7591c9154c@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG
|
Список | 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 -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
В списке pgsql-admin по дате отправления: