Replication Master to Master
Contents
1 Introduction
After done the installation (Look here : Installation et configuration), we are going to set up MySQL master-master replication. We need to replicate MySQL servers to achieve high-availability (HA). In my case I need two masters that are synchronized with each other so that if one of them drops down, other could take over and no data is lost. Similarly when the first one goes up again, it will still be used as slave for the live one.
Here is a basic step by step tutorial, that will cover the mysql master and slave replication and also will describe the mysql master and master replication.
Notions: we will call system 1 as master1 and slave2 and system2 as master2 and slave 1.
Install mysql on master 1 and slave 1. configure network services on both system, like :
- Master 1/Slave 2 ip: 10.8.0.1
- Master 2/Slave 1 ip : 10.8.0.6
2 Master 1 configuration
2.1 Step 1
On Master 1, make changes in my.cnf :
Notes : Italic lines are nearly optional and bold lines need to be set
If you want to sync all databases without setting exclusions, you could without adding '*ignore-db' values :
Restart MySQL :
restart |
/etc/init.d/mysql restart |
2.2 Step 2
On master 1, connect on it and create a replication slave account in mysql.
mysql> create user 'replication'@'10.8.0.1' identified by 'password'; |
- replication : username for replication
- password : password for replication user
mysql> grant replication slave on <database name>.* to 'replication'@'10.8.0.1'; or mysql> grant replication slave on *.* to 'replication'@'10.8.0.1'; |
Flush the privileges and database tables with read lock :
Note, if you have full InnoDB databases, you needn't to flush tables with read locks.
2.3 Step 3
Backup the desired database and upload them to the slave. If you're on InnoDB :
mysqldump |
mysqldump -uroot -p --opt --add-drop-table --routines --triggers --events --single-transaction --master-data=2 -B wikidb > wikidb.sql |
Note: If there is InnoDB/MyISAM, add --lock-all-tables !
scp |
scp wikidb.sql 10.8.0.6:~/ |
Then we will unlock tables :
mysql -uroot -p unlock tables; quit; |
3 Slave 1 configuration
3.1 Step 1
Let's create the database :
mysql -uroot -p create database wikidb; quit; |
Then we import the database :
mysql -uroot -p wikidb < wikidb.sql |
3.2 Step 2
Now edit my.cnf on Slave1 or Master2 :
my.cnf |
[mysqld] ... server-id=2 bind-address = 0.0.0.0 # sync_binlog = 1 expire_log_days = 14 ... |
Then restart MySQL :
restart |
/etc/init.d/mysql restart |
3.3 Step 3
Grab informations from the Master :
head |
head -n100 database.sql |
Now we're going to inform the slave database :
mysql -uroot -p stop slave; reset slave; change master to master_host='10.8.0.1', master_user='replication', master_password='password', master_log_file='mysql-bin.000173', master_log_pos=50937; |
Let's starting the slave 1 :
Above highlighted rows must be indicate related log files and Slave_IO_Running and Slave_SQL_Running: must be to YES.
- Seconds_Behind_Master : is the difference time between master and slave data sync (in progress...).
- Master_Host : This is the address of the master server. The slave will connect on it to get the logs that have to be replayed
- Master_User : The user that we will use for the replication
- Master_Port : The port where the slave will connect to on the master
- Master_Log_File: This file is the binary log that the slave will have to replay. the binary log is located on the master server. This file contains every statement that makes a change to the database in a binary format.
- Read_Master_Log_Pos : This is the position number on the binary log file that is being read by the "Slave_I/O Process" (the process that established the connexion to the master and ensure the sync)
- Relay_Log_File: Same as the binary log but this file is located on the slave. This is a relay file of the master binary log
- Relay_Log_Pos: This is the position number on the relay log file that is being read by the "Slave_SQL Process" (the process that replays the changes to the slave database)
- Relay_Master_Log_File : It contains all the statements that have been processed by the slave.
- Slave_IO_Running : The status of the Slave_I/O process. when it's on "Yes" that means that the slave is properly connected to the master. if it's on "No" that means that something goes wrong with the connectivity between the 2 nodes
- Slave_SQL_Running : The status of the Slave_SQL process. when it's on "Yes" that means that the slave is able to process statements and that all is working correctly. if it's on "No" that means that something goes wrong while reading the relay logs
4 Master 1 verification
The above scenario is for master-slave, now we will create a slave master scenario for the same systems and it will work as master master.
5 Master 2 configuration
5.1 Step 1
On Master 2, make changes in my.cnf :
Restart MySQL :
/etc/init.d/mysql restart |
5.2 Step 2
On master 1, connect on it and create a replication slave account in mysql.
mysql> create user 'replication'@'10.8.0.6' identified by 'password'; |
- replication : username for replication
- password : password for replication user
mysql> grant replication slave on <database name>.* to 'replication'@'10.8.0.6'; or mysql> grant replication slave on *.* to 'replication'@'10.8.0.6'; |
Flush the provileges :
6 Slave 1 configuration
Now we're going to inform the slave database :
mysql -uroot -p slave stop; reset slave; change master to master_host='10.8.0.6', master_user='replication', master_password='password', master_log_file='mysql-bin.000173', master_log_pos=50937; |
Let's starting the slave 2 :
Above highlighted rows must be indicate related log files and Slave_IO_Running and Slave_SQL_Running: must be to YES.
7 Master 2 verification
The above scenario is for master-slave, now we will create a slave master scenario for the same systems and it will work as master master.
8 Monitoring
Now you need to monitor your replication, you need to look at this when doing 'show slave status\G' :
show slave status |
... Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 0 ... |
What is interesting to investigate are those lines :
show slave status |
... Last_IO_Error: error connecting to master 'replication@192.168.25.9:3306' - retry-time: 60 retries: 86400 Last_SQL_Error: ... |
You also need to look at binlog size :
Ugrade Binlog_cache_size from 32 to 128k if Binlog_cache_disk_use is not equal to 0.
9 FAQ
9.1 After a reboot the slave is not synchronized
On the master get informations :
mysql -uroot -p show master status; |
Try to do this on the slave (adapt to your configuration) :
The slave syncronization should be repared :-)
9.2 Watch current process to determine syncro problem
With this command, we can see if there is a mysql replication problem :
9.3 What if I have binlogs corrupted ?
If you've got this kind of problem, a tool called mk-table-checksum available here permit to check consitency between 2 servers. It also can help to recreate a consistancy database from the master.
9.4 Repair replication
You may need to repair your replication because somethings went wrong and you can see that in the slave status (Last_Error). The way to correct the problem is to stop the slave :
mysql |
stop slave; |
Then analyze the error message and correct it on the slave. Then skip the error message :
mysql |
set global sql_slave_skip_counter=1; |
Then start the slave again :
mysql |
start slave; |
All should now be ok :-)
10 Ressources
Here is another documentation if you encounter problem :
MySQL Database Scale-out and Replication for High Growth Businesses (Très bonne documentation)
Other MySQL masters replication documentation
Master to Master replication MySQL 5 on Debian Etch
Master to Master replication MySQL 5 on Fedora
How To Repair MySQL Replication
Setting Up Master-Master Replication On Four Nodes
MariaDB MySQL Avancé