public inbox for [email protected]
help / color / mirror / Atom feedFrom: Kevin Grittner <[email protected]>
To: Magnus Hagander <[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 12:50:30 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CABUevEwiaBWkgV+RX=Y77hauz-oKSo=7Tu7S7a8DN4dXGZSdTQ@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<0F73426A2EA544878BCAC33BB989D671@maumau>
<[email protected]>
<[email protected]>
<CABUevEwiaBWkgV+RX=Y77hauz-oKSo=7Tu7S7a8DN4dXGZSdTQ@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>
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.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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: <[email protected]>
* 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