Bill Moran <wmoran@potentialtech.com> writes:
> First off, "clustering" is a word that is too vague to be useful, so
> I'll stop using it.
Right. MySQL Cluster, on the other hand, is a very specific technology.
http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster.html
It's interesting but far from an all-purpose solution. I am no expert
but I believe these are true statements:
* The data is all kept in memory, with *no* on-disk backup. This is why
it's so fast. As for reliability, the rationale is that if you have
enough replicated nodes then you'll never lose all of them at once.
* It's a synchronous multi-master system, meaning that performance is
only good if there is very low communication delay between the nodes.
Not only do they have to be all on the same LAN segment, MySQL says
it had better be at least 100MB Ethernet.
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.
It is, however, capable of being d*mn fast for read-mostly workloads
that can fit their whole dataset into RAM --- and with the price of
RAM what it is, that's not such a big limitation, though remember you
need N servers with that much RAM not only one. (For write-mostly
workloads I imagine it doesn't scale out so well, because of the
costs of updating multiple servers synchronously.)
regards, tom lane