Re: Clustering, mirroriing, or replication?

Most replication systems add a fair amount of complexity. How reliable are
current replication systems? Are they replication systems for performance
or for reliability+availability?

How much does it cost to make sure that the probability of both master and
failover machines failing is lower or as low as the probability of the
replication system failing? What would the impact be e.g. resulting
downtime etc?

I have seen some HA + load balancing firewall (not DB) systems which were
hardly worth the hassle - seemed to have just about the same amount of
downtime (if not more due to the added complexity and interactions with
other stuff -  e.g. buggy switches).

Some people have made similar mutterings about some DB clustering
solutions. Even if that's because they didn't do it right, it may be
because it's difficult to do it right, and that's not good is it? Could
just be a "feel good thing" that doesn't really add much to reliability for
all the added effort and overhead.

Does anyone know what's the most reliable platform postgresql can run on?
With or without scheduled downtime?

At 11:03 AM 8/12/2004 -0500, Jon Brisbin wrote:
>One option is to have the POS software always write to a local database,
>with that change getting replicated to all other active nodes.  Another
>option is to have a "master" database, with a failover as backup.  Downside
>here is that if both machines fail, then they are dead in the water.  We
>can't make money if the registers aren't operational.  However, this is
>similar to what happens now (which is why we want to change it.)
>
>Having mucked with postgres replication a little in the last couple of days,
>I'm starting to wonder just how long it will take us to develop a good
>replication mechanism.  If one is already in place, I'd just like to use
>that.  Or at least learn from someone else trying to set up something
>similar.