Semi-synchronous replication principle:
Before mysql5.5, the replication of mysql was asynchronous, and there was a certain delay between the data of the master database and the slave database, so there was a hidden danger: when a transaction was written and committed on the master database, the slave database had not yet obtained the master database. When the Binlog log is pushed, the master database is down. For example, the master database may lose the transaction Binlog on the master database due to disk damage or memory failure. At this time, the transaction may be lost on the slave database, resulting in master-slave inconsistency. To solve this problem, semi-synchronous replication was introduced in MySQL 5.5.
In the asynchronous replication before MySQL 5.5, after the master library has completed the commit operation, it can successfully return to the client after the master library writes the Binlog log, without waiting for the binlog log to be transmitted to the slave library.
In semi-synchronous replication, in order to ensure that every Binlog transaction on the master library can be reliably copied to the slave library, the master library does not report back to the front-end application user in time when each transaction is successfully submitted, but waits for it. After a slave library also receives the binlog transaction and successfully writes it to the relay log, the master library returns the commit operation to the client successfully.
Semi-synchronous replication ensures that after the transaction is successfully submitted, there are at least two log records, one on the binlog log of the main library and the other on the relay log of at least one cluster library, thus further ensuring the integrity of the data. The general flow chart of semi-synchronous replication is as follows:
In the semi-synchronous replication mode, if the host goes down in any of the steps 1, 2, and 3, the transaction is not submitted successfully, and the transaction is not received from the library. The corresponding binlog log, so the master and slave data are consistent. If the slave library is down or the network fails when the binlog log is transferred to the cluster library in step 4, the binlog is not transferred to the slave library in time, and the transaction on the master library will wait for a period of time (often set by the parameter rpl_semi_sync_master_timeout). The number of milliseconds), if the binglog cannot be successfully pushed to the slave database within this period, mysql automatically adjusts the replication mode to asynchronous, and the transaction returns the submission result to the client normally.
Semi-synchronous replication largely depends on the network conditions between the master and slave libraries. The smaller the round-trip delay RTT, the better the real-time performance of the slave library. Generally speaking, the faster the network between the master and slave libraries, the better the slave library. real time. Try to ensure that the slave node and the master node are in the same computer room, in the same cabinet, and on the same switch.
The semi synchronization plug-in developed by Google for MySQL 5.5 and later, we can use this plug-in to achieve semi-synchronous replication.
The main library and the slave library use different plug-ins.
Experimental environment:
192.168.0.196 master node 1
192.168.0.198 master node 2
Myql version: mysql-5.5.17
Configure a firewall, and those running two master nodes can access each other's 3306 port.
Configuration process:
1:) Determine whether the msyql server supports dynamic addition of plug-ins
2:) After confirming that dynamic plug-ins are supported, check whether there are plug-ins in the mysql installation directory. Generally, the main library plug-in exists in the installation directory /lib/plugin by default: semisync_master .so and the slave library plugin semisync_slave.so
3:) Install the plugin on the master library
4:) Install the plugin on the slave library
5:) View the installed plug-ins from mysql.plugin
When the installation is complete, MySql will record the plug-ins just installed in the system table plugin, and the plug-ins will be automatically loaded after the next system restart.
6:) You need to configure the parameters on the master library and the slave library to open semi_sync respectively. The default semi-synchronization setting is not enabled.
Configure global parameters on the master library: configure global parameters
as on the slave library:
7: Start the slave thread on the slave library At
this step, the semi-synchronous configuration is completed
Configuration test Check the semi-synchronization status
on the master library:
pay attention to the three parameters:
rpl_semi_sync_master_status =ON : indicates that semi-synchronization replication is currently open
rpl_semi_sync_master_yes_tx value is 0: indicates that the master library has not yet had any transaction that is copied to the slave through semi-synchronization library.
The value of rpl_semi_sync_master_no_tx is 0: it means that there are currently 0 transactions that are not responded in time by the slave library in semi-synchronous mode.
Execute a transaction and check the status:
at this time, you will find that rpl_semi_sync_master_yes_tx becomes 1, the update transaction just now is copied to the slave database through semi-synchronization, and rpl_semi_sync_master_yes_tx is increased by 1.
Check the slave database table
After testing the millisecond waiting time of the main library in an abnormal network environment, it will automatically switch to an asynchronous replication scenario.
1) Check the waiting timeout time for the semi-synchronous replication of the master database:
2:) Turn on the firewall of the slave database, and set the filtering rules to simulate the failure of the master database or the network failure.
* means enable, switch whether to enable or not through the [space bar
] Create a filter rule
on the slave library, then execute and stop the slave thread on the slave library, then start the slave thread, and view the slave thread.
At this time, slave_IO_Running becomes the connecting state, indicating that it is connecting with the main library. If the connection is successful, slave_IO_Running changes to the yes state.
3:) Execute a transaction on the main library and commit, the commit operation on the main library will be blocked for 30 seconds.
After the master library waits for 30 seconds of synchronization, the update operation is successfully executed after the synchronization response from the slave library is not obtained. The update transaction is written into the binary file of the master library, and the semi-synchronous mode is switched to the asynchronous mode at the same time.
rpl_semi_sync_master_status =OFF : Indicates that semi-synchronous replication is currently closed
. rpl_semi_sync_master_yes_tx value of 1: Indicates that the master library currently has 1 transaction that is replicated to the slave library through semi-synchronous replication.
The value of rpl_semi_sync_master_no_tx is 3: it means that there are currently 3 transactions that are not responded in time by the slave library in semi-synchronous mode, from 2 to 3 before, because the semi-synchronous update operation did not succeed.
4: Clear the firewall rules of the slave library.
After clearing the firewall rules, the slave library will automatically try to connect to the master library. After a few seconds, the status of the i/o thread will change from Connecting to YES, and the data of the master library and the slave library are consistent.
Check the semi_sync status of the master library and the slave library. :
It is found that the rpl_semi_sync_master_status of the master library becomes ON. After the master library detects that the slave library is normal, the replication method from the master library to the slave library has an asynchronous mode, and switches to semi-synchronous mode again.
From the process of semi-synchronous replication, it will be found that the 'half' of semi-synchronous replication is reflected in: although the binlog logs of the master library and the slave library are synchronized, the master library returns the submission result without waiting for the slave library to apply this part of the log. This part of the operation is asynchronous. The data of the slave library is not synchronized with the master library in real time. So it can only be called semi-synchronization, not full real-time synchronization.