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
resuscitated.
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
is not.
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
(http://onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html)
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
choice.
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
System.
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?
Wes
--
Rick James - MySQL Geek
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
