Re: AW: [Extern] Re: consistent postgresql snapshot

Поиск
Список
Период
Сортировка
От kaido vaikla
Тема Re: AW: [Extern] Re: consistent postgresql snapshot
Дата
Msg-id CA+427g-3-w6TOoMyXi9yJBTvesD8gmtat2y68Ux7pe2YSRh1Mg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: AW: [Extern] Re: consistent postgresql snapshot  (Nick Cleaton <nick@cleaton.net>)
Список pgsql-general
Talking about fsfreeze and blocksize are not relevant in your case at all. 
You can't make a backup this way any way. According your mail, 
you are playing with database recovery after crash. Is pg crash proof? Yes (https://www.postgresql.org/docs/current/wal-intro.html).
You can use this solution for example to make a test environment and it works, 
but not for live database backup. 
For backup use a pg_basebackup or pg_start_backup()/snap/pg_stop_backup() solution
br
Kaido


On Thu, 12 May 2022 at 17:53, Nick Cleaton <nick@cleaton.net> wrote:
On Thu, 12 May 2022 at 14:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Zwettler Markus (OIZ)" <Markus.Zwettler@zuerich.ch> writes:
> I don't want to do use the normal backup algorithm where pg_start_backup + pg_stop_backup will fix any fractured block and I am required to have all archived logfiles, therefore.
> I want to produce an atomic consistent disk snapshot.

[ shrug... ]  You can't have that.  [snip]

The only way you could get a consistent on-disk image is to shut
the server down (being sure to do a clean not "immediate" shutdown)
and then take the snapshot.

I think you could work around that by taking a dirty snapshot, making a writable filesystem from it, waiting until you've archived enough WAL to get that to a consistent state, and then firing up a temporary postmaster on that filesystem to go through recovery and shut down cleanly.

В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Restricting user to see schema structure
Следующее
От: Bryn Llewellyn
Дата:
Сообщение: Re: Restricting user to see schema structure