MySQL Master-Slave Replication - Step by Step

MySQL replication is a process that enables data from one MySQL database server (the master)
to be copied automatically to one or more MySQL database servers (the slaves).

1. Configure the Master Server:

We are going to start with the master:
1. SSH to the master server
2. Edit the /etc/my.cnf file and add the following entries under [mysqld] section
$ vi /etc/my.cnf
server-id = 1
binlog-do-db=database
master-info-file = /var/lib/mysql/mysql-master.info
log-error = /var/lib/mysql/my_database.err
log-bin = /var/lib/mysql/mysql-bin
3. Restart mysql
$systemctl restart mysqld
4. Create the replication user (change the Pass-Goes-Here part with your new pass):
Note: this goes on the slave, so that the master could then connect to the slave server
Mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY
'Slave@123';
Mysql> FLUSH PRIVILEGES;
Mysql> FLUSH TABLES WITH READ LOCK;
Mysql> SHOW MASTER STATUS;

You would see something like:

5. Take a note of the File (mysql-bin.000005) and Position (154) numbers and open new
session to take the backup.
$ mysqldump -u root -p --master-data sample_db > /root/sampled_backp.sql
Mysql> UNLOCK TABLES;
 MySQL Master-Slave Replication - Step by Step

Mysql> quit;
6. Now transfer the dump file to the slave server
$ scp /root/sampled_backup.sql root@192.168.0.33:/root/

2. Configure Slave Server:

1. Login to the slave server via SSH as user root and open my.cnf configuration file
with VI editor.
$vi /etc/my.cnf
server-id = 2
master-connect-retry=60
replicate-do-db=database
relay-log = mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
log-error = /var/lib/mysql/mysql.err
2. Now import the dump file that we exported in earlier command and restart the MySQL
service.
$ mysql -u root –p sample_db < /root/sampledb_backup.sql

Note: you might need to create the database before importing the data if it is not exists.
$mysql –u root -p
mysql> CREATE DATABASE sample_db;
3. Login into MySQL as root user and Then in order to start the replication run the
following and make sure to update the details accordingly:
Mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.32', MASTER_USER='slave',
MASTER_PASSWORD='Slave@123', MASTER_LOG_FILE='mysql-bin.000005',
MASTER_LOG_POS=154;
Mysql> start slave;
Mysql> show slave status\G

Then when you run the show slave status command you should see something like this:
 MySQL Master-Slave Replication - Step by Step

3. Verifying MySQL Replication on Master and Slave Server

1. To verify that everything works as expected, we’ll create database on the master
server:
$mysql –u root –p
Mysql> create database replica_test;
Mysql> create table replica_users (Sno int unsigned auto_increment primary key, Name
char(10));
Mysql> insert into replica_users (Sno, Name) values (1, ‘salve_user’);

2. Now login to the slave server and check whether database created pr not.
$ mysql –u root –p
Mysql> show databases;
In the output you will find newly created replica_test in the slave.
 MySQL Master-Slave Replication - Step by Step

Just for Knowledge on the replica:

Now let’s see what is happening on the slave. When you start replication, two threads are
started on the slave:

1. IO thread
This process called IO thread connects to a master, reads binary log events from the master as
they come in and just copies them over to a local log file called relay log. That’s all.
Slave_IO_Running: Whether the I/O thread for reading the master's binary log is running.
Normally, you want this to be yes unless you have not yet started replication or have explicitly
stopped it with STOP SLAVE.

2. SQL thread
The second process – SQL thread – reads events from a relay log stored locally on the
replication slave (the file that was written by IO thread) and then applies them as fast as
possible.
Slave_SQL_Running: Whether the SQL thread for executing events in the relay log is running.
As with the I/O thread, this should normally be yes.

3. Seconds_Behind_Master:
The number of seconds that the slave SQL thread is behind processing the master binary log. A
high number (or an increasing one) can indicate that the slave is unable to handle events from
the master in a timely fashion.