On Thu, Dec 30, 2010 at 13:30, Aidan Van Dyk <aidan@highrise.ca> wrote:
> On Thu, Dec 30, 2010 at 6:41 AM, Magnus Hagander <magnus@hagander.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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/