Re: Netapp SnapCenter

From: Paul Förster <paul(dot)foerster(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: "Wolff, Ken L" <ken(dot)l(dot)wolff(at)lmco(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Netapp SnapCenter
Date: 2020-06-18 16:49:32
Message-ID: 2C6D03C3-CFF0-4F14-BA83-A2809BA29196@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Magnus,

> On 18. Jun, 2020, at 16:19, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> I don't know specifically about SnapCenter, but for snapshots in general, it does require backup mode *unless* all your data is on the same disk and you have an atomic snapshot across that disk (in theory it can be on different disk as well, as long as the snapshots in that case are atomic across *all* those disks, not just individually, but that is unusual).

according to what I know from our storage guys, Netapp does atomic snapshots for each volume. We have the database and its corresponding WAL files (pg_wal directory) on the same volume and the archived WALs (archive_command) on another. And the snapshots on those two volumes are not taken at the same time. Currently, the database is set to backup mode (using cron) and the storage guys have a window during which they can take the snapshots.

> So the upthread suggestion of putting data and wal on different disk and snapshoting them at different times is *NOT* safe. Unless the reference to the directory for the logs means a directory where log files are copied out with archive_command, and it's actually the log archive (in which case it will work, but the recommendation is that the log archive should not be on the same machine).

as I said above, pg_wal is a directory in PGDATA at the default location and WALs are archived using the archive_command to a different volume. So I guess, we should be safe then.

> The normal case is that snapshots are guaranteed to be atomic, and thus this millisecond window cannot appear. But that usually only applies across individual volumes. It's also worth noticing that taking the backups without using the backup mode and archive_command means you cannot use them for PITR, only for restore onto that specific snapshot.
>
> While our documentation on backups in general definitely needs improvement, this particular requirement is documented at https://www.postgresql.org/docs/current/backup-file.html.

since we use backup mode, we should be good with PITR too. I didn't test that myself, but a workmate did and he said it worked nicely.

So bottom line, SnapCenter means for PostgreSQL just a plain volume snapshot like we currently do with SnapCreator, using backup mode scripts and "archive_command"-ing WALs to a diffent volume, i.e. no change in strategy. It's just that SnapCenter can't control backup mode as it can with Oracle.

Thanks for the invaluable input. Also, thanks Ken.

Cheers,
Paul

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michel Pelletier 2020-06-18 17:34:51 Re: Hiding a GUC from SQL
Previous Message Michel Pelletier 2020-06-18 16:40:20 Re: Hiding a GUC from SQL