MySQL中AFTER_SYNC AFTER_COMMIT的过程分析
发布时间：2021-12-21 11:17:40 所属栏目：MySql教程 来源：互联网
导读：本篇内容主要讲解MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析吧! MySQL 5.7增强了半同步复制，rpl_semi_sync_master_wa
|
本篇内容主要讲解“MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析”吧! MySQL 5.7增强了半同步复制，rpl_semi_sync_master_wait_point增加了AFTER_SYNC的值，由该参数AFTER_SYNC/AFTER_COMMIT两个值选择是否启用增强半同步. mysql> SET rpl_semi_sync_master_wait_point= AFTER_SYNC; 开启了mysql 5.7增强半同步，5.7默认就是开启的； mysql> SET rpl_semi_sync_master_wait_point= AFTER_COMMIT; 5.6的半同步方式； 当半同步模式为 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事务(则需要业务判断了)。 MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析 当半同步模式为 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层还没有提交(无损复制) MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析 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； 到此，相信大家对“MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！ （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
热点阅读