在MySQL事务执行的过程中,innodb引擎会产生redo log,我们知道,MySQL的事务提交是两阶段提交的,画图如下:
通常来讲,redo log刷盘的时机是在事务提交的commit阶段采取刷盘的,在此之前,redo log都存在于redo log buffer这块指定的内存区域中。
这里我们首先要明确两个概念和两个参数:
write:刷盘
fsync:持久化到磁盘
write(刷盘)指的是MySQL从buffer pool中将内容写到系统的page cache中,并没有持久化到系统磁盘上。这个速度其实是很快的。
fsync指的是从系统的cache中将数据持久化到系统磁盘上。这个速度可以认为比较慢,而且也是IOPS升高的真正原因。
参数:
innodb_flush_logs_at_trx_commit(该参数针对redo log)
取值0:每次提交事务都只把redo log留在redo log buffer中
取值1:每次提交事务都将redo log 持久化到磁盘上,也就是write+fsync
取值2:每次都把redo log写到系统的page cache中,也就是只write,不fsync
sync_binlog(改参数针对binlog)
取值0:每次提交都将binlog 从binlog cache中 write到磁盘上,而不fsync到磁盘
取值1:每次提交事务都将binlog fsync到磁盘上
取值N:每次提交事务都将binlog write到磁盘上,累计N个事务之后,执行fsync
但是,在某些特定场景下,redo log会在commit这个动作到来之前进行刷盘操作,例如下面的两种情况会让没有提交的事务的redo log写入磁盘:
1、redo log buffer占用的空间即将达到buffer pool的一般的时候,后台线程会主动刷盘,这个时候,由于事务没有提交,所以仅仅是将redo log buffer中的内容通过write的方法写入到系统的cache中,没有进行fsync的持久化动作。
2、并行提交事务的时候,会顺带将上一个事务的部分redo log从redo log buffer中fsync到磁盘上,例如下面的例子:
假设redo log buffer中的内容如下(假设每个事务的redo log有4部分):
redo log B1
redo log A1
redo log B2
redo log B3
redo log B4
此时,事务B发生了commit操作,而设置的innodb_flush_logs_at_trx_commit的值是1,那么会触发事务B的redo log持久化到磁盘。此时事务A的一部分redo log,也就是redo log A1会被顺带着持久化fsync到磁盘中。
这里还需要说明一点,因为MySQL的innodb存储引擎时需要支持崩溃恢复的,依赖prepare阶段的redo log ,所以,如果innodb_flush_logs_at_trx_commit的值是1,MySQL会在redo log的prepare阶段就进行一次持久化redo log的fsync操作。这个fsync的存在,再加上每秒一次的后台刷盘操作,innodb会认为redo log在commit的时候,就不需要fsync了,只write到文件系统的page cache就够了。
所以,真正的两阶段提交,应该是下面这个样子:
之所以redo log的write和fsync没有连接在一起,其实是考虑到了组提交的功能,分开来进行这两个步骤,在并发的场景下,可以让这一组一次性提交的redo log更多一点,从而一次性fsync更多的组员。
最后,回答一个问题,我们知道innodb采用了WAL技术(先写log,再写磁盘)来减少磁盘写。但是我们上面的分析过程不难看出,在事务提交的过程中,redo log prepare阶段会进行一次fsync磁盘,binlog 阶段也会fsync一次磁盘,这似乎并没有减少与磁盘的交互,MySQL这样设计的意义是什么?
其实这样的目的有两个:
其一:redo log和binlog都是顺序写,顺序写比数据页的随机写节约时间,性能更高
其二:组提交机制使得我们不用每个事务都进行写磁盘操作,而是将多个写操作放在一个组里面,这样可以大幅度降低磁盘的IOPS