On Sun, Aug 17, 2014 at 9:50 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> Magnus Hagander <magnus@hagander.net> wrote:
>
>> On Wed, Aug 13, 2014 at 11:23 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
>
>>
>>> The above is regarding WAL file archiving -- I'm not putting down
>>> streaming replication. Of course, what I would have *really* liked
>>> is a WAL receiver that could write out normal-looking WAL files for
>>> archiving purposes and pass through the WAL stream to a hot
>>> standby. Last I checked (which was admittedly at least a couple
>>> years back) there was no such utility, although I seem to remember
>>> that Magnus had done some work that looked like it could be bent to
>>> that end.
>>
>> I did. But I think that has mostly been superceded by replication
>> slots now. As in, if you use pg_receivexlog with a specific
>> replication slot, I believe you no longer need archive command at all,
>> do you? Since the replication slot will block rotation of the WAL
>> files until they are actually archived by pg_receivexlog (What my
>> command did was have an archive command that looked back into
>> pg_stat_replication to see if pg_receivexlog had received the data or
>> not).
>>
>> It did not pass through any WAL stream though - you'd have your
>> standby connect directly to the same master that pg_receivexlog
>> connects to. What would be the actual reason for having that one do
>> the passthrough itself?
>
> The use case was to maintain both a hot standby and a set of WAL
> files to allow PITR recovery (e.g., to recover to just before some
> catastrophic SQL command was executed) to a remote site across a
> *slow* WAN connection. Rather than send the WAL across the slow
> connection twice they would ship and apply WAL files and suffer the
> consequent replication delay to the hot standby; but if the standby
> could be done through streaming replication and the WAL files could
> still be re-created off of the same stream, that would be better.
>
> Basically, where bandwidth is limited and expensive, you don't want
> to have to send the same WAL data over the same connection more
> than once.
Oh, now I remember. Different usecase, different tool :)
That said, you can almost get there with pg_receivexlog - have it
create the archives ,and use non-streaming replication on the slave...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
