Re: empty backup_label - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: empty backup_label
Date
Msg-id CABUevEwaKgdLsJGUN1SxszBXpPfHVB8vRtWyyVta0WZgaXeV_g@mail.gmail.com
Whole thread Raw
In response to Re: empty backup_label  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: empty backup_label
Re: empty backup_label
List 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/


pgsql-hackers by date:

Previous
From: Euler Taveira
Date:
Subject: Re: libpq compression
Next
From: Tom Lane
Date:
Subject: Re: libpq compression