在mysql异步复制的情况下，Mysql Master Server将自己的Binary Log通过复制线程传输出去以后，Mysql Master Sever就自动返回数据给客户端，而不管slave上是否接受到了这个二进制日志。在半同步复制的架构下，当master在将自己binlog发给slave上的时候，要确保slave的IO_THREAD接收日志写入relay-log以后，才会返回数据给客户端。对比两种架构：异步复制对于用户来说，可以确保得到快速的响应结构，但是不能确保二进制日志确实到达了slave上；半同步复制对于客户的请求响应稍微慢点，但是他可以保证二进制日志的完整性。备库Crash时，主库会在某次等待超时后，关闭Semi-sync的特性，降级为普通的异步复制。如图
优点:
当事务返回客户端成功后，则日志一定在至少两台主机上存在。MySQL在加载并开启Semi-sync插件后，每一个事务需等待备库接收日志后才返回给客户端。如果做的是小事务，两台主机的延迟又较小，则Semi-sync可以实现在性能很小损失的情况下的零数据丢失。
缺点:
完成单条事务增加了额外的等待延迟，延迟的大小取决于网络的好坏。Semi-sync不是分布式事务，主库会在自己完成事务后，等待备库接收事务日志。
主库Crash后，那么可能存在一些事务已经在主库Commit，但是还没有传给任何备库，我们姑且称这类事务为"墙头事务"。"墙头事务"都是没有返回给客户端的，所以发起事务的客户端并不知道这个事务是否已经完成。这时，如果客户端不做切换，只是等Crash的主库恢复后，继续在主库进行操作，客户端会发现前面的"墙头事务"都已经完成，可以继续进行后续的业务处理；另一种情况，如果客户端Failover到备库上，客户端会发现前面的“墙头事务”都没有成功，则需要重新做这些事务，然后继续进行后续的业务处理。为了防止"墙头事务"有人提议把Waiting Slave dump提前一步。如图
环境规划
服务器IP 节点名称
192.168.255.143(master) node143
192.168.255.144(slave) node144
在master的操作
1.install plugin rpl_semi_sync_master SONAME 'semisync_master.so'; #安装插件
2.set global rpl_semi_sync_master_enabled = 1; #开启半同步
在slave的操作
1.install plugin rpl_semi_sync_slave soname ‘semisync_slave.so’;
2.set global rpl_semi_sync_slave_enabled = 1; #开启半同步
3.重启replication(stop slave;start slave;)
参数说明
Rpl_semi_sync_master_clients # 半同步复制客户端的个数
Rpl_semi_sync_master_net_avg_wait_time #平均等待时间（默认毫秒）
Rpl_semi_sync_master_net_wait_time #总共等待时间
Rpl_semi_sync_master_net_waits #等待次数
Rpl_semi_sync_master_no_times #关闭半同步复制的次数
Rpl_semi_sync_master_no_tx #表示没有成功接收slave提交的次数
Rpl_semi_sync_master_status #表示当前是异步模式还是半同步模式，on为半同步
Rpl_semi_sync_master_timefunc_failures #调用时间函数失败的次数
Rpl_semi_sync_master_tx_avg_wait_time #事物的平均传输时间
Rpl_semi_sync_master_tx_wait_time #事物的总共传输时间
Rpl_semi_sync_master_tx_waits #事物等待次数
Rpl_semi_sync_master_wait_pos_backtraverse # 网上有人理解为"后来的先到了，而先来的还没有到的次数"
Rpl_semi_sync_master_wait_sessions #当前有多少个session因为slave的回复而造成等待
Rpl_semi_sync_master_yes_tx #成功接受到slave事物回复的次数