Bill Moran <wmoran@xxxxxxxxxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
