On Thu, Dec 30, 2010 at 13:30, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> On Thu, Dec 30, 2010 at 6:41 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> As the README says that is not self-contained (for no fault of its own) and
>>> one should typically set archive_command to guarantee zero WAL loss.
>> Yes. Though you can combine it fine with wal_keep_segments if you
>> think that's safe - but archive_command is push and this tool is pull,
>> so if your backup server goes down for a while, pg_streamrecv will get
>> a gap and fail. Whereas if you configure an archive_command, it will
>> queue up the log on the master if it stops working, up to the point of
>> shutting it down because of out-of-disk. Which you *want*, if you want
>> to be really sure about the backups.
> I was thinking I'ld like use pg_streamrecv to "make" my archive, and
> the archive script on the master would just "verify" the archive has
> that complete segment.
> This get's you an archive synced as it's made (as long as streamrecv
> is running), and my "verify"archive command would make sure that if
> for some reason, the backup archive went "down", the wal segments
> would be blocked on the master until it's up again and current.
That's exactly the method I was envisionning, and in fact that I am
using in a couple of cases - jus thaven't documented it properly :)
Since pg_streamrecv only moves a segment into the correct archive
location when it's completed, the archive_command only needs to check
if the file *exists* - if it does, it's transferred, if not, it
returns an error to make sure the wal segments don't get cleaned out.
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-12-30 13:24:10|
|Subject: Re: Re: Vacuum of newly activated 8.3.12 standby receives
warnings page xxx is uninitialized --- fixing|
|Previous:||From: Joachim Wieland||Date: 2010-12-30 12:31:47|
|Subject: Snapshot synchronization, again...|