【MySQL】组提交技术的阅读思考-创新互联
组提交难点
一.给leader进程带来了不公平
创新互联公司坚持“要么做到,要么别承诺”的工作理念,服务领域包括:成都网站设计、成都做网站、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的常德网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!二.兼顾redo和binlog顺序的对应
三.事务redo与binlog的写流程与fsync时机(没有引进组提交时的流程)
四.为什么要组提交?(简单组提交下的弊病,硬件资源速度的不一致性,带来的优势)
关键参数与流程
flush阶段
将Binlog写入内存,(好像没有Binlog buffer的说法,直接写入内存,内存写入条带文件)。
- binlog_max_flush_queue_time 每多少秒去写入一次Binlog到内存(官方)。flush阶段中一批事务等待的时间。类似于检票处一次用Bodycheck牌挡住一定数量的人。默认0,这个参数已经废弃
sync->commit阶段,主要是在sync,sync(刷盘binlog)。若sync_binlog不为1,多个组应该卡在这儿。岂不是导致commit ack变慢?不对,只是加速
binlog_group_commit_sync_delay 应该是用来控制leader进度的,也就是发车间隔时间。这个是导致leader不公平的主要原因。单位微妙。微妙级别的话,相对于刷盘的时间,leader的不公平看起来微乎其微。
- binlog_group_commit_sync_no_delay_count 最低发车座位数, 类似于定员流水发车大巴,车上的人到达一定的数量后,直接发车,不在等待一个最小发车间隔
commit阶段 redo log buffer刷盘
sync_binlog的含义就变了,假定设为1000,表示的不是1000个事务后做一次fsync,而是1000个事务组。默认1的话就是,1个事务组提交一次fsync Binlog
也就是说,比如, 1-1000个事务,前面999个都没有sync,默认是sync成功的。第1000个事务时进行真正的binlog sync 。若中间挂了,没有sync成功,那么1-1000事务的binlog 都没有被记录- 第一次等待的时间可能不太好理解,,应该是第一次分批限流。比方说,保证流入sync阶段的都是按时间分段的,而不是离散的算是预分组吧。找不到很合适的例子说明
总结
在读写IO相对于内存的速度有很大差距的情况下,把单次离散写,合并成批量连续写。硬盘的寻道时间要比顺序写硬盘的时间要慢很多。尽量少寻道,也是一种思路
参考
阿里月报 201501
https://www.kancloud.cn/taobaomysql/monthly/67157
官方手册
https://dev.mysql.com/doc/refman/5.7/en/replication-options-reference.html
姜承尧
《Innodb存储引擎 P322》
延伸阅读
fb关于组提交的文章 发布时间:2010 年 10 月 7 日 周四 02:16
https://www.facebook.com/notes/mysql-at-facebook/group-commit/438641125932/
没有精力
其实看源码最直接,没有精力
另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
名称栏目:【MySQL】组提交技术的阅读思考-创新互联
文章网址:http://scyanting.com/article/ddhgii.html