mysql 组提交group commit
转载
前言
- 操作系统使用页面缓存来填补内存和磁盘访问的差距
- 对磁盘文件的写入会先写入道页面缓存中
- 由操作系统来决定何时将修改过的脏页刷新到磁盘
- 确保修改已经持久化到磁盘,须调用fsync或者fdatasync
- 数据库在事务提交过程中调用fsync将数据持久化到磁盘,才满足ACID中的D(持久化)
- fsync是昂贵的操作,对于普通磁盘,每秒能完成几百次fsync
- MySQL中使用了两阶段提交协议,为了满足D(持久化) ,一次事务提交最多会导致3次fsync
- 提交的事务在存储引擎内部(redo log)中准备好,一次fsync;事务写入到binlog中并刷盘持久化,一次fsync;事务在存储引擎内部提交,一次fsync(可以省略,存储引擎准备好的事务可以通过binlog来恢复)
改进
- 为了提高单位时间内的事务提交数,必须减少事务提交过程中的fsync调用次数
- MySQL 从5.6版本开始引入group commit技术(MariaDB 5.3版本引入)
- 基本思想是多个并发提交的事务共用一次fsync操作来实现持久化
group commit
An InnoDB optimization that performs some low-level I/O operations (log write) once for a set of commit operations, rather than flushing and syncing separately for each commit
原理
- 多个并发需要提交的事务共享一次fsync操作来进行数据的持久化
- 将fsync操作的开销平摊到多个并发的事务上去
- group commit 不是在任何时候都能发挥作用,要有足够多并发的需要提交的事务
实现
- 多个并发提交的事务在写redo log或binlog前会被加入到一个队列中
- 队列头部的事务所在的线程称为leader线程,其它事务所在的线程称为follower线程
- leader线程负责为队列中所有的事务进行写binlog操作,此时,所有的follower线程处于等待状态
- 然后leader线程调用一次fsync操作,将binlog持久化
- 最后通知follower线程可以继续往下执行
参数
binlog_group_commit_sync_delay=N
定时发车,在等待N 微秒后,进行binlog刷盘操作
binlog_group_commit_sync_no_delay_count=N
人满发车,达到最大事务等待数量,开始binlog刷盘,忽略定时发车
注意
-
当binlog_group_commit_sync_delay=0时,binlog_group_commit_sync_no_delay_count参数设置无效,即没有定时发车情况下,人满发车也就没有了_
-
当sync_binlog=0或sync_binlog=1,在刷盘前,对每个binlog应用定时发车
-
当sync_binlog=N(N>1),在每N个binlog后应用定时发车
-
设置了定时发车增加了并发提交事务的数量,从而增加slave并行apply的速度(slave开启多线程复制)
-
定时发车增加了事务提交的延迟,在高并发情况下,延迟有可能增加争用从而减少吞吐量
-
定时发车有优点也有缺点,要更具业务负载持续优化来决定最佳设置
参考