1. Introduction to MySQL master-slave synchronization
Master-slave replication means that one MySQL server acts as the master database server, and another one or more acts as the slave database server, and the data of the master database server is automatically copied to the slave database server.
- 1 Types of Replication Supported by MySQL
- Statement-based replication: SQL statements executed on the master server execute the same statement on the slave server. MySQL uses statement-based replication by default, which is more efficient. Once it finds that exact copying is impossible, row-based copying is automatically selected.
- Row-based replication: Copy the changed content instead of executing the command on the slave server. Supported from mysql5.0.
- Mixed-type replication: Statement-based replication is used by default, and row-based replication is used when statement-based replication is found to be inaccurate.
1.2 MySQL master-slave synchronization principle
- The Master node records data changes in the binary log (Bianry log), which is the file specified by log-bin in the configuration file my.cnf of the Master node. These records are called binary log events;
- The slave node reads the binary log events in the Master through the I/O thread and writes it to its relay binlog;
- The Slave reads the records of the relay binlogs through the SQL Thread thread, redoes the events in the relay log, executes the event information in the relay log one by one locally, and completes the local storage of the data, so as to reflect the changes to its own data (data replay).
1.3 Problems solved by master-slave replication
MySQL replication technology has the following characteristics:
(1) Data distribution (Data distribution)
(2) Load balancing
(3) Backups
(4) High availability and failover
1.4 Asynchronous and semi-synchronous replication
MySQL itself supports one-way, asynchronous replication. Asynchronous replication means that there is a delay in copying data from one machine to another, and most importantly it means that data cannot be copied at the same time as the application's transaction is committed and acknowledged on the master or applied to the slave server.
Synchronous replication can be defined as data being committed to one or more machines at the same time, usually through what is known as "two-phase commit". Although synchronous replication can ensure data consistency, it also causes performance degradation. MySQL using the MyISAM or InnoDB storage engines does not natively support synchronous replication, however some technologies, such as Distributed Replicated Block Devices (DRBD for short), can provide synchronous replication on the underlying file system, allowing a second MySQL server to fail on the primary server takes over (using a replica of the second server).
- semi-synchronous replication
Since MYSQL 5.5, semi-automatic replication is supported. The previous versions of MySQL Replication were asynchronous. After the main database executed some transactions, it would not control the progress of the standby database. If the standby database is unfortunately behind, and more unfortunately the main database crashes (for example, downtime) at this time, the data in the standby database is incomplete. In short, when the primary database fails, we cannot use the standby database to continue to provide consistent data services. Semisynchronous Replication ensures that the committed transaction has been passed to at least one standby database to a certain extent. In Semi synchronous, it is only guaranteed that the transaction has been delivered to the standby database, but it is not guaranteed that the execution has been completed on the standby database.
In addition, there is another situation that will lead to inconsistency between the primary and secondary data. In a certain session, after submitting a transaction on the main database, it will wait for the transaction to be passed to at least one standby database. If the main database crashes during this waiting process, the standby database may be inconsistent with the main database, which is fatal. If the primary and secondary network fails or the secondary database hangs, the primary database waits for 10 seconds (the default value of rpl_semi_sync_master_timeout) after the transaction is committed, and then continues. At this point, the main library will change back to its original asynchronous state.
After MySQL loads and enables the Semi-sync plug-in, each transaction needs to wait for the standby database to receive the log before returning it to the client. If you are doing small transactions with low latency between the two hosts, Semi-sync can achieve zero data loss with little performance penalty.
By default, MySQL's replication is asynchronous. After all update operations on the Master are written to Binlog, it does not ensure that all updates are replicated to the Slave. Although asynchronous operations are efficient, when there is a problem with the Master/Slave, there is a high risk of data being out of sync, and data may even be lost.
The purpose of introducing the semi-synchronous replication function in MySQL 5.5 is to ensure that when the master fails, the data of at least one slave is complete. In the case of timeout, it can also be temporarily transferred to asynchronous replication to ensure the normal use of services. After one slave catches up, it continues to switch to semi-synchronous mode.
1.5 Master-slave mode
- One master multiple slave mode
Second, the master-slave configuration
The basic steps of master-slave configuration:
- Master configuration
- Configure a unique server id
- Create a user with copy permissions
- Slave configuration
- Configure a unique server id
- Connect to the master server and start replicating data
2.1 Master configuration
- Modify the configuration file
1 # Enable binary log: format + binary log prefix name
2 binlog-format= ROW
3 log-bin=mysql-master- bin
4 # Set server id : must be unique
5 server- id = 127
6 # Whether it is recorded when slave is updated In the log;
7 # Let the slave act as the master of other slaves. At this point, the slave writes the events executed by the #SQL thread into its own
binary log (binary log), and then its slave can obtain these events and execute them
9 log-slave-updates= true 10 # Open half Synchronization
11 # Install the plugin first: install plugin rpl_semi_sync_master soname
12 # ' semisync_master.so '
;
13 # View status: show variables like ' rpl_% ' ;
14 rpl_semi_sync_master_enabled= ON
15 # The name of the binary database that needs to be synchronized;
16 binlog- do -db= tuling
17 # The name of the binary database that is not synchronized, if it is not set, it can be Comment out;
18 binlog-ignore-db= information_schema
19 binlog-ignore-db= mysql
20 binlog-ignore-db= personalsite
21 binlog-ignore-db= test
22 # Binlog file verification, when the master and slave database versions are inconsistent Need to close the checksum
23 # binlog_checksum =none;
- Create a user database for master-slave synchronization:
grant replication slave,super,reload on *.* to slave1@192.168.17.201 identified by '123456';
- View master node status
mysql> show master status
mysql> show slave hosts
mysql> show binary logs
mysql> show binlog events in 'mysql-bin.000003'
2.2 Slave configuration
- Modify the configuration file my.cnf
server-id = 2
log-bin=mysql-slave-bin
binlog-do-db=tuling
binlog-ignore-db=information_schema
binlog-ignore-db=mysql
binlog-ignore-db=personalsite
binlog-ignore-db=test
- Connect to the main database
mysql>change master to master_host='192.168.0.101', master_user='slave1', master_password='123456' ,MASTER_AUTO_POSITION = 2887;
- Slave related operations
mysql>start slave;
mysql>stop slave;
show slave status\G;