文章目录
  1. group commit

redo：恢复提交事务修改的页操作；undo：回滚行记录到某个特定的版本。

redo是物理日志，记录页的物理修改操作；undo是逻辑日志，对每个行记录进行日志的记录。

redo用来保证事务的持久性；

undo只是将数据库在逻辑上恢复到事务执行前的状态，在物理层面，并不保证与事务执行前的状态完全相同。

group commit

事务提交会进行两个阶段的操作：

  • 修改内存中事务对应的信息，将日志写入重做日志缓冲；
  • 调用fsync将日志从重做日志缓冲写入磁盘；

group commit将多个事务的重做日志通过一次fsync刷新到磁盘，提高了数据库的整体性能。

开启二进制日志后，为保证存储引擎层中的事务与二进制日志的一致性，二者使用了两阶段事务，

  • 事务提交时InnoDB存储引擎进行perpare操作；
  • MySQL数据库上层写入二进制日志；
  • InnoDB存储引擎将日志写入重做日志文件：(1)修改内存中事务对应的信息，并将日志写入重做日志缓冲；(2)调用fsync将日志从重做日志缓冲写入磁盘。

整个过程如下图。

 

在MySQL5.6之前，为保证MySQL数据库上层二进制日志的写入顺序与InnoDB层的事务提交顺序一致，InnoDB存储引擎使用prepare_commit_mutex这个锁；那么在prepare_commit_mutex加锁之后，其他要提交的事务在”MySQL数据库上层写入二进制日志”这一步就需要等待。

为解决加锁之后不能group commit的问题，使用队列来组织所有要提交的事务的日志。

MySQL5.6 BLGC的实现方式为将事务提交的过程分为如下几步。

 

  • Flush阶段：将事务的二进制日志写入内存；
  • Sync阶段：将内存中的二进制日志刷新到磁盘；
  • Commit阶段：事务按照先后顺序被提交；

这样一组事务在进行group commit时，其他事务可以进行Flush阶段。