adg类似于mysql半同步机制_MySQL5.7新特性半同步复制之AFTER_SYNC/AFTER_COMMIT的过程分析和总结...

MySQL 5.7增强了半同步复制，rpl_semi_sync_master_wait_point增加了AFTER_SYNC的值，由该参数AFTER_SYNC/AFTER_COMMIT两个值选择是否启用增强半同步.

当半同步模式为 AFTER_COMMIT时:

过程分析如下：

1 > session 发出commit请求

2 > flush binlog and fsync binlog

3 > InnoDB 引擎层 commit

4 > 发送binlog到SLAVE，等待slave发送ack确认

5 > slave 接受binlog 写入relay log ，刷盘完成发送ack确认包给master

6 > master 返回 commit ok 信息给session

另外 (master 等待事务A 的 ACK的时候宕机，此时新事务B在宕机之前开启)：

1> binlog 未发送到从库:

事务B获取到事务A提交的内容， 此时宕机故障切换到slave，事务B获取到的内容却丢失了。事务A commit没有收到反馈信息(则需要业务判断了)。

2> binlog 已经发送给从库 :

事务B获取到事务A提交的内容，故障切换到salve ，B仍然获取到A提交的内容，没毛病。事务A commit没有收到反馈信息，若重新执行该事务，则相当于执行两次A事务(则需要业务判断了)。

当半同步模式为 AFTER_SYNC(5.7版本推荐使用)时:

过程分析如下：

1 > session 发出commit请求

2 > flush binlog and fsync binlog

3 > 发送binlog到SLAVE，等待slave发送ack确认

4 > slave 接受binlog 写入relay log ，刷盘完成发送ack确认包给master

5 > InnoDB 引擎层 commit

6 > master 返回 commit ok 信息给session

另外(master 等待事务A 的 ACK的时候宕机，此时新事务B在宕机之前开启)：

1> 事务B读取不到事务A的内容，因为事务A的ENGINE层还没有提交(无损复制)

dump thread过程分析:

mysql5.6版本之前：

1> master dump thread 发送binlog events 给 slave 的IO thread，等待 slave 的ack回包

2> slave 接受binlog events 写入redo log ，返回 ack 包给master dump thread

3> master dump thread 收到ack包 ，给session返回commit ok，然后继续发送写一个事务的binlog。

mysql5.7之后新增ack线程：

1> master dump thread 发送binlog events 给 slave 的IO thread，开启ack线程等待 slave 的ack回包，dump 线程继续向slaveIO thread发送下一个事务的binlog。

2> slave 接受binlog events 写入redo log ，返回 ack 包给master ack线程，然后给session返回commit ok。

过程总结:

Master在收到slave的应答后才Commit事务--after_sync(5.6上Master在commit后，才等待Slave的应答--after commit).

因此在确认事务复制到Slave上之前，并发的事务看不到当前事务的数据.

当Master出现故障时,所有已经提交的事务都复制到了Slave上.

缺省采用无数据丢失的应答等待机制after_sync。用户也可以选择使用5.6的应答等待机制after_commit

设置方法:

mysql> SET rpl_semi_sync_master_wait_point= AFTER_SYNC;

Master接收到N个slave的应答后，才commit 事务.

用户可以设置应答Slave的数量:

mysql> SET GLOBAL rpl_semi_sync_master_wait_for_slave_count= N；

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15498/viewspace-2143986/，如需转载，请注明出处，否则将追究法律责任。