A, MySQL replication

1.1 MySQL several sync pattern concept:

1、 Asynchronous replication (Asynchronous replication)

That is the default MySQL replication is asynchronous, the main library after the completion of the transaction execution submitted by the client will immediately return the results to the client, and does not care whether it has received treatment from the library, so there will be a problem, if the main crash out, the transaction at this time on the main library has been submitted may not be transferred from the library, if at this time, the main library will force the library to enhance, may lead to the data on the new primary database is incomplete.

2、Full Replication (Fully synchronous replication)

Means that when it returned to the client the main library executing the transaction, all of the libraries are executed the transaction. All because of the need to wait for completion of the transaction executed from the library to return, so the whole synchronous replication performance is bound to receive a serious impact.

3、Semi-synchronous replication (Semisynchronous replication)

From a multi-master mode, a successful return from the node, i.e. the success, without waiting for all of the plurality of nodes to return. Be between asynchronous replication and fully synchronous replication, the master database After you perform a transaction submitted by the client does not immediately returned to the client, but wait at least one received from the library to the relay log in and write it back to the client. With respect to the asynchronous replication, semi-synchronous replication improves data security, but it also caused some delay, the delay is at least a TCP / IP round trip time. Therefore, semi-sync is preferably used in low-latency network.
Here Insert Picture Description

1.2 MySQL semi-synchronous replication technology

In general, an ordinary replication, namely MySQL asynchronous replication, rely on MySQL binary log that is binary log data replication. For example, two machines, A host (Master), the other one is the slave (slave).

Normal replication to: A transaction (t1) written binlog buffer; dumper thread notifies slave new transaction t1; binlog buffer conduct checkpoint; slave of io thread receives t1 and written to own a relay log; slave to write the sql thread local database. At this time, master and slave can see this new transaction, even if the master hanging, slave can be promoted to a new master.
Abnormal copy is: A transaction (t1) written binlog buffer; dumper thread notifies slave new transaction T1; binlog
Buffer conduct checkpoint; slave because the network is unstable, has not received t1; master hang up, promoted to the new slave master, t1 lost.
The big question is: Master and slave is not synchronized update affairs, even if there is no other network or system anomalies, when the service concurrent up, slave master batch to be executed since the transaction sequence, resulting in significant delays.

In order to compensate for the lack of more than a few scenes, MySQL 5.5 launched from a semi-synchronous replication. Compared asynchronous replication, semi-synchronous replication improves data integrity, because it is clear to know,After a successful transaction commits, the transaction will be present in at least two places. That is the thread in the dumper after notification slave master, adds an ack (acknowledgment message), that is, whether t1 successfully received the flag code, which is in addition to sending dumper thread t1 to the slave, also assumed the work ack of receiving slave. If an exception occurs, do not receive ack, it will automatically be downgraded to an ordinary copy, abnormal repair until then will automatically become semi-synchronous replication. MASTER means that only one of which receives the return information SLAVE, will commit; otherwise, wait until the timeout is then switched to the asynchronous submit.

Specific properties of semi-sync 1.3

Library to produce master binlog binlog File primary library, from the library spread relay log, and from the database application; that is transmitted is asynchronous, the application also asynchronous. Semi-synchronous replication refers to transmission synchronous, asynchronous or application!

Libraries will tell when connected to the main library from the main library, it is configured in the semi-synchronous.
If the semi-synchronous replication in the master side is opened, and there is at least a semi-synchronous replication from the library nodes, then the transaction thread main library will be blocked and waiting when submitting results, there are two possibilities, either at least it has received a notice from the library node Binlog all events this transaction, or waits until the configuration of more than a certain point in time, but this time, semi-synchronous replication will automatically shut down, converted to asynchronous replication.
Only after all Binlog received one transaction, it is written from the library node and Flush to Relay Log files, correspondence will notify waiting thread above the main library.
If the waiting, the waiting time has exceeded the timeout time, without any notice from the current transaction nodes, then the main library will be automatically converted to asynchronous replication, when at least a semi-synchronous come up from the node, the main library it will be automatically converted to semi-synchronous replication mode.
Semi-synchronous replication and the job must be opened from both ends of the library are the main libraries, the main library or use the default asynchronous replication.

