MySQL核心模块揭秘|二阶段提交prepare阶段(2)

MySQL核心模块揭秘|二阶段提交prepare阶段

具体什么情况分配多少个 undo 段，后续关于 undo 模块的文章会有详细介绍。

不管 InnoDB 给事务分配了几个 undo 段，它们的状态都会被修改为 TRX_UNDO_PREPARED。

第 2 件，把事务 Xid 写入所有 undo 段中当前提交事务的 undo 日志组头信息。

InnoDB 给当前提交事务分配的每个 undo 段中，都会有一组 undo 日志属于这个事务，事务 Xid 就写入 undo 日志组的头信息。

对于第 1、2 件事，如果事务改变了用户普通表的数据，修改 undo 段状态、把事务 Xid 写入 undo 日志组头信息，都会产生 redo 日志。

第 3 件，把内存中的事务对象状态从TRX_STATE_ACTIVE修改为TRX_STATE_PREPARED。

前面修改 undo 状态，是为了事务提交完成之前，MySQL 崩溃了，下次启动时，能够从 undo 段中恢复崩溃之前的事务状态。

这里修改事务对象状态，用于 MySQL 正常运行过程中，标识事务已经进入二阶段提交的 prepare 阶段。

第 4 件，如果当前提交事务的隔离级别是读未提交（READ-UNCOMMITTED）或读已提交（READ-COMMITTED)，InnoDB 会释放事务给记录加的共享、排他 GAP 锁。

虽然读未提交、读已提交隔离级别一般都只加普通记录锁，不加 GAP 锁，但是，外键约束检查、插入记录重复值检查这两个场景下，还是会给相应的记录加 GAP 锁。

第 5 件，调用 trx_flush_logs()，处理 redo 日志刷盘的相关逻辑。

static void trx_flush_logs(trx_t *trx, lsn_t lsn) {
  ...
  switch (thd_requested_durability(trx->mysql_thd)) {
    case HA_IGNORE_DURABILITY:
      /* We set the HA_IGNORE_DURABILITY
      during prepare phase of binlog group commit
      to not flush redo log for every transaction here. 
      So that we can flush prepared records
      of transactions to redo log in a group
      right before writing them to binary log
      during flush stage of binlog group commit. */
      break;
    case HA_REGULAR_DURABILITY:
      ...
      trx_flush_log_if_needed(lsn, trx);
  }
}

从名字上看，trx_flush_logs() 的作用是把事务产生的 redo 日志刷盘。

前面介绍过，MYSQL_BIN_LOG::prepare() 调用ha_prepare_low()之前，就已经把当前事务所属用户线程对象的durability_property属性设置为HA_IGNORE_DURABILITY了。

从上面的代码可以看到，用户线程对象的durability_property属性值为HA_IGNORE_DURABILITY，prepare 阶段并不会把 redo 日志刷盘。

3. 总结

开启 binlog 的情况下，用户事务需要使用二阶段提交来保证 binlog 和 InnoDB 表的数据一致性。

binlog prepare 什么也不会干。

InnoDB prepare 会把分配给事务的所有 undo 段的状态修改为 TRX_UNDO_PREPARED，把事务 Xid 写入 undo 日志组的头信息，把内存中事务对象的状态修改为 TRX_STATE_PREPARED。

上述的关于MySQL核心模块揭秘|二阶段提交prepare阶段的详细讲解，IT袋网小编希望本文能给你带来生活上的帮助！