The Ultimate Guide to High Availability with MariaDB

Multi-Master ring replication

You are viewing an old version of this article. View the current version here.

The terms master and slave have historically been used in replication, and MariaDB has begun the process of adding primary and replica synonyms. The old terms will continue to be used to maintain backward compatibility - see MDEV-18777 to follow progress on this effort.

Contents

  1. What is Multi-master ring replication
  2. Configuring the Masters

What is Multi-master ring replication

Multi-master "ring" replication means that you have 2 or more master where each master is replicating its data to one another master asynchronously. This is not to be confused with MariaDB Galera clusters which is a virtually synchronous multi-primary cluster for MariaDB.

The benefit of asynchronous replication compared to Galera cluster , is that ring replication is resilient against bad connections. If a connection goes down, all masters will continue to serve it's clients and data will automatically be synced when the link is again available.

The following picture shows one of the more advanced multi-master setups that is resilient against any master going down but can also handle 'human failures', like an accidental drop table, thanks to the delayed slaves.

One should setup replication on each masters like one does in standard MariaDB replication. The replication setup among the masters should be a ring. In other words, each master should replicate to one other master and each master should only have one other master as a slave.

Each master can of course have one or more normal slaves. A master could also be a slave of other master not in the ring setup.

All MariaDB servers supports multi-master ring replication. In fact, when MySQL replication was originally designed around year 2000, it was to be a multi-master-ring replication solution for Yahoo to replicate from the East coast to the West coast.

Configuring the Masters

First follow the instructions in setup replication. The main thing to remember is to use the master_use_gtid=current_pos option for CHANGE MASTER.

The main things that are different for multi master ring replication are:

  • Give every master and slave in the replication setup a unique server_id. This can be a number from 1 to 4294967295. It a good practice to ensure that you do not have any servers in your system with the same server_id!
  • Use global transaction id (as described above)
  • Give each master a unique gtid_domain_id. This will allow replication to apply transactions from different master in parallel independent from other masters.

Add the following into your my.cnf file for all masters and restart the servers.

[mariadbd]
# Replace the following with a unique id. All slaves of this master should have same
# gtid_domain_id to allow easy failover to a slave if needed
gtid_domain_id=1
#
auto_increment_increment=10
# Set this to a different value 1-10 for each master. Could be same as gtid_domain_id
# This to ensure that all masters generate different values for AUTO_INCREMENT keys.
auto_increment_offset=1
#
# The following is needed to ensure the ALTER TABLE on another master will not
# break ring replication
slave_type_conversions=ALL_NON_LOSSY,ALL_LOSSY
#
# We cannot use semisync in ring replication as the masters need to be resilient against
# bad connections
rpl_semi_sync_master_enabled=0
#
# We have to log updates from other masters to the binary log.
log_slave_updates

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.