Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG
Дата
Msg-id 7966ee9e-2241-eced-4639-e32c157b915a@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 31/10/17 04:47, Stephen Frost wrote:
> Greetings,
>
> * Marcin Koziej (marcin@cahoots.pl) wrote:
>> Now it's fixed, but if anyone needs I'm attaching all scripts to 1)
>> backup and restore wal's and 2) backup and restore base backup from
>> OpenStack SWIFT
> Interesting, but these scripts seem to be seriously lacking in error
> checking (what happens if the copy to swift fails..?  or pg_basebackup
> fails?) and it's unclear how you can be sure that the WAL file has been
> sync'd to disk which is important or you might end up having holes in
> your WAL stream if the swift system fails.  There's also no checking to
> make sure that the WAL needed for a given pg_basebackup ever actually
> made it to the swift system, which is required to ensure you have a
> consistent backup.
>
> Generally speaking, these kinds of scripts really aren't a good choice
> for doing backups of PG.  I'd strongly suggest you look at one of the
> existing tools which are developed specifically for doing backups of PG
> and are well tested, supported, and maintained.  If you'd like support
> for a new storage system, I know that at least pgBackRest's storage
> layer is pluggable and adding a new storage option is pretty straight
> forward.
>
>
I'm not convinced that his approach is bad.

The script checks the result of the 'swift upload' for the base backup, 
it is the wal backup one that does not explicitly check the 'swift 
upload' result (this should really be added). To be fair, anything wrong 
with the swift system will likely be discovered immediately beforehand 
where he does a 'swift stat'!

I'd guess his original problem was an improperly setup recovery.conf, 
rather than the overall design.

regards

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 по дате отправления:

Предыдущее
От: "Ferrell, Denise D CTR NSWCDD, H11"
Дата:
Сообщение: Re: [Non-DoD Source] Re: [ADMIN] Database Error
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [ADMIN] Postgresql Upgrade from 9.3 to 9.4 failing