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.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
