Having built a custom cluster using vanilla MySQL + async replication, I can tell you that it's no walk in the park. Our requirement was to have the data shared across two data centers in different geographical areas with automated failover, and time from failure to failover completion of under 30 seconds. We managed to do this, but there were some very ugly parts. For one, we have no automated fail-back since promoting a slave, you lose the ability to deterministically figure out where other masters need to start replicating from (global TX IDs will solve this). We also get some false positives (much more than real failures) due to the fact that the cluster monitor has to be in yet a third geoarea. Lastly, this requires application support. We remedy this by having a common DB session layer and a messaging system for notifying all the applications of failures.
The good things about this are that we do get high availability with all the normal features of an RDMBS (JOINs, random queries, high-level query language, etc). We also have sharding baked-in so we get to distribute write queries across multiple masters. Having said that, the next time I need high availability I will be setting up either a two-node MySQL master-master cluster with mutual monitoring or some type of a different data store that provides eventual consistency.
