符合中小企业对网站设计、功能常规化式的企业展示型网站建设
本套餐主要针对企业品牌型网站、中高端设计、前端互动体验...
商城网站建设因基本功能的需求不同费用上面也有很大的差别...
手机微信网站开发、微信官网、微信商城网站...
本篇内容主要讲解“MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析”吧!
创新互联拥有十载成都网站建设工作经验,为各大企业提供成都网站设计、成都做网站服务,对于网页设计、PC网站建设(电脑版网站建设)、app软件开发、wap网站建设(手机版网站建设)、程序开发、网站优化(SEO优化)、微网站、国际域名空间等,凭借多年来在互联网的打拼,我们在互联网网站建设行业积累了很多网站制作、网站设计、网络营销经验,集策划、开发、设计、营销、管理等网站化运作于一体,具备承接各种规模类型的网站建设项目的能力。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事务(则需要业务判断了)。
当半同步模式为 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;
到此,相信大家对“MySQL中AFTER_SYNC/AFTER_COMMIT的过程分析”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!