13.3.7 XATransaction

InnoDB存储引擎支持XA事务。 MySQL XA 实现基于 X/Open CAE 文档*《分布式事务处理:XA 规范》。本文档由 The Open Group 发布,可在http://www.opengroup.org/public/pubs/catalog/c193.htm获得。 第 13.3.7.3 节“ XATransaction 限制”中描述了当前 XA 实现的局限性。

在 Client 端,没有特殊要求。 MySQL 服务器的 XA 接口包含以XA关键字开头的 SQL 语句。 MySQLClient 端程序必须能够发送 SQL 语句并理解 XA 语句接口的语义。他们不需要链接到最新的 Client 端库。较旧的 Client 端库也将起作用。

在 MySQL 连接器中,MySQL Connector/J 5.0.0 和更高版本通过可为您处理 XA SQL 语句接口的类接口直接支持 XA。

XA 支持分布式事务,即允许多个单独的事务资源参与全局事务的能力。事务性资源通常是 RDBMS,但可能是其他类型的资源。

全局事务涉及几个本身具有事务性的操作,但是所有操作必须要么作为一个组成功完成,要么全部作为一个组回滚。从本质上讲,这将 ACID 属性扩展到“一个级别”,以便可以将多个 ACID 事务作为具有 ACID 属性的全局操作的组成部分一起执行。 (与非分布式事务一样,如果您的应用程序对读取现象敏感,则SERIALIZABLE可能是首选。REPEATABLE READ可能不足以进行分布式事务。)

分布式事务的一些示例:

  • 应用程序可以充当将消息传递服务与 RDBMS 组合在一起的集成工具。该应用程序确保涉及消息发送,检索和处理的事务也涉及事务数据库,这些事务都在全局事务中发生。您可以将其视为“Transaction 电子邮件”。

  • 应用程序执行涉及不同数据库服务器的操作,例如 MySQL 服务器和 Oracle 服务器(或多个 MySQL 服务器),其中涉及多个服务器的操作必须作为全局事务的一部分发生,而不是作为每个服务器本地的独立事务发生。

  • 银行将帐户信息保存在 RDBMS 中,并通过自动柜员机(ATM)进行收款。必须确保 ATM 操作正确反映在帐户中,但这不能仅靠 RDBMS 来完成。全局事务 Management 器集成了 ATM 和数据库资源,以确保财务事务的总体一致性。

使用全局事务的应用程序涉及一个或多个资源 Management 器和一个事务 Management 器:

  • 资源 Management 器(RM)提供对事务性资源的访问。数据库服务器是一种资源 Management 器。必须能够提交或回滚 RMManagement 的事务。

  • 事务 Management 器(TM)协调作为全局事务一部分的事务。它与处理每个事务的 RM 通信。全局事务中的各个事务是全局事务的“分支”。全局事务及其分支由后面描述的命名方案标识。

XA 的 MySQL 实现使 MySQL 服务器可以充当资源 Management 器,用于处理全局事务中的 XA 事务。连接到 MySQL 服务器的 Client 端程序充当事务 Management 器。

要执行全局事务,必须知道涉及哪些组件,并将每个组件带到可以提交或回滚的地步。根据每个组件报告其成功能力的情况,它们都必须作为原子组全部提交或回滚。也就是说,要么所有组件都必须提交,要么所有组件都必须回滚。要 Management 全局事务,必须考虑到任何组件或连接网络都可能发生故障。

执行全局事务的过程使用两阶段提交(2PC)。这是在执行了全局事务的分支所执行的动作之后发生的。

  • 在第一阶段,准备所有分支。也就是说,TM 告诉他们准备提交。通常,这意味着 Management 分支的每个 RM 在稳定的存储中记录分支的动作。分支指示它们是否能够执行此操作,并将这些结果用于第二阶段。

  • 在第二阶段,TM 告诉 RM,是提交还是回滚。如果所有分支在准备就绪时都 table 示可以提交,则将告知所有分支进行提交。如果在准备就绪时指示任何分支将无法提交,则将告知所有分支回滚。

在某些情况下,全局事务可能使用一阶段提交(1PC)。例如,当事务 Management 器发现全局事务仅由一个事务资源(即单个分支)组成时,可以告知该资源同时准备和提交。