1 Introduction
One of the reasons why MySQL is one of the most widely used databases in the world is that it is free. But it cannot be ignored that its own function is indeed very powerful. With the development of technology, in the actual production environment, a single MySQL database server cannot meet the actual needs. At this point, the database cluster solves this problem very well. Using MySQL distributed cluster, you can build a cluster server with high concurrency and load balance (this blog does not cover it for the time being). Before this, we must ensure that the data in each MySQL server is synchronized. We can easily complete data synchronization through MySQL internal configuration, mainly including master-slave replication and master-master replication.
2. Environmental description
Two linux virtual hosts
Linux version CentOS6.6, MySQL 5.5
ip：192.168.95.11、192.168.95.12
3. Master-slave replication
3.1、MySQL
It's already installed and doesn't have any data
3.2, configuration file
Generally, the MySQL configuration files in Linux are in /etc/my.cnf (the configuration file in Windows is mysql.ini)
log-bin=mysql-bin enable binary log
Note: The binary log must be turned on, because data synchronization is essentially that other MySQL database servers execute the binary log of this data change on the local machine again.
192.168.95.11 is the primary database server
192.168.95.12 is the slave database server
3.3. Start building master-slave replication
first step:
Create a MySQL user that can log in to the 192.168.95.12 host in 192.168.95.11
User: mysql12
Password: mysql12
mysql>GRANT REPLICATION SLAVE ON *.* TO ‘mysql12’@’192.168.95.12’ IDENTIFIED BY ‘mysql12’;
mysql>FLUSH PRIVILEGES;
Step 2:
View 192.168.95.11 MySQL server binary file name and location
mysql>SHOW MASTER STATUS;
third step:
Tell the binary file name and location
Execute in 192.168.95.12:
mysql>CHANGE MASTER TO
>MASTER_HOST=’192.168.95.11’,
>MASTER_USER=’mysql12’,
>MASTER_PASSWORD=’mysql12’,
>MASTER_LOG_FILE=’mysql-bin.000048’,
>MASTER_LOG_POS=432;
Complete the master-slave replication configuration
3.4. Test master-slave replication
in 192.168.95.12
mysql>SLAVE START; #Enable replication
mysql>SHOW SLAVE STATUS\G #Check whether master-slave replication is configured successfully
When you see Slave_IO_Running: YES, Slave_SQL_Running: YES, it indicates that the status is normal
practical testing:
--Login to 192.168.95.11 master MySQL
mysql>SHOW DATABASES;
--Login 192.168.95.12 from MySQL
mysql>SHOW DATABASES;
-----------------------------------------------------
192.168.95.11 main MySQL operation:
mysql>create database aa;
mysql>use aa;
mysql>create table tab1(id int auto_increment,name varchar(10),primary key(id));
mysql>show databases;
mysql>show tables;
192.168.95.12 from MySQL operation:
mysql>show databases;
mysql>show tables;
It can be seen from the above two result graphs that the two hosts have achieved data synchronization. The configuration of master-slave replication is so simple.
4. MySql master-master replication
4.1. Implementation principle
Master-master replication means that data can be changed in both MySQL hosts, and the other host will also make corresponding changes. You might be smart enough to figure out how to do it. Yes, just organically combine the two master-slave replications. It's just that we need to pay attention to some issues when configuring, for example, the primary key is duplicated, the server-id cannot be duplicated, and so on.
4.2, configuration file
--192.168.95.11
server-id=11 #Any natural number n, as long as the two MySQL hosts are not duplicated.
log-bin=mysql-bin #Enable binary log
auto_increment_increment=2 #Step value auto_imcrement. Generally, if there are n masters of MySQL, fill in n
auto_increment_offset=1 #Start value. Generally fill in the nth master MySQL. This is the first primary MySQL
binlog-ignore=mysql #Ignore the mysql library [I don't usually write]
binlog-ignore=information_schema #Ignore the information_schema library [I don't usually write]
replicate-do-db=aa #Database to be synchronized, all libraries by default
--192.168.95.12
server-id=12
log-bin=mysql-bin
auto_increment_increment=2
auto_increment_offset=2
replicate-do-db=aa
Restart MySQL after configuration
4.3. Start building master-master replication
Because the master-slave replication is a combination of two master-slave replications, I will follow the above master-slave replication and then configure it.
first step:
Create a MySQL user that can log in to the 192.168.95.11 host in 192.168.95.12
User: mysql11
Password: mysql11
mysql>GRANT REPLICATION SLAVE ON *.* TO ‘mysql11’@’192.168.95.11’ IDENTIFIED BY ‘mysql11’;
mysql>FLUSH PRIVILEGES;
Step 2:
View binary log name and location at 192.168.95.12
mysql>show master status;
third step:
Tell the binary file name and location
Execute in 192.168.95.11:
mysql>CHANGE MASTER TO
MASTER_HOST=’192.168.95.12’,
MASTER_USER=’mysql11’,
MASTER_PASSWORD=’mysql11’,
MASTER_LOG_FILE=’mysql-bin.000084’,
MASTER_LOG_POS=107;
Complete the master-master replication configuration
4.4. Test master-master replication
Open slave start respectively;
mysql>SHOW SLAVE STATUS\G #Check whether master-slave replication is configured successfully
192.168.95.11
192.168.95.12
When you see Slave_IO_Running: YES, Slave_SQL_Running: YES, it indicates that the status is normal
test:
--192.168.95.11
mysql>use aa;
mysql>select*from tab1;
tab1 no data
--192.168.95.12
mysql>use aa;
mysql>select*from tab1;
tab1 no data
--192.168.95.11 insert data
mysql>insert into tab1 (name) value(‘11’),(‘11’),(‘11’);
--192.168.95.12 insert data
mysql>insert into tab1 (name) value(‘22’),(‘22’),(‘22’);
View data:
The two host data results are the same!
The master-master replication configuration is successful!
5. Matters needing attention
1. The auto_increment_increment and auto_increment_offset in the master-master replication configuration file can only ensure that the primary key is not duplicated, but cannot guarantee the order of the primary key.
2. When the configuration is completed and Slave_IO_Running and Slave_SQL_Running are not all YES, there is an error message in the show slave status\G information, which can be corrected according to the error message.
3. When Slave_IO_Running and Slave_SQL_Running are not all YES, most of the problems are caused by inconsistent data.
Common mistakes:
1. There are db databases in both databases, but the first MySQL db has tab1, and the second MySQL db does not have tab1, it must not succeed.
2. The binary log name and location of the data have been obtained, and the data operation has been performed, resulting in the change of the POS. The previous POS is still used when configuring CHANGE MASTER.
3. After the slave is stopped, the data is changed, and then the slave is started. error.
The ultimate correction method: re-execute CHANGE MASTER again.
(The above are some of my own opinions, if there are any shortcomings or mistakes, please point out)
Author: That Leaf Follows the Wind
Disclaimer: This blog post is original and only represents the views or conclusions I have summarized at a certain time during my work and study. When reprinting, please give a link to the original text in an obvious position on the article page.