Re: Replication - state of the art?

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.