public inbox for [email protected]
help / color / mirror / Atom feedFrom: Magnus Hagander <[email protected]>
To: Kevin Grittner <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: MauMau <[email protected]>
Cc: Josh Berkus <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Sample archive_command is still problematic
Date: Sun, 17 Aug 2014 21:51:57 +0200
Message-ID: <CABUevExpn2bvG3jpkKgAZefWk0iRvQrvH8nYmL2r-+8qLrQjYQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<0F73426A2EA544878BCAC33BB989D671@maumau>
<[email protected]>
<[email protected]>
<CABUevEwiaBWkgV+RX=Y77hauz-oKSo=7Tu7S7a8DN4dXGZSdTQ@mail.gmail.com>
<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>
On Sun, Aug 17, 2014 at 9:50 PM, Kevin Grittner <[email protected]> wrote:
> Magnus Hagander <[email protected]> wrote:
>
>> On Wed, Aug 13, 2014 at 11:23 PM, Kevin Grittner <[email protected]> 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/
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
view thread (25+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Sample archive_command is still problematic
In-Reply-To: <CABUevExpn2bvG3jpkKgAZefWk0iRvQrvH8nYmL2r-+8qLrQjYQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox