3.2.1. Preparing Hosts for Multimaster

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 my.cnf file:

    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 your my.cnf file:

    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.