MySQL5.5引入了半同步复制（Semi-synchronous Replication），以下是对于半同步复制的认知和理解：

1. 半同步启动需要主从两端都需要加载安装各自对应的semi模块，从库端支持半同步功能的数量至少一台；主库端当一个事务成功提交后，并不及时反馈给前端用户，该线程会被临时block，等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt（回执确认），这时主库线程才返回给当前session告知操作完成，半同步复制并不关心在从库一端该事务是否都被执行并被提交完成。

2. 半同步与异步复制相比，进一步提高了数据完整性（不太理解为什么这么说），保证了事务成功提交后，有两份记录被记录下来，一份在主库上，另一份至少在一个从库上。

3. 半同步复制在平衡性能与数据可靠性方面，采用了network group commit的方式来复制binlog。半同步复制为了保证在主库上的每一次更新都能可靠的复制到从库上，当每次事务结束后，都需要等待从库的确认回执，这样即便有意外发生，从库也只是少了那一个事物，但是这样会产生频繁的roundtrip time，性能可想而知；而如果能增加每一次确认前被复制的事务个数，尽可能多的以一个batch的形式完成一次复制，这样效率会提高很多，但是随之带来的负面影响，就是故障发生后，从库丢失的就是一批事务。sysbench的压测结果会发现，性能并没有想象的落差很大，我测的结果几乎没什么变化。

4. 目前实现的所谓半同步复制，其实真正意义上不能叫作semi-synchronous replication，用Baron的话说应该叫作delayed-acknowledgment commits，也仍然属于asynchronous的概念；同时Baron也阐述了同步的概念：“In truly synchronous replication, when you commit a transaction, the commit does not complete until all replicas have also committed successfully.”

5. Baron的另一个观点：“semi-synchronous replication actually forces the client to be synchronized, not the replicas.”其实，native replication与现有实现的semi-sync replication就其复制架构本身并没有特别的变化，两种模式下，复制都是发生在主库commit操作完成之后。

6. 不建议在高延时的网络环境下使用半同步复制功能。

以下是配置和监控半同步复制：

1. 半同步复制功能以plugin的方式接入MySQL，需要在主库与从库两端同时开启半同步的支持，具体配置如下：

On the master

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’;

mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;

mysql> SET GLOBAL rpl_semi_sync_master_timeout = 1000;  # 1 second

On the slave

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’;

mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;

mysql> START SLAVE;

NOTE: SLAVE端需要先开启半同步参数，然后启动从库复制，否则，Rpl_semi_sync_slave_status的状态始终为：OFF。

2. 通过以下参数可以判断半同步是否正常：

Rpl_semi_sync_master_status -- 判断主库当前模式为半同步还是异步复制

Rpl_semi_sync_master_clients -- 当前处于半同步状态的从库个数

Rpl_semi_sync_master_yes_tx,Rpl_semi_sync_master_no_tx -- 主库收到正常确认以及超时未成功确认的事务个数

Rpl_semi_sync_slave_status -- 从库半同步复制是否正常，当io_thread为NO时，状态为OFF

查看半同步相关参数及状态参数命令：

mysql> SHOW VARIABLES LIKE ‘rpl_semi_sync%’;

mysql> SHOW STATUS LIKE ‘Rpl_semi_sync%’;

-TAKE AWAY-

半同步复制使MHA更加完美

在之前的文章中曾和大家分享过MHA这种高可用的主从自动的failover方案，而这里说的半同步复制对于MHA是一个很有利的支持。

半同步可以最大程度的保障主库执行过的语句被成功复制到从库relay log中；而当主库发生故障时，使从库的状态更接近主库，保持最小的数据差异。基于半同步这个特点，可以将其与MHA一起使用，当主库故障，故障自动切换被触发，在这个过程中MHA需要比较主库与从库日志差异，由于半同步的特点，差异日志会尽可能的少，那么MHA在进行判断比较、差异生成、拷贝直至最后的差异应用，这一系列的时间消耗都会得到缩减，这样MHA的切换时间就相应减少，数据库故障可以快速恢复。

正常情况下，主库写入binlog日志的pos位置与从库读到的Read_Master_Log_Pos位置应该保持一致；测试中发现，当主库被意外关掉，仍存在少量的跟新语句没有被同步过去，这一点在手册里面有提及（If the master commits but a crash occurs while the master is waiting for acknowledgment from a slave, it is possible that the transaction may not have reached any slave.）

建议继续学习：

1. MySQL半同步存在的问题    (阅读：2590)