关于mysql:MySQL-核心模块揭秘-07-期-二阶段提交-1-prepare-阶段

116次阅读

共计 2909 个字符,预计需要花费 8 分钟才能阅读完成。

二阶段提交的 prepare 阶段,binlog 和 InnoDB 各自会有哪些动作?

本文基于 MySQL 8.0.32 源码,存储引擎为 InnoDB。

1. 二阶段提交

二阶段提交,顾名思义,蕴含两个阶段,它们是:

  • prepare 阶段。
  • commit 阶段。

咱们只思考 SQL 语句操作 InnoDB 表的场景,对于用户事务,是否应用二阶段提交,取决于是否开启了 binlog。

因为 MySQL 把 binlog 也看作一个存储引擎,开启 binlog,SQL 语句扭转(插入、更新、删除)InnoDB 表的数据,这个 SQL 语句执行过程中,就波及到两个存储引擎。

应用二阶段提交,就是为了保障两个存储引擎的数据一致性。

用户事务提交分为两种场景,如果开启了 binlog,它们都会应用二阶段提交。

场景 1:通过 BEGIN 或其它开始事务的语句,显式开始一个事务,用户手动执行 COMMIT 语句提交事务。

场景 2:没有显式开始的事务,一条 SQL 语句执行时,InnoDB 会隐式开始一个事务,SQL 语句执行实现之后,主动提交事务。

如果没有开启 binlog,SQL 语句扭转表中数据,不产生 binlog,不必保障 binlog 和表中数据的一致性,用户事务也就不须要应用二阶段提交了。

InnoDB 内部事务是个特例,不论是否开启了 binlog,扭转表中数据都不会产生 binlog 日志,所以内部事务不须要应用二阶段提交。

2. prepare 阶段

以下代码中,ha_prepare_low() 会调用 binlog 和 InnoDB 解决 prepare 逻辑的办法。

int MYSQL_BIN_LOG::prepare(THD *thd, bool all) {
  ...
  thd->durability_property = HA_IGNORE_DURABILITY;
  ...
  int error = ha_prepare_low(thd, all);
  ...
}

调用 ha_prepare_low() 之前,用户线程对象的 durability_property 属性值会被设置为 HA_IGNORE_DURABILITY

这个属性和 redo 日志刷盘无关,InnoDB prepare 会用到。

2.1 binlog prepare

binlog 被看作一种存储引擎,它也有 prepare 阶段,代码如下:

// sql/binlog.cc
static int binlog_prepare(handlerton *, THD *thd, bool all) {
  DBUG_TRACE;
  if (!all) {thd->get_transaction()->store_commit_parent(mysql_bin_log.m_dependency_tracker.get_max_committed_timestamp());
  }
  return 0;
}

二阶段提交时,all = true,不会命中分支 if (!all)。也就是说,在 prepare 阶段,binlog 什么也不会干。

2.2 InnoDB prepare

二阶段提交的 prepare 阶段,InnoDB 次要做五件事。

第 1 件,把调配给事务的所有 undo 段的状态从 TRX_UNDO_ACTIVE 批改为 TRX_UNDO_PREPARED

进入二阶段提交的事务,都至多扭转过(插入、更新、删除)一个用户表的一条记录,起码会调配 1 个 undo 段,最多会调配 4 个 undo 段。

具体什么状况调配多少个 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。

本期问题:二阶段提交的 prepare 阶段为什么不把 redo 日志刷盘?欢送大家留言交换。

下期预报:MySQL 外围模块揭秘 | 08 期 | 二阶段提交 (2) commit 阶段。

正文完
 0