MySQL 多事务引擎XA-CSDN博客

有那么一坨代码，他虽然在那里，我们却很少用到。。那就是MySQL的多XA事务引擎特性支持。。本周我们来探讨下TC LOG MMAP的代码实现。由于工作的关系，这块很少涉及，正好趁着周末补补漏。

本文分析的代码基于支持Tokudb的MySQL5.6.16 和MySQL 5.7.5；原因是官方MySQL还不包含多个事务引擎，因此代码压根走不到TC LOG MMAP. 但是MySQL5.7又Fix掉了相关的XA BUG （bug#47134），因此本文贴出的代码部分以MySQL5.7.5为主，调试部分以我们支持TOKUDB的MySQL5.6.16内部分支为主。

1.准备工作

为了能够使用到TC LOG MMAP，我们需要禁止binlog和gtid。如果仅仅关掉binlog，但gtid没有关闭，也会阻止实例启动

2.实例启动时的初始化

在实例启动时，会选择使用哪种XA方式，默认的就是BINLOG和ENGINE做XA，如果BINLOG禁止了，则使用引擎本身做XA

相关代码(sql/mysqld.cc: init_server_components)：

4011   if (total_ha_2pc > 1 || (1 == total_ha_2pc && opt_bin_log))
4012   {
4013     if (opt_bin_log)
4014       tc_log= &mysql_bin_log;
4015     else
4016       tc_log= &tc_log_mmap;
4017   }
4018   else
4019     tc_log= &tc_log_dummy

其中total_ha_2pc代表了支持了二阶段提交（2PC）的引擎数目，在初始化各个存储接口时（函数ha_initialize_handlerton），如果发现引擎的prepare接口函数被定义了，就会给total_ha_2pc++; 注意binlog模块也算是支持2PC的引擎

#不存在支持2PC的引擎，或者只有1个支持2PC的引擎且没有打开Binlog时，使用tc_log_dummy做协调者;对应类TC_LOG_DUMMY

#打开binlog时，使用mysql_bin_log做2PC协调者; 对应类MYSQL_BIN_LOG

#没有打开binlog，且存在超过两个支持2PC的引擎时，使用tc_log_mmap做协调者；对应类TC_LOG_MMAP

这三个类对象皆继承自TC_LOG，关系图如下：

对于TC_LOG_DUMMY，直接调用引擎接口做PREPARE/COMMIT/ROLLBACK，基本不做任何协调；

对于MYSQL_BIN_LOG，这算是我们最熟悉的部分了，实际上binlog接口不做prepare，只做commit，也就是写BINLOG到文件中。所有写入Binlog的事务，在崩溃恢复时，都应该能够提交。

本文的重点是TC_LOG_MMAP，因此其他两类不在这里展开阐述。

注意下文所有的讨论前提，都是基于BINLOG已经被彻底关闭！！！

3. TC LOG初始化

在确定了使用tc_log_mmap后，就会调用TC_LOG_MMAP::open 打开/初始化日志文件，文件名默认为tc.log，存放在$DATA目录下，文件主要用来持久化维护事务的XID信息

当tc.log文件不存在时，就创建该文件，并将文件大小初始化到24KB

当tc.log文件存在时，表示上次使用的是tc_log_mmap，那么就需要走崩溃恢复逻辑。

对tc.log的操作，使用mmap的方式映射到内存中：

data= (uchar *)my_mmap(0, (size_t)file_length, PROT_READ|PROT_WRITE,
MAP_NOSYNC|MAP_SHARED, fd, 0);

tc.log 以PAGE来进行划分，每个PAGE大小为8K，至少需要3个PAGE，初始化的文件大小也为3个PAGE（TC_LOG_MIN_SIZE），每个Page对应的结构体对象为st_page，因此需要根据page数，完成文件对应的内存控制对象的初始化。

在完成st_page初始化后，如果需要进入崩溃恢复逻辑（启动实例时tc.log文件已经存在），则调用TC_LOG_MMAP::recover进入崩溃恢复处理（后文讨论）

初始化第一个page的header，写入magic number以及当前的2PC引擎数（也就是total_ha_2pc）

下图描述了tc.log的文件结构:

4.事务Prepare/Commit

假定我们做了如下操作序列，其中sbtest1为Innodb表，sbtest2为tokudb表；

BEGIN;

update sbtest1 set k =k+1 where id = 2;

update sbtest2 set k =k+1 where id = 2;

commit;

当遇到第一个UPDATE时，会去注册XA，设置XID。backtrace如下：

mysql_update

|–>lock_table –>mysql_lock_tables–>lock_external–>handler::ha_external_lock–>ha_innobase::external_lock–>innobase_register_trx–>trans_register_ha