Second, the semi-synchronous replication configuration (a semi-sync based GDIT)

The plug-ins installed in the database is a temporary exit will re-login failure, permanent can be configured in the configuration file write
test environment: Basic asynchronous replication based on

step1 main library service plug-in installation, and open the semi-synchronous replication:

mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so'; #安装半同步模块
Query OK, 0 rows affected (0.01 sec)

mysql> select plugin_name,plugin_status
    -> from information_schema.plugins
    -> where plugin_name like '%semi%';  #查看插件
+----------------------+---------------+
| plugin_name          | plugin_status |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE        |
+----------------------+---------------+
1 row in set (0.00 sec)

mysql> set global rpl_semi_sync_master_enabled=ON; #开启半同步，也就是激活插件
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%semi%';    #环境变量

mysql> show status like '%rpl_semi_sync%';	#状态变量

Here Insert Picture Description

step2 from the end of the plug is also mounted, open semi-synchronous replication:

mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected (0.00 sec)

mysql> set global rpl_semi_sync_slave_enabled=ON;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%semi%';

Here Insert Picture Description
Note: To restart from the IO threads, if not restart, the default or asynchronous replication, after the restart, the slave will be registered as a semi-synchronous replication slave on the master role

mysql> stop slave io_thread;
Query OK, 0 rows affected (0.00 sec)

mysql> start slave io_thread; #重启IO线程使半同步生效
Query OK, 0 rows affected (0.00 sec)

mysql> show status like '%rpl%'; 查看变量的状态
mysql> show variables like '%rpl%'; 查看变量的值
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | ON         |
		### 是否开启半同步
| rpl_semi_sync_master_timeout              | 10000      | 
		###切换复制的timeout
| rpl_semi_sync_master_trace_level          | 32         | 
		###用于开启半同步复制模式时的调试级别,默认是32
| rpl_semi_sync_master_wait_for_slave_count | 1          |
		###至少有N个slave接收到日志
| rpl_semi_sync_master_wait_no_slave        | ON         |
		###是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on 
| rpl_semi_sync_master_wait_point           | AFTER_SYNC | 
		###等待的point
| rpl_stop_slave_timeout                    | 31536000   |
+-------------------------------------------+------------+    
		###控制stop slave 的执行时间，在重放一个大的事务的时候,突然执行stop slave,命令 
		###stop slave会执行很久,这个时候可能产生死锁或阻塞,严重影响性能

Here Insert Picture Description

III. Test

1. failure semisynchronous

No case by semi-synchronous replication:

step1 from the end to turn off the IO threads:

mysql> stop slave io_thread;
Query OK, 0 rows affected (0.01 sec)

step2 inserted into the master table data, waits 10 seconds, 10s becomes asynchronous replication:

mysql> insert into userlist values ('user5','555');
Query OK, 1 row affected (10.01 sec)

In this case the master step3 found semisynchronous failures +1:

Rpl_semi_sync_master_no_tx表示没有成功接收slave提交的次数，也就是使用半同步失败的次数，10s后没有得到反馈信息，会转为异步复制
Rpl_semi_sync_master_yes_tx使用半同步成功的次数，数据的一致性能提高

mysql> show status like '%rpl%';

Check the semi-synchronous state is off, the transaction is to be synchronized 1
Here Insert Picture Description
From the end will find that there is no synchronization over, open the IO thread again, data can be synchronized over, copied at this time it is the result of asynchronous replication

mysql> start slave io_thread;
Query OK, 0 rows affected (0.00 sec)

mysql> use westos;
Database changed
mysql> select * from userlist;

Here Insert Picture Description

2. The semi-synchronous normal circumstances

IO step1 open from the end:

mysql> start slave io_thread;
Query OK, 0 rows affected (0.00 sec)

step2 end of the main insert new data:

mysql> insert into userlist values ('user6','666');
Query OK, 1 row affected (0.01 sec)

mysql> select * from userlist;

mysql> show status like '%rpl%';  #Rpl_semi_sync_master_yes_tx 变为1，成功一次