介绍
上篇文章介绍了MMM架构的实现方法，但是上篇文章的MMM方案的复制是异步复制，异步复制的主要问题在于当主从存在延时时如果主机出现了故障导致了主从切换时这时将会存在数据丢失；mysql为了解决异步复制数据丢失的问题增加了半同步复制，半同步复制存在5.5以上的版本，半同步复制的原理是客户端在事务提交时必须等待从库接收到binlog的回应之后才能提交事务（当存在多个从库时默认只需要一个从库接受到了bInlog即可，也可以配置必须每一个从库都必须接收到binlog但是这样对性能影响就会很大），如果从库宕机或者故障导致binlog没有及时传送到从库（由参数rpl_semi_sync_master_timeout控制，默认是10S）,这时mysql会自动转为异步复制，当从库又重新启动有新的一条binglog从主库发送到从库在规定的时间内得到响应mysql又会自动转换为半同步复制，所以半同步复制对主从之间的网络要求比较高。
mysql版本：5.6
方案：MMM+半同步复制
一、原理
5.6的半同步复制是在客户端执行commit主库写入完binlog然后执行数据刷新到磁盘后才由dump线程将binlog记录发送到从库的io线程。
二、安装配置
首先说明一下，当前的配置是基于MMM方案的配置，由于MMM方案是两主一从，所以我在其中的双主上面配置半同步复制，从库上面还是原先的异步复制。半同步复制是基于插件来实现的，主从上面各自执行不同的插件。
1.查询是否支持动态插件
主从上面都需要查看是否支持动态插件
2.安装动态插件
主备都执行
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
注意：由于我当前的双主模式所以主和备都需要执行主从的插件，如果只是单纯的主从模式那么主执行主的插件从执行从的插件即可。
查看插件是否安装
3.开启半同步复制
SET GLOBAL rpl_semi_sync_master_enabled = 1;SET GLOBAL rpl_semi_sync_slave_enabled = 1;
同样主和备上面都同时执行上面两个操作，注意必须是开启全局的变量。
4.重启io线程
1.备库执行
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
2.主库执行
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
5.配置参数
show variables like '%rpl_semi%';
rpl_semi_sync_master_enabled、rpl_semi_sync_slave_enabled
分别代表主从的半同步复制是否启用，因为我当前是双主模式所以即担当了主又担当了从，所以这里面存在slave的参数在里面
rpl_semi_sync_master_timeout
该参数是配置半同步复制的延时时间，当主库发生binlog到从库从库在10s内还没有返回则自动转换为异步复制，这个时间可以调整，默认是10S
注意：如果仅仅是作为slave那么只有"rpl_semi_sync_slave_enable","rpl_semi_sync_trace_level"这两个状态，其它的4个是作为master端显示的，由于我这里是配置双主模式，所有主从都存在。
6.状态参数
show status like '%rpl_%';
这些状态参数比较重要，通常用来对半同步复制进行分析。
Rpl_semi_sync_master_clients：有多个个半同步复制的从库，对于当前的主来说只有backup是半同步复制的从库，而slave是异步复制，所以这里是1；
Rpl_semi_sync_master_net_avg_wait_time：master等待从库的平均响应时间，单位微妙
Rpl_semi_sync_master_net_wait_time： master等待从库响应的总时间，单位微妙
Rpl_semi_sync_master_net_waits：master等待从库响应的总次数
Rpl_semi_sync_master_no_times：master关闭半同步复制的次数，也就是当主从延时超过规定的时间转换为异步复制的次数。
Rpl_semi_sync_master_no_tx：master提交没有被slave响应成功的次数，也可以理解为不是同步半同步复制的次数。
Rpl_semi_sync_master_status：仅当当前服务器作为主库，是否开启了半同步复制，如果这里是OFF代表是异步复制，前提是当前查询的服务器是主服务器。
Rpl_semi_sync_master_timefunc_failures：master调用时间函数失败的次数，例如：gettimeofday().
Rpl_semi_sync_master_tx_avg_wait_time：master等待每一个事务的平均时间，单位微妙
Rpl_semi_sync_master_tx_wait_time：master等待事务的总时间，单位微妙
Rpl_semi_sync_master_tx_waits：master等待事务的总次数
Rpl_semi_sync_master_wait_pos_backtraverse：发生master写入的binlog的数量和slave响应返回的binlog数量不一致的次数。
Rpl_semi_sync_master_wait_sessions：当前等待slave响应的回话数量，该状态可以反应当前主从延时包括压力的情况
Rpl_semi_sync_master_yes_tx：master提交被slave成功响应的次数
Rpl_semi_sync_slave_status：仅当当前服务器作为从库，半同步复制是否开启，on代表开启。
注意：如果仅仅是作为slave那么只有"rpl_semi_sync_slave_status"这1个状态，其它的状态是作为master端显示的，由于我这里是配置双主模式，所有主从都存在。
注意：注意关注上面颜色加粗的这些状态
三、测试
模拟从库宕机
stop slave;
在master执行插入操作
主库上面等待响应的时间刚好是10S
从参数值也可以得到刚才有一次半同步复制失败
当从库重新启动复制之后，半同步复制也同样开启，刚才的插入记录也被异步复制应用了过来。
注意：开启半同步复制要加入到my.cnf文件中才能保证重启mysql服务后半同步复制也启用
SET GLOBAL rpl_semi_sync_master_enabled = 1;SET GLOBAL rpl_semi_sync_slave_enabled = 1;
参考：
http://dev.mysql.com/doc/refman/5.6/en/replication-semisync-interface.html
前面写的复制相关文章：
主从复制：
主主复制：
MMM:
总结
半同步复制虽然主从的binlog是同步的，但是主只是等待binlog写入到从库并不等待从库应用这部分binlog,而从库应用这部分binlog的操作则是异步的，所以主从的数据并不是实时同步的，所以只能叫做半同步复制。在5.7版本之前作为主从的业务都会遇到主从延时比较大的情况，特别是当主是密集写的情况这种延时就更加大，那是因为主是并发写也从库应用主的binlog是顺序执行导致从跟不上主，在5.7引入了并行复制，所谓的并行也就是将不相关的操作放在一个组里面这样从库就可以做到理论上的并行了从而提高主库应用binlog的速率，并且在5.7的半同步复制引入了一个新的参数“rpl_semi_sync_master_wait_point=AFTER_SYNC”该参数是控制主库响应从库的binlog发生在flush disk之前，在5.6版本当主库flush disk之后才发送binlog如果这时主库由于某种原因宕机了，这时如果客户端没有收到从库的响应那么客户端可能从新执行操作而这时主从已经做了切换客户端连接主库（之前是从库）再次执行之前的操作，这样当之前的主库（现在变成从库）启动之后变成从库后又重新应用了一次操作造成了数据写了两次，所以在5.7就把binlog的响应放在flush disk之前这样就不会存在数据重复写的情况了，默认该参数是开启的所以搭建方法和5.6是完全一致的不需要做什么改变。如果将该参数的值改成“rpl_semi_sync_master_wait_point=AFTER_COMMIT”则又变成5.6一样的方案。在后面会单独写一篇关于5.7复制有关的新改进的文章，欢迎关注。
| 备注： 作者： 博客： 本站点所有随笔都是原创，欢迎大家转载；但转载时必须注明文章来源，且在文章开头明显处给明链接。 《欢迎交流讨论》 |