Analytics - live data can be created on the master, while the analysis of the information can take place on the slave without affecting the performance of the master.Data security - as data is replicated to the slave, and the slave can pause the replication process, it is possible to run backup services on the slave without corrupting the corresponding master data.This model can improve the performance of writes (since the master is dedicated to updates), while dramatically increasing read speed across an increasing number of slaves. Reads, however, may take place on one or more slaves.

In this environment, all writes and updates must take place on the master server. Scale-out solutions - spreading the load among multiple slaves to improve performance.Usage targets for replication in MariaDB include: If changes are queued up and written later, it is asynchronous. If the changes are made to the master and slave at the same time, it is synchronous.

The difference is simply the timing of propagation of changes. Master-slave replication can be either synchronous or asynchronous. The slave outputs a message stating that it has received the update successfully, thus allowing the sending of subsequent updates. The master logs the updates, which then ripple through to the slaves. Master-slave replication enables data from one database server (the master) to be replicated to one or more other database servers (the slaves). This guest post from Jelastic (originally published here) describes how to set up MariaDB master-slave replication using their Jelastic PaaS (Platform as a Service). Traditionally, master-slave replication is done with real servers, but it can also be done with cloud database servers. Many developers use master-slave replication to solve a number of different problems, including problems with performance, supporting the backup of different databases, and as a part of a larger solution to alleviate system failures.

Backup master database