- Scalability - if most of your queries are read.
- Data security
- Analytics - there are cases when you have complex queries and you do not want to put the stress on the production server.
- Long-distance data distribution
Configuring the master server
- Master server must have binary log enabled
- Unique server-id must be configured
- Red Hat based server: /etc/my.cnf
- Debian based server: /etc/mysql/my.cnf
[mysqld]
log-bin = mysql-bin
server-id = 1
Make sure the following lines must be commented out. Otherwise, slave servers won't be able to access the master:
#skip-networkingNow, restart MySQL service:
#bind-address = 127.0.0.1
Debian based: service mysql restartCreate replication user on master server
Red Hat based: /etc/init.d/mysqld restart
- Log into MySQL server as root
mysql -uroot -p
- Now, on MySQL shell create the replication user
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'password';
mysql> FLUSH PRIVILEGES;
- Unique server-id must be configured. Remember, none of the slave/master servers can have the same server-id. Server-id enabled communication between the master and slave servers.
- Enabling binary log is not compulsory but it recommended for data backup and crash recovery. There might be a case when you want this slave server to be the master server for other slaves.
- The following configurations can be set/changed whilst MySQL service is running:
- master-host: master IP address or hostname.
- master-user: MySQL user account with replication privilege.
- master-password: replication user password.
- master-connect-retry: seconds to retry to connect after network failure.
Now, restart MySQL service.[mysqld]
log-bin = mysql-bin
server-id = 2
master-host = 192.168.0.1
master-user = slave_user
master-password = password
master-connect-retry = 60
Preparing to replicate
Most of the cases, we have our master database running long before the slave. Hence, the master database should have a lot of data. We must import data from master to slave before replicating. There are two ways:
- LOAD DATA FROM MASTER:
use this if you are willing to have the master server being locked during the importing operation.
- Log into MySQL server as root:
mysql -uroot -p
- Now, importing and replicating from MySQL shell:
mysql> LOAD DATA FROM MASTER;
- Log into MySQL server as root:
- Common procedure:
Tasks on master server
- Enabling READ LOCK from master server for mysqldump later. We want to make sure that data will not be changed while we dumping the databases:
mysql> FLUSH TABLES WITH READ LOCK;
- Now, get the log sequence number:
mysql> SHOW MASTER STATUS;
If we see something like this, then we are on the right track:+------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000001 | 106 | | | +------------------+----------+--------------+------------------+ 1 row in set (0.00 sec)
Please take note of the position (106)! This is the log position where we start backing up the data. - Backup up the database from Linux shell:
mysqldump --routines --triggers --single-transaction --quick -uroot -p --all-databases > all-dbs.sql
- Unlock the master database so data can be written:
mysql> UNLOCK TABLES;
- Now, transfer SQL file (all-dbs.sql) to slave server.
Tasks on slave server
- Import data to slave server:
mysql -uroot -ppassword mysql < /path/to/all-dbs.sql
Note: -ppassword: no space between -p & password - Stop slave from replicating:
mysql> SLAVE STOP;
- Now, we have to manually set the log sequence position:
mysql> CHANGE MASTER TO
MASTER_HOST='192.168.0.1',
MASTER_USER='slave_user',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.001',
MASTER_LOG_POS=106; - Finally, start replicating:
mysql> SLAVE START;
- Enabling READ LOCK from master server for mysqldump later. We want to make sure that data will not be changed while we dumping the databases: