Some considerations must be taken into account for any multi-master scenario:
For tables that use auto-increment, collisions are possible if two
hosts select the same auto-increment number. You can reduce the
effects by configuring each MySQL host with a different auto-increment
settings, changing the offset and the increment values. For example,
adding the following lines to your
auto-increment-offset = 1 auto-increment-increment = 4
In this way, the increments can be staggered on each machine and collisions are unlikely to occur.
Use row-based replication. Statement-based replication will work in
many instances, but if you are using inline calculations within your
statements, for example, extending strings, or calculating new values
based on existing column data, statement-based replication may lead to
significant data drift from the original values as the calculation is
computed individually on each master. Update your configuration file
to explicitly use row-based replication by adding the following to
binlog-format = row
Beware of triggers. Triggers can cause problems during replication because if they are applied on the slave as well as the master you can get data corruption and invalid data. Tungsten Replication cannot prevent triggers from executing on a slave, and in a multi-master topology there is no sensible way to disable triggers. Instead, check at the trigger level whether you are executing on a master or slave. For more information, see Section C.3.1, “Triggers”.
Ensure that the
server-id for each
MySQL configuration has been modified and is different on each host.
This will help to prevent the application of data originating on the a
server being re-applied if the transaction is replicated again from
another master after the initial replication. Tungsten Replication is
designed not to replicate these statements, and uses the server ID as
part of the identification process.