MySQL 外部XA事务怎么安全恢复？

• 应用程序（AP）：定义事务边界，并指定构成事务的操作

• 资源管理器（RM）：提供对共享资源的访问

• 事务管理器（TM）：为事务分配唯一标识符，监视其进度，并负责事务的提交，回滚和故障恢复

MySQL的XA事务中，MySQL是资源管理器，事务管理器是连接MySQL的客户端。XA的协议主要描述了事务管理器与资源管理器之间的接口：

在MySQL中，常用的XA接口有：

• XA START，负责开启或者恢复一个XA事务，将事物状态设置为ACTIVE

• XA END，将事务状态设置为IDLE状态，可通过XA START进行恢复

• XA PREPARE，通知资源管理器，准备提交事务，将事务设置为PREPARED状态

• XA COMMIT，通知资源管理器，提交XA事务

• XA ROLLBACK，通知资源管理器，回滚XA事务

XA协议采用两阶段提交的方式来保证全局事务的原子性，两阶段提交的过程如下：

1. 第一阶段，事务管理器发起PREPARE请求，询问所有资源管理器是否可以提交事务，资源管理器根据自身状态回复YES或者NO，在回复YES前，资源管理器会将事务持久化并设置为PREPARED状态

2. 第二阶段，事务管理器根据前一阶段的结果来决定是提交还是回滚事务，如果所有节点均返回YES，那么通知所有节点提交事务，否则通知所有节点回滚事务

MySQL支持多存储引擎，为了保证binlog以及各个存储引擎之间的一致性，MySQL引入了两阶段提交，每个事务都是XA事务。这些事务按照事务管理器（两阶段提交中的协调者）所在位置可分为外部XA事务和内部XA事务：

• 内部XA事务，事务管理器位于MySQL内部，一个事务跨多个存储引擎进行读写，就会产生内部XA事务。其中binlog是一个特殊的参与者，因此，尽管一个事务只修改一个存储引擎，由于binlog的存在，也会启动内部XA事务。崩溃恢复的时候根据binlog内容来决定InnoDB引擎中的事务是提交还是回滚，binlog中存在的XA事务，在InnoDB中会提交相应的事务，如果一个事务在binlog中不存在，那么在InnoDB层会回滚该事务。

• 外部XA事务，由外部的事务管理器控制，用户使用XA start， XA end，XA prepare和XA commit接口来操作XA事务，可以修改多个节点的数据。MySQL-8.0.30以前，崩溃恢复的时候MySQL对InnoDB中处于prepared状态的外部XA事务统一不做处理，因此外部XA事务不保证crash safe（即，binlog和InnoDB中的事务可能出现不一致）。

  
  

  
  

binlog prepare

InnoDB prepare

其中binlog prepare阶段会将XA prepare语句写入binlog，然后再将InnoDB中XA事务的状态设置为prepared，这个过程不是crash safe的（已知bug：https://bugs.mysql.com/bug.php?id=88534 ），有如下的问题：

1. 写完XA prepare的binlog后立即crash

   
   

   
   

   
   

   binlog prepare
   

↓ crash

InnoDB prepare





此时InnoDB中事务的状态还是active，下次启动的时候active状态的事务被直接回滚，造成binlog和InnoDB不一致，进而导致主从不一致。

2. 如果交换binlog和InnoDB的prepare顺序

InnoDB prepare


↓ crash

binlog prepare





在InnoDB prepare完成后立即crash，此时InnoDB中事务的状态是prepared，而binlog中还没有对应的日志（崩溃恢复的时候不会回滚已经处于prepared状态的外部XA事务），导致binlog和InnoDB不一致。

上面的bug链接可以看到更多相关的讨论，bug报告者也提出了一种解决方法（以XA prepare 为例）：

1. XA prepare的顺序：InnoDB prepare，binlog prepare

2. 仿照Previous_gtid_log_event，在binlog中新增一个event，用于记录已经处于prepared状态的XA事务的xid

3. 崩溃恢复过程中，根据binlog中记录的xid来决定是回滚还是保留InnoDB中处于prepared状态的外部XA事务

