NDB Cluster -- Not only can this use multiple machines in one cluster,
but you can have multiple clusters each taking writes.
This can lead to "conflicts" when writes go to multiple masters
'simultaneously'. NDB resolves them automatically, based on algorithms
that _you_ pre-specify. (Eg, "take the one with the earlier timestamp".)
Caveat: The "engine" is not quite the same as InnoDB, so you need to
learn about its quirks.
MMM -- Beware of recovery problems if one machine dies and cannot be
The biggest fear of single-Master (or Dual Master - singler writer, etc)
is when the real problem is a network issue. If you cannot get to the
'dead' Master to see that it really is dead, you don't dare promote some
other machine to be Master.
There are many 3rd party products that claim to go beyond out-of-the-box
MySQL Replication. But, look under there covers. Make sure you can
live with their subtle, hidden, limitations.
Remember, "semi-sync" is called "semi" for a reason.
Percona Cluster carries semi-sync a little closer to fully sync, but it
If you really must scale both reads and writes, and you are unwilling to
separate reads and writes, then maybe NDB Cluster is your first choice.
I would rather convince you to separate your reads and writes, while
avoiding problems with "critical reads".
On 4/2/12 1:22 PM, Wes Modes wrote:
> Howdy all.
> I am looking for a MySQL solution that allows us to horizontally scale a
> number of MySQL nodes as peers without separating reads and writes, or
> slaves and masters. This may not be ideal, but the application we are
> using is an unchangeable aspect of the project.
> I ran into this post by Giuseppe Maxia
> that details our concern exactly:
> MySQL Cluster... is a complex architecture to achieve high
> availability and performance. One of the advantages of MySQL Cluster
> is that each node is a peer to the others, whereas in a normal
> replicating system you have a master and many slaves, and
> applications must be careful to write only to the master...
> There are some cases where the MySQL Cluster is the perfect
> solution, but for the vast majority, replication is still the best
> Replication, too, has its problems, though:
> * There is a fastidious distinction between master and slaves.
> Your applications must be replication-aware, so that they will
> write on the master and read from the slaves. It would be so
> nice to have a replication array where you could use all the
> nodes in the same way, and every node could be at the same time
> master and slave.
> * There is the fail-over problem. When the master fails, it's true
> that you have the slaves ready to replace it, but the process of
> detecting the failure and acting upon it requires the
> administrator's intervention.
> Fixing these two misfeatures is exactly the purpose of this article.
> Using features introduced in MySQL 5.0 and 5.1, it is possible to
> build a replication system where all nodes act as master and slave
> at the same time, with a built-in fail-over mechanism.
> The article goes on to talk about setting up a Multimaster Replication
> At one point, I was lured into using the Multi-Master Replication
> Manager for MySQL (MMM) since it was said to be a set of scripts that
> made this process easier, but found that like standard replication made
> a distinction between masters and slaves, so I'm back to the original
> Giuseppe article.
> Anyone have experience setting up MySQL Multi-Master Replication? Or is
> there a better list to ask this question on?
Rick James - MySQL Geek