MySQL/MariaDB Database Master-Slave Replication
Master-slave replication is used to solve a number of different problems with performance, supporting the backup of different databases, and as a part of a larger solution to alleviate system failures. It enables data from one database server (the master) to be replicated to one or more database servers (the slaves). The master logs the updates, which then ripple through to the slaves. The slave outputs a message stating that it has received the update successfully, thus allowing to send the subsequent updates. Master-slave replication can be either synchronous or asynchronous. The difference is simply the timing of propagation of changes. If the changes are made to the master and slave at the same time, it is synchronous. If changes are queued up and written later, it is asynchronous.
The target usage for replication in MariaDB and MySQL databases includes:
- Scale-out solutions
- Data security
- Long-distance data distribution
How you can use such replication and take advantage of it:
- Backups: to use replication as a backup solution, replicate data from the master to a slave, and then back up the data slave. The slave can be paused and shut down without affecting the running operation of the master, so you can produce an effective snapshot of “live” data that would otherwise require the master to be shut down.
- Scale-out: you can use replication as a scale-out solution; that is, where you want to split up the load of database queries across multiple database servers, within some reasonable limitations. Because replication works from the distribution of one master to one or more slaves, using replication for scale-out works best in an environment where you have a high number of reads and low number of writes/updates.
- Spreading the load: there may be situations when you have a single master and want to replicate different databases to different slaves. For example, you may want to distribute different sales data to different departments to help spread the load during data analysis.
- Increasing the performance: as the number of slaves connecting to a master increases, the load, although minimal, also increases, as each slave uses a client connection to the master. Also, as each slave must receive a full copy of the master binary log, the network load on the master may also increase and create a bottleneck. If you are using a large number of slaves connected to one master, and that master is also busy processing requests (for example, as a part of a scale-out solution), then you may want to improve the performance of the replication process. One way to improve the performance of the replication process is to create a deeper replication structure that enables the master to replicate to only one slave, and for the remaining slaves to connect to this primary slave for their individual replication requirements.
- Failover alleviating: You can set up a master and a slave (or several slaves), and to write a script that monitors the master to check whether it is up. Then instruct your applications and the slaves to change master in case of failure.
- Security: you can use SSL for encrypting the transfer of the binary log required during replication, but both the master and the slave must support SSL network connections. If either host does not support SSL connections, replication through an SSL connection is not possible. Setting up replication using an SSL connection is similar to setting up a server and client using SSL. You must obtain (or create) a suitable security certificate that you can use on the master, and a similar certificate (from the same certificate authority) on each slave.
You can get a MySQL or MariaDB database cluster with required replication type (including the master-slave one) up and running within minutes using Jelastic one-click install widget:
If you prefer to configure the Master-Slave replication manually in order to get more slave replicators or specify some custom configurations, please, follow the instruction below.
1. Log in to Jelastic dashboard.
2. Ask Jelastic to create a new environment.
3. In the Environment topology dialog pick MariaDB (or MySQL) as a database you want to use. Set the cloudlet limit and type the name of your first environment, for example, masterbase.
Wait just a minute for your environment to be created.
4. In the same way create one more environment with MariaDB or just clone it. Let’s name it slavebase. It will be located on the other hardnode, what is even more secure and reliable for storing your data.
Now you have two identical environments with two databases.
Configure Master Database
Let’s configure master base now.
1. Click Config button for your master database.
2. Navigate to my.cnf file and add the following properties as it is shown below:
We use binlog format “mixed” (binlog-format=mixed) to allow a replication of operations with foreign keys.
3. Save the changes and restart MariaDB in order to apply the new configuration parameters.
4. Click the Open in Browser button for MariaDB. Jelastic sent you an email with credentials to the database. Log in using these credentials.
5. Navigate to the User accounts tab and click on Add user account.
6. Specify the name and password for your slave replication user.
Now, scroll down and tick the replication client and replication slave administration privileges.
Click Go at the bottom of the page.
Configure Slave Database
Let’s go back to the Jelastic dashboard and configure our slave base.
1. Click Config button for your slave database.
2. Navigate to my.cnf file and add the following strings:
We allow our slave base to skip all errors from master (slave-skip-errors = all) in order not to stop normal slave operation in case of errors on master base.
This skipping is not recommended for using at the development stage in order to find out bugs etc. But here we talk about production, when your code has been already tested. Any error on the master’s side can stop slave or lead to its unsynchronization. In this case the error may be even innocuous. Some minor errors will probably occur on production. So the replication can be stopped because of small errors.
3. Next, open the /etc/phpMyAdmin/config.inc.php file and append it with the next option:
4. Save the changes and restart your slave database server in order to apply the new configuration parameters.
5. Navigate to phpMyAdmin using the credentials which Jelastic sent you when you created the environment for your slave database.
6. Go to the Replication tab click Configure for Slave replication.
7. Configure your master server (enter the name, the password and the host of your slave replication user).
Now you master server is configured.
8. Click on Control slave > Full start for the slave server in order to run Slave SQL and Slave IO threads.
9. Check the slave status table to ensure that everything is ok.
Check the Results
We have to ensure now that master-slave replication works for our databases.
1. Let’s create the new database (e.g. Jelastic) in our master base.
2. Navigate to slave base and you’ll see that the new database was successfully replicated.
Connection to Master-Slave
Here are two examples on how to connect to your master and slave databases from Java and PHP application.
1. As an example here you can see the code of our Java application which connects to master and slave databases.
2. Connection to master and slave databases for your PHP application:
Now you have your own database replication in the cloud. Enjoy!