/** contains an undo log of an prepared transaction */
constexpr uint32_t TRX_UNDO_PREPARED = 6;
/* contains an undo log of a prepared transaction that has been processed by the
 * transaction coordinator */
constexpr uint32_t TRX_UNDO_PREPARED_IN_TC = 7;

enum class enum_ha_recover_xa_state : int {
  NOT_FOUND = -1,               // Trnasaction not found
  PREPARED_IN_SE = 0,           // Transaction is prepared in SEs
  PREPARED_IN_TC = 1,           // Transaction is prepared in SEs and TC
  COMMITTED_WITH_ONEPHASE = 2,  // Transaction was one-phase committed
  COMMITTED = 3,                // Transaction was committed
  ROLLEDBACK = 4                // Transaction was rolled back
};

if (trx_state_eq(trx, TRX_STATE_PREPARED)) {
  if (trx_is_prepared_in_tc(trx)) {
  /* 事务处于XA prepare的第二阶段，将该事务加到XA事务状态链表中去，并修改事务状态为PREPARED_IN_TC*/
    xa_list.add(*trx->xid, enum_ha_recover_xa_state::PREPARED_IN_TC);
  } else {
  /*否则，将该事务加到XA事务状态链表中去，并修改事务状态为PREPARED_IN_SE*/
    xa_list.add(*trx->xid, enum_ha_recover_xa_state::PREPARED_IN_SE);
  }
}

enum_ha_recover_xa_state Xa_state_list::add(XID const &xid,
                                            enum_ha_recover_xa_state state) {
  auto previous_state = enum_ha_recover_xa_state::NOT_FOUND;


  auto it = this->m_underlying.find(xid);
  if (it != this->m_underlying.end()) previous_state = it->second;


  switch (state) {
    case enum_ha_recover_xa_state::PREPARED_IN_SE: {
      if (previous_state == enum_ha_recover_xa_state::NOT_FOUND ||
          previous_state == enum_ha_recover_xa_state::COMMITTED ||
          previous_state == enum_ha_recover_xa_state::ROLLEDBACK)
        this->m_underlying[xid] = state;
      break;
    }
    case enum_ha_recover_xa_state::PREPARED_IN_TC: {
      if (previous_state == enum_ha_recover_xa_state::NOT_FOUND ||
          previous_state == enum_ha_recover_xa_state::PREPARED_IN_SE)
        this->m_underlying[xid] = state;
      break;
    }
    case enum_ha_recover_xa_state::NOT_FOUND:
    case enum_ha_recover_xa_state::COMMITTED:
    case enum_ha_recover_xa_state::COMMITTED_WITH_ONEPHASE:
    case enum_ha_recover_xa_state::ROLLEDBACK: {
      assert(false);
      break;
    }
  }
  return previous_state;
}

bool xa::recovery::recover_one_ht(THD *, plugin_ref plugin, void *arg) {
  handlerton *ht = plugin_data<handlerton *>(plugin);
  xarecover_st *info = static_cast<struct xarecover_st *>(arg);
  int got;


  if (ht->state == SHOW_OPTION_YES && ht->recover) {
    while (
        (got = ht->recover(
             ht, info->list, info->len,
             Recovered_xa_transactions::instance().get_allocated_memroot())) >
        0) {
      // 从引擎层获取所有处于prepared状态的事务
      for (int i = 0; i < got; ++i) {
        auto &xa_trx = info->list[i];
        my_xid xid = xa_trx.id.get_my_xid();


        if (!xid) {  // 处理外部XA事务
          ::recover_one_external_trx(*info, *ht, xa_trx, external_stats);
          ++info->found_foreign_xids;
          continue;
        }


        if (info->dry_run) {
          ++info->found_my_xids;
          continue;
        }


        // 处理内部XA事务
        ::recover_one_internal_trx(*info, *ht, xa_trx, xid, internal_stats);
      }
      if (got < info->len) break;
    }
  }
  return false;
}

MySQL 8.0.30通过新增一种undo状态，实现了crash safe的外部XA事务，读者有兴趣可自行阅读相关代码，加深理解。