if (thd->transaction.xid_state.xid.is_null())
thd->transaction.xid_state.xid.set(thd->query_id);

XID根据会话当前的query_id来设置，由于query id是递增的，因此能保证xid唯一性。

（如果是先UPDATE TOKUDB表，则是另外一个trace：lock_external–>handler::ha_external_lock–>ha_tokudb::external_lock–>ha_tokudb::create_txn-->trans_register_ha）

总之，不管先更新哪个表，xid只注册一次，在事务完成前都不会变化了。

当事务提交COMMIT时，实际上是分两步走的，第一步是Prepare，第二步是Commit;

mysql_execute_command–>trans_commit–>ha_commit_trans:

if (!trn_ctx->no_2pc(trx_scope) && (trn_ctx->rw_ha_count(trx_scope) > 1))
error= tc_log->prepare(thd, all);

当事务中使用超过两个XA事务引擎时，就会走到XA PREPARE的逻辑，如果只使用一个引擎，是无需PREPARE的。

TC_LOG_MMAP::prepare的实现很简单，就是直接调用引擎的PREPARE接口函数（ha_prepare_low）

通常事务引擎都会在引擎层写一个PREPARE的REDO 日志，例如TOKUDB和INNODB。

当完成Prepare后，就进入Commit阶段，这里会稍微复杂点。XA事务COMMIT的入口为TC_LOG_MMAP::commit，分为以下几个步骤：

Step 1: 获取XID

my_xid xid= thd->transaction.xid_state.xid.get_my_xid();

在遇到第一个UPDATE时XID已经设置好了。对应unsigned longlong的query id

Step2: 记录XID到tc.log中

if (all && xid)
if (!(cookie= log_xid(thd, xid)))
DBUG_RETURN(RESULT_ABORTED); // Failed to log the transaction

为了将XID写入到TC日志中，首先需要选择一个PAGE。

TC_LOG_MMAP对PAGE的管理，采用一种POOL结构，在刚启动时的初始化时，active指针指向第一个Page, pool指针指向第二个page， pool_last_ptr指向最后一个page结尾.

通过active、pool、pool_last_ptr三个指针实现了PAGE POOL的管理。

记录XID的流程如下：

1)持有LOCK_tc锁

2)获取active page

–#如果当前active的page中没有空闲空间，则condition wait (COND_active)

–#如果没有active的page，则从POOL中取一个PAGE（TC_LOG_MMAP::get_active_from_pool），根据注释描述，有两种策略：

–# take the first from the pool
–# if there’re waiters – take the one with the most free space.

然后将active指针指向选择的page

3)将xid写入到active page中（store_xid_in_empty_slot），Page状态被设置成PS_DIRTY。

同时返回一个cookie：

cookie= (ulong)((uchar *)p->ptr – data_arg). 通过cookie，我们可以快速定位到写入的page位置

4)如果syncing指针被设置，表示有别的线程正在sync文件，等待直到其完成(wait_sync_completion)

注意这里可能别的线程sync的正是当前page，因此再次检查st_page::state是否为PS_DIRTY。如果不是，就无需去sync 当前page了，直接返回;

5)将active的page指针赋值给syncing，同时设置active为NULL.

6)释放LOCK_tc锁。

7)写syncing的page，刷到磁盘，调用函数TC_LOG_MMAP::sync

完成sync后，持有LOCK_tc，将该page丢到POOL末尾，唤醒可能在step4等待的线程。syncing被重置为NULL.

可以看到，在写一个XID的过程中，PAGE经历了，从ACTIVE ==> SYNCING ==> POOL的三种状态转变。

Step3: 到引擎层提交事务（ha_commit_low）

不赘述，各个引擎各自实现。

Step4: 重置XID.

if (cookie)
if (unlog(cookie, xid))
DBUG_RETURN(RESULT_INCONSISTENT); // Transaction logged, committed, but not unlogged.

调用函数TC_LOG_MMAP::unlog，前面提到的cookie这里就起到作用了，我们可以直接定位到PAGE的内存位置：

PAGE *p= pages + (cookie / tc_log_page_size);

my_xid *x= (my_xid *)(data + cookie);

将在记录的XID设置为0，同时递增st_page::free，表示已经释放了一个空闲的slot。

5.崩溃恢复

崩溃恢复时，我们需要所有已经记录的XID都要COMMIT掉。

函数TC_LOG_MMAP::recover

和BINLOG做XA Recover类似，TC_LOG_MMAP也是在崩溃恢复时，读取记录在tc.log文件中的XID；所有已经记录的XID对应的事务，在引擎层都需要COMMIT