MariaDB Replication

MariaDB, resp. MySQL, natively supports master->slave replication.

A typical use case for the replication is to do backups. Performing backups on the slave server does not affect availability of the production database. If both servers use equivalent hardware, you may even use the replication for fail-over - if the master server goes down, you can send the traffic to the slave server.

Another usage scenario is asynchronous master-master replication (technically a two-way master->slave replication). The main purpose is fail-over, because even without collisions in keys, you can run into problem during intense write workloads on both nodes, especially with complex write queries. Key collisions can be solved by using odd auto-increment numbers on one server and even ones on the other. If you do not use auto-increment and instead generate IDs in your application, it is not possible to use this type of replication.

The limits of this replication are based on the technical implementation. Master server streams transaction log to the slave, which replays all the write queries. The slave may be delayed during a time-consuming operation. When the delay is longer than the transaction backlog, the replication will stop. Occasionally, the replication might fail for other reasons, most notably key collision (usually caused by sending a write operation directly to the slave server).

In order to restore the replication, it is necessary to copy the database storage from master server to the slave. After that, we restart the replication and the slave server syncs the remaining data. If all tables are in InnoDB, this usually has no adverse effect on the master. However, when copying MyISAM tables, those are temporarily locked, causing their unavailability. If you are contacted by our technical support about restoring replication, you need to be aware of the service outage of databases with MyISAM tables.