Re: Replication - state of the art?

On Wed, Mar 01, 2006 at 11:28:06AM -0800, Bryce Nesbitt wrote:
> 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.

Then I suggest you use Slony-I.  While it is not plug and play, the
thing it _is_ designed to handle reasonably well is failover and
(better) switchover.  Most systems plan to solve that piece of
functionality later, with a script or something, at which point it is
apparent that setting up failover or swichover to be anything
approaching safe is actually very tricky.  (Log shipping is probably
not in this category, but AFAIK the promote-to-live support for a
standby database copy is still not all built by anyone.  If you like
rolling your own, however, it might be your answer.)

> 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?

The "no budget" remark here is what makes me strike CMD's Mammoth
Replicator off the list.  But I'm sure their administration tools are
far sweeter than the admittedly hackish ones that Slony currently
delivers out of the box.  

> nightly) into something more reasonable (like 500 milliseconds).  But
> risk -- of data corruption --
> and time --too much-- will can the project.

Another big reason to use a live-standby system like Slony is that
once you have the extra database online, you suddenly think of all
sorts of nifty queries you can move there without destroying your
production performance.  Be careful not to get addicted, is all.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca
Information security isn't a technological problem.  It's an economics
problem.    --Bruce Schneier