On Tue, May 20, 2008 at 02:09:28PM +1000, Glen Edmonds wrote:
> 
> Here's my basic problem with slony and why I think it is not yet
> "industrial strength":
>  
> Despite what the home page says, Slony is absolutely not a clustering
> solution.  It is a replication solution.  For any database to have true
> high availability (achievable 24/7 up time), it must have a clustering
> solution.  Put simply, a cluster has these things:

Well, I think this depends pretty heavily on whatever local definition of
"cluster", "industrial", and "24/7 uptime" you have.

It sounds like what you want is a multi-machine cluster of databases with
multiple members in read/write mode, with some kind of failure detection
that takes over transactions in the event of the loss of a cluster member. 

As I like to tell customers, if you actually need Oracle's RAC, go buy it.
It's an excellent product.  In spite of what some sales people may initially
tell you, it _will not_ provide the fabled five nines, and Oracle Corp.
actually sign a contract with you guaranteeing it does last I checked.  That
said, it seems like a good system to me, and I've never heard anything from
users of it that suggested it didn't work reasonably well ("except when it
doesn't", of course) in local-net scenarios.  (I have heard several very
painful stories about metronet deployments.)

If you want to do this with Postgres, I encourage you to go find Markus, and
start sponsoring work (or pay him to release his work) on Postgres-R.

If you want to describe your actual goals rather than describe a specific
implementation of some technology, then I may have some suggestions on what
you can do to realise those goals.  I don't expect any of it will look much
like Oracle's much-patented system, however.

I will note one other thing, however:

> Basically, you can add and remove servers whenever you like, and because
> there's no single point of failure, it can stay up 24/7.

I think you have a remarkably naïve view of how reliable systems are
designed.  Hint: a very complicated technology with "no single point of
failure" does not entail a reliable system. 

A