Re: empty backup_label
Magnus Hagander <magnus@hagander.net>
From: Magnus Hagander <magnus@hagander.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Kerr <dmk@mr-paradox.net>, pgsql-hackers@postgresql.org
Date: 2012-06-26T15:33:42Z
Lists: pgsql-hackers
On Tue, Jun 26, 2012 at 5:24 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sun, Jun 24, 2012 at 5:33 PM, David Kerr <dmk@mr-paradox.net> wrote: >> Howdy, >> >> We're using NetApp's flexclone's whenever we need to move our DB between machines. >> >> One specific case where we do that is when we're creating a new streaming replication target. >> >> The basic steps we're using are: >> pg_start_backup(); >> <flex clone within the netapp> >> pg_stop_backup(); >> >> The problem i'm seeing is that periodically the backup_label is empty, which means >> I can't start the new standby. >> >> I believe that since the NetApp stuff is all happening within the SAN this file hasn't been >> fsynced to disk by the time we take the snapshot. >> >> One option would be to do a "sync" prior to the clone, however that seems kind of like a >> heavy operation, and it's slightly more complicated to script. (having to have a user >> account on the system to sudo rather than just connecting to the db to issue the >> pg_start_backup(...) ) >> >> Another option is to add pg_fsync(fileno(fp)) after the fflush() when creating the file (I'm not >> sure if fsync implies fflush or not, if it does you could just replace it.) >> >> I think this type of snapshot is fairly common, I've been doing them since 2000 with EMC, >> i'm sure that most SAN vendors support it. > > These seems like a good idea to me. Actually, I'm wondering if we > shouldn't back-patch this. > > Thoughts? Certainly can't hurt. I guess any other files that are lost this way will be recreated by WAL recovery - or is there something else tha tmight be of risk of similar treatment? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/