On Sat, Aug 25, 2007 at 11:13:45AM -0400, Tom Lane wrote:
> In case you hadn't noticed the disconnect between these statements:
> if they have to be that close together, there *will* be a single point
> of failure. Fire in your data center, for instance, will take out every
> copy of your data. So as a "high availability" solution I don't find
> it all that compelling.
Indeed. There's another issue, too, which you have to spend some
time reading the manual to get. The clustering stuff is _yet
another_ table type, with subtly different semantics from other table
types. As usual, this means that you can blow off your foot by
mixing table types in a transaction. As near as I can tell, the
cluster table type (I disremeber the name of it) cannot be run in
strict mode, either.
To answer the OP's question, you can do some "cluster-like" things by
doing hardware clustering -- two machines attached to a RAID with
some sort of hardware fail-over in place.
I think that the MySQL cluster stuff wasn't intended as an HA
feature, though (although they might well be selling it that way).
It was a way to scale many small systems for certain kinds of
workloads. My impression is that in most cases, it's a SQL-ish
solution to a problem where someone decided to use the SQL nail
because that's the hammer they had. I can think of ways you could
use it, and I'm not surprised that Some Giant Corp is doing so. But
I'd be astonished if someone used it for truly valuable data. I
would think very hard about the qualifications of someone who
proposed using it for financial data.
A
--
Andrew Sullivan | ajs@xxxxxxxxxxxxxxx
Users never remark, "Wow, this software may be buggy and hard
to use, but at least there is a lot of code underneath."
--Damien Katz
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
