A cluster running on good hardware with a good configuration, both tuned to the workload. We have customers who get very good performance and no downtime (ie. no total cluster failure).

There are a lot of disk writes with LCPs and redo logs but typically LCPs are quite slow writes (default 10MB/sec). With cluster being real-time the redo data (GCP) does need to be put to disk quickly, so fast disks are important for this aspect, especially on a database with a lot of writes. I would rather a lot of disk IO than the possibility of data loss.

Yes, that is possible if all nodes fail simultaneously, which is not something that is likely to happen with a well configured cluster.

NDB cluster does not really make sense for Data warehouse applications. There was a discussion on what is good for cluster on the mailing list, check out the thread that starts here: http://lists.mysql.com/cluster/6960. In terms of performance versus Oracle RAC I think they are very different solutions and really answer different problems. Tom Hanlon’s post in the thread sums up rather well what scales well with NDB.

Your write-up is pretty broad but it seems to gloss over some key issues.

1.) Maintenance. It’s the main cause of downtime for most sites. Solutions like DRBD or SAN that implement shared disk semantics don’t support it especially well. The reason is that if you only have a single copy of data you can’t do maintenance that requires both to be online.

2.) Uptime. I’m curious what is the basis for your up-time numbers. Uptime is a factor of your database, your admin procedures (e.g., heartbeat w/ VIP for failover vs. manual procedure with application reconfiguration), your ability to avoid configuration errors, etc. Also as @Ryan H pointed out, you can make unreliable things much more reliable by having many of them.

3.) Failures. Understanding types and consequences of failures is important. If NDB somehow does not work, your data are inaccessible with no easy fall-back solution. SANs fail in some strange and scary ways. They are also SPOFs. Approaches that create walled off copies are very robust across a lot of nasty failures. This is one of the big benefits of database replication, whether using MySQL or Tungsten Replicator.

4.) Backups. People tend to forget this is the first line of defense for data and jump straight to more complicated approaches.

I would like to invite you to have a look at Tungsten whenever you have time. We have a pretty broad view of availability and also take into consideration issues like data protection.

Robert

For geographical redundancy, I think replication is the best solution and it can be applied to all solutions. Losing some data when a whole goes down is usually acceptable. Even NDB cluster now support replication (row based only) and I have even done some experiments with NDB to InnoDB replication and, it works (not heavily tested).

I guess you meant “Since MyISAM is not ACID compliant” not “Since MySQL…”