From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Paul Förster <paul(dot)foerster(at)gmail(dot)com> |
Cc: | "Wolff, Ken L" <ken(dot)l(dot)wolff(at)lmco(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Netapp SnapCenter |
Date: | 2020-06-22 17:00:55 |
Message-ID: | 20200622170054.GH3125@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Greetings,
* Paul Förster (paul(dot)foerster(at)gmail(dot)com) wrote:
> > On 22. Jun, 2020, at 17:46, Wolff, Ken L <ken(dot)l(dot)wolff(at)lmco(dot)com> wrote:
> > So apologies if this is a stupid question but there's obviously been a lot of discussion on this issue. Was a consensus ever reached on the following?
> >
> > If a Postgres database (both data and WAL) is located on one NetApp volume, meaning a snapshot should capture everything at exactly the same time with the required atomicity, do we still need to put the database into backup mode beforehand (and take it out afterwards)? If we don't put Postgres into backup mode first, will we still be able to use the WALs to roll transactions forward or would we be limited to only the point-in-time at which that snapshot was taken?
>
> you're absolutely fine with that as long as PGDATA and the pg_wal directory are located on the same volume. But you can't perform a PITR.
... and all tablespaces are also on that volume. Basically, anything
that PG might ever write to needs to all be included in that atomic
write.
> If you don't do pg_start_backup() then you won't be able to perform a PITR but if that's an "I-will-*DEFINITELY*-never-need-a-PITR" situation, then that's ok. Otherwise, from what I learned, you do a pg_start_backup(), then do the volume snapshot, and finally the pg_stop_backup() saving the output of the latter for PITR purposes.
Note that the output from pg_stop_backup() is absolutely essential for
the backup itself, not just if you want to do PITR.
As for doing PITR with such a snapshot, it's not something I'd recommend
as a general PITR-supporting backup strategy as it ends up being
complicated and very much has a risk associated with it that you'll end
up with a corrupted database if you don't manage it properly (and PG is
pretty limited in its ability to help you with this process..).
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-06-22 17:05:14 | Re: DISTINCT on jsonb fields and Indexes |
Previous Message | Tom Lane | 2020-06-22 16:54:38 | Re: ERROR: invalid memory alloc request size 18446744073709551613 |