In a regular replication setup one host is the replication master with one or more slaves. Which creates a single point of failure the master. 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.

This guide only works with MyISAM table types (the default for MySQL).

This guide is aimed at users who have setup a master slave replication. If this is not the case please read the following howto.

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. Please make sure you emerge mysql 5.x before you continue.

One hard-to-solve problem in a multimaster replication is the conflict that can happen with self-generated keys. The AUTO_INCREMENT feature is quite convenient, but in a replication environment it will be disruptive. If node A and node B both insert an auto-incrementing key on the same table, conflicts arise immediately. MySQL 5 introduces a couple of server variables for replicated auto-increment that address this specific problem and allow for the creation of an array of peer-to-peer nodes with MySQL replication.

By choosing non-conflicting values for these variables on different masters, servers in a multiple-master configuration will not use conflicting AUTO_INCREMENT values when inserting new rows into the same table. To set up N master servers, set the variables like this:

* Set auto_increment_increment to N on each master.
* Set each of the N masters to have a different auto_increment_offset, using the values 1, 2, ... , N.

Using those two variables as described in the manual, you can ensure that all nodes in your replication array will use different sequences of auto-incrementing numbers. For example, using auto_increment_increment = 10 and auto_increment_offset=3, the numbers generated when inserting three records will be 3, 13, 23. Using 10, 7, you'll get 7, 17, 27, and so on.
For my two-node array, I set auto_increment_increment to 10 for each node, and auto_increment_offset to 1 in the first node and 2 in the second.

Stop both mysql servers if you have a running master slave replication and edit the file

The server ID, must be different for each node the auto_increment_increment, the same for all the nodes. The auto_increment_offset, must also be different on each host to guarantee the uniqueness of self-generated keys.
A few variables are worth noting in these configuration files. The first is log-slave-updates. This option tells each server to write the changes that it receives from its master through the relay binary log to its own binary log. Without it, cascade replication doesn't work. The option replicate-same-server-id has the purpose of avoiding infinite replication loops, effectively telling each node to ignore from its master's binary log any statement that originated with its own server ID.
auto_increment_increment and auto_increment_offset have the appropriate values, as explained earlier. The rest is normal replication administration.