Re: Core team statement on replication in PostgreSQL - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Core team statement on replication in PostgreSQL
Date
Msg-id 485654B7.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to Re: Core team statement on replication in PostgreSQL  (Greg Smith <gsmith@gregsmith.com>)
Responses Follow-up on replication hooks for PostgreSQL  (Robert Hodges <robert.hodges@continuent.com>)
List pgsql-hackers
>>> On Mon, Jun 9, 2008 at  9:48 PM, in message
<Pine.GSO.4.64.0806092243080.11286@westnet.com>, Greg Smith
<gsmith@gregsmith.com> wrote: 
> On Mon, 9 Jun 2008, Tom Lane wrote:
> 
>> It should also be pointed out that the whole thing becomes
uninteresting
>> if we get real-time log shipping implemented.  So I see absolutely
no
>> point in spending time integrating pg_clearxlogtail now.
> 
> There are remote replication scenarios over a WAN (mainly aimed at 
> disaster recovery) that want to keep a fairly updated database
without 
> putting too much traffic over the link.  People in that category
really 
> want zeroed tail+compressed archives, but probably not the extra
overhead 
> that comes with shipping smaller packets in a real-time
implementation.
We ship the WAL files over a (relatively) slow WAN for disaster
recovery purposes, and we would be fine with replacing our current
techniques with real-time log shipping as long as:
(1)  We can do it asynchronously.  (i.e., we don't have to wait for
WAN latency to commit transactions.)
(2)  It can ship to multiple targets.  (Management dictates that we
have backups at the site of origin as well as our central site.  A
failure to replicate to one must not delay the other.)
(3)  It doesn't consume substantially more WAN bandwidth overall.
A solution which fails to cover any of these leaves pg_clearxlogtail
interesting to us. 
-Kevin


pgsql-hackers by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
Next
From: "David E. Wheeler"
Date:
Subject: Re: Question about Encoding a Custom Type