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