高性能MYSQL---基于GDIT的半同步复制

一、MySQL复制

1.1 MySQL几个同步模式概念：

1、 异步复制（Asynchronous replication）

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主库上已经提交的事务可能并没有传到从库上，如果此时，强行将从库提升为主库，可能导致新主库上的数据不完整。

2、全同步复制（Fully synchronous replication）

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

3、半同步复制（Semisynchronous replication）

一主多从模式下，有一个从节点返回成功，即成功，不必等待多个节点全部返回。介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

1.2 MySQL半同步复制技术

一般而言，普通的replication，即MySQL的异步复制，依靠MySQL二进制日志也即binary log进行数据复制。 比如两台机器，一台主机（master），另外一台是从机（slave）。

• 正常的复制为： 事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。

• 异常的复制为： 事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog
  buffer进行checkpoint；slave因为网络不稳定，一直没有收到t1；master挂掉，slave提升为新的master，t1丢失。

• 很大的问题是： 主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。

为了弥补以上几种场景的不足，MySQL从5.5开始推出了半同步复制。相比异步复制，半同步复制提高了数据完整性，因为很明确知道，在一个事务提交成功之后，这个事务就至少会存在于两个地方。即在master的dumper线程通知slave后，增加了一个ack（消息确认），即是否成功收到t1的标志码，也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。 如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复后又会自动变为半同步复制。即表示MASTER 只需要接收到其中一台SLAVE的返回信息，就会commit；否则需等待直至达到超时时间然后切换成异步再提交。

1.3 半同步复制具体特性

主库产生binlog到主库的binlog file，传到从库中继日志，然后从库应用；也就是说传输是异步的，应用也是异步的。半同步复制指的是传输同步，应用还是异步的！

• 从库会在连接到主库时告诉主库，它是否配置了半同步。
• 如果半同步复制在主库端是开启了的，并且至少有一个半同步复制的从库节点，那么此时主库的事务线程在提交时会被阻塞并等待，结果有两种可能，要么至少一个从库节点通知它已经收到了所有这个事务的Binlog事件，要么一直等待直到超过配置的某一个时间点为止，而此时，半同步复制将自动关闭，转换为异步复制。
• 从库节点只有在接收到某一个事务的所有Binlog，将其写入并Flush到Relay Log文件之后，才会通知对应主库上面的等待线程。
• 如果在等待过程中，等待时间已经超过了配置的超时时间，没有任何一个从节点通知当前事务，那么此时主库会自动转换为异步复制，当至少一个半同步从节点赶上来时，主库便会自动转换为半同步方式的复制。
• 半同步复制必须是在主库和从库两端都开启时才行，否则主库默认使用异步方式复制。

二、半同步复制的配置(基于GDIT的半同步复制)

将插件安装在数据库中是临时的，退出重新登陆会失效，永久的可以将配置写在配置文件中
实验环境：基于异步复制的基础上

step1 主库安装服务插件，并且开启半同步复制：

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%';	#状态变量

step2 在从端也安装插件，开启半同步复制：

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%';  

注意：要重启从上的IO线程，如果没有重启，则默认还是异步复制，重启后，slave会在master上注册为半同步复制的slave角色

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会执行很久,这个时候可能产生死锁或阻塞,严重影响性能

三.测试

1.半同步失败的情况

没有通过半同步复制的情况：

step1 从端关掉IO线程：

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

step2 在主端表中插入数据，会等待10秒，10s后会变为异步复制：

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

step3 此时在主端发现半同步失败次数+1：

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

mysql> show status like '%rpl%';

查看半同步状态也是off，待同步的事务也是1

从端会发现没有同步过来，再次打开IO线程后，数据才能同步过来，此时复制过来的是异步复制的结果

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

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

2.半同步正常情况

step1 从端打开IO：

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

step2 主端插入新数据：

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，成功一次

step3 从端验证同步结果：

mysql> select * from userlist;