背景
关于Group Commit网上的资料其实已经足够多了&＃xff0c;我这里只简单的介绍一下。
众所周知&＃xff0c;在MySQL5.6之前的版本&＃xff0c;由于引入了Binlog/InnoDB的XA&＃xff0c;Binlog的写入和InnoDB commit完全串行化执行&＃xff0c;大概的执行序列如下&＃xff1a;
当sync_binlog&＃61;1时&＃xff0c;很明显上述的第二步会成为瓶颈&＃xff0c;而且还是持有全局大锁&＃xff0c;这也是为什么性能会急剧下降。
很快Mariadb就提出了一个Binlog Group Commit方案&＃xff0c;即在准备写入Binlog时&＃xff0c;维持一个队列&＃xff0c;最早进入队列的是leader&＃xff0c;后来的是follower&＃xff0c;leader为搜集到的队列中的线程依次写Binlog文件, 并commit事务。Percona 的Group Commit实现也是Port自Mariadb。不过仍在使用Percona Server5.5的朋友需要注意&＃xff0c;该Group Commit实现可能破坏掉Semisync的行为&＃xff0c;感兴趣的点击bug#1254571
Oracle MySQL 在5.6版本开始也支持Binlog Group Commit&＃xff0c;使用了和Mariadb类似的思路&＃xff0c;但将Group Commit的过程拆分成了三个阶段&＃xff1a;flush stage 将各个线程的binlog从cache写到文件中; sync stage 对binlog做fsync操作&＃xff08;如果需要的话&＃xff09;&＃xff1b;commit stage 为各个线程做引擎层的事务commit。每个stage同时只有一个线程在操作。
Tips&＃xff1a;当引入Group Commit后&＃xff0c;sync_binlog的含义就变了&＃xff0c;假定设为1000&＃xff0c;表示的不是1000个事务后做一次fsync&＃xff0c;而是1000个事务组。
Oracle MySQL的实现的优势在于三个阶段可以并发执行&＃xff0c;从而提升效率。更进一步的理解&＃xff0c;可以参考这篇博客
XA Recover
在Binlog打开的情况下&＃xff0c;MySQL默认使用MYSQL_BIN_LOG来做XA协调者&＃xff0c;大致流程为&＃xff1a;
通过这种方式&＃xff0c;可以让InnoDB和Binlog中的事务状态保持一致。显然只要事务在InnoDB层完成了Prepare&＃xff0c;并且写入了Binlog&＃xff0c;就可以从崩溃中恢复事务&＃xff0c;这意味着我们无需在InnoDB commit时显式的write/fsync redo log。
Tips&＃xff1a;MySQL为何只需要扫描最后一个Binlog文件呢 &＃xff1f; 原因是每次在rotate到新的Binlog文件时&＃xff0c;总是保证没有正在提交的事务&＃xff0c;然后fsync一次InnoDB的redo log。这样就可以保证老的Binlog文件中的事务在InnoDB总是提交的。
问题
其实问题很简单&＃xff1a;每个事务都要保证其Prepare的事务被write/fsync到redo log文件。尽管某个事务可能会帮助其他事务完成redo 写入&＃xff0c;但这种行为是随机的&＃xff0c;并且依然会产生明显的log_sys->mutex开销。
优化
从XA恢复的逻辑我们可以知道&＃xff0c;只要保证InnoDB Prepare的redo日志在写Binlog前完成write/sync即可。因此我们对Group Commit的第一个stage的逻辑做了些许修改&＃xff0c;大概描述如下&＃xff1a;
通过延迟写redo log的方式&＃xff0c;显式的为redo log做了一次组写入&＃xff0c;并减少了log_sys->mutex的竞争。
目前官方MySQL已经根据我们report的bug#73202锁提供的思路&＃xff0c;对5.7.6的代码进行了优化&＃xff0c;对应的Release Note如下&＃xff1a;
性能数据
简单测试了下&＃xff0c;使用sysbench, update_non_index.lua, 100张表&＃xff0c;每张10w行记录&＃xff0c;innodb_flush_log_at_trx_commit&＃61;2, sync_binlog&＃61;1000&＃xff0c;关闭Gtid
京公网安备 11010802041100号