Message-ID: <4405F5C6.1040300@obviously.com>
Date: Wed, 01 Mar 2006 11:28:06 -0800
From: Bryce Nesbitt <bryce1@obviously.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
MIME-Version: 1.0
To: pgsql-sql@postgresql.org
Subject: Re: Replication - state of the art?
References: <20060301133041.8EFFA19B797@smtp03l.fasthosts.co.uk>
	<4405DF32.4070307@obviously.com>
	<20060301182803.GK17356@phlogiston.dyndns.org>
In-Reply-To: <20060301182803.GK17356@phlogiston.dyndns.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Andrew Sullivan wrote:
> On Wed, Mar 01, 2006 at 09:51:46AM -0800, Bryce Nesbitt wrote:
>   
>> switch over and rebuild the DB.  "No-lost transaction" is far more
>> important than switch time.
>>     
>
> You can't guarantee that without two phase commit, no matter what you
> do.  Log shipping doesn't require you to have an active database
> running on the origin (slony-1 does, which is one of its potential
> drawbacks).  But that won't help you if a transaction committed at
> the instant an earthquake hit your datacentre, wiping it out.  You
> can't get the data off the failed origin no matter what. 
>   
Actually let me loosen that a bit:  we don't need two phase commit.  We
can loose the most recent transaction, or even the last few seconds of
transactions.  What we can't survive is -- on the day of the emergency
-- a long and complicated DB rebuild with mistakes and hard-to-debug
data issues.

>> Anyone here using replication or transaction journaling?  Has it proved
>> reliable, easy to maintain?
>>     
>
> Define "easy".  Every possible replication system is going to have
> slightly grotty corners into which you find yourself wandering.  The
> question is merely whether the room is octagonal or merely
> rectangular.
>   
There's no fire creating demand for replication, so there is little time
budget.
So is there a sort of padded, no-sharp-corners, playroom that gets us
90% of the way there?

We're looking to reduce what's now a 24 hour window on data loss (since
the most recent
nightly) into something more reasonable (like 500 milliseconds).  But
risk -- of data corruption --
and time --too much-- will can the project.