MySQL 5.7中对XA支持的改进有哪些

本文主要向大家展示“MySQL 5.7中对XA支持做了哪些改进”，简单易懂，条理清晰，希望能帮大家解决疑惑。让边肖带领大家学习和研究这篇文章《MySQL 5.7中对XA支持做了哪些改进》。

00-1010xa解决了ACID属性在跨分布式资源时可以保留在单个事务中的问题。资源本身可以是其他MySQL服务器，甚至是其他不同的数据库技术。XA标准描述了全局事务管理器和本地资源管理器之间的交互。

正如介绍中提到的，MySQL 5.0引入了XA支持，增加了参与全局事务的能力。XA支持可以提供事务资源访问的资源管理器和可以在全局事务中协调事务的事务管理器。MySQL的XA实现了MySQL服务器充当资源管理器，而连接到MySQL服务器的客户端执行事务管理器的任务。

XA使用两阶段提交协议，其中第一阶段是发出提交请求，然后进行实际的提交。在全局事务的每个分支完成执行后，将启动两阶段提交协议：

在第一阶段，事务管理器发送一条消息，准备提交给参与全局事务的所有分支。在资源管理器确认准备好提交之前，它会记录并保存操作的记录结果，以便为第二阶段的实际提交做准备。

在第二阶段，如果事务管理器收到来自所有相关分支的明确响应，它会通知它们提交。但是，如果任何分支回答“否”，将通知所有分支执行回滚。

事务管理器与多个资源管理器交互，以处理全局事务中的单个事务/分支。下图描述了一个涉及资源管理器的XA事务。XA事务的语句以XA关键字、要执行的操作和唯一标识符开始。在下面的示例中，字符串“xatest”表示全局事务标识符。除了全局事务标识符，还可以为XA事务指定分支标识符和格式id。分支标识符用于标识本地事务，格式标识指定前两个组件使用的格式。

XA START / BEGIN启动交易并定义其全球交易标识符。XA END规定了现行事务的结束。XA PREPARE准备提交事务。XA COMMIT [ONE PHASE]提交并结束一个已经准备好的事务。

如果使用单一阶段”选项，准备和提交将在单个步骤中执行，以结束事务。并终止在XA ROLLBACK 回滚.的业务XA RECOVER显示有关所有PREPARED事务的信息。

让我们看看上面的XA事务的状态之间的转换。

激活XA START交易。一旦活动事务执行了所有语句，就会发出XA_END语句，这将使事务处于空闲状态。对于闲置交易，可以发行XA PREPARE或XA COMMIT ONE PHASE。XA PREMIUM将事务置于PREPARED状态。然而，XA COMMIT ONE PHASE会准备并提交了交易。对于已准备好的XA事务，发出XA COMMIT提交来结束事务。

背景

在5.7.7之前，如果客户端连接终止或服务器正常退出，则回滚PREPARED事务.当客户端被终止时，所有事务都会回滚。因此，即使XA事务处于PREPARED状态，它也不能在XA RECOVER期间恢复事务。理想情况下，在准备事务时，应该可以提交或回滚事务。对于这种情况，我们来看看。

在错误12161中报告。

例子。

一个

2

三

四

五

六

七

八

九

10

/p>

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

mysql> CREATETABLEt1(fld1INT);

QueryOK, 0 rowsaffected (0.01 sec)

mysql> COMMIT;

QueryOK, 0 rowsaffected (0.00 sec)

mysql> XA 'test';

QueryOK, 0 rowsaffected (0.00 sec)

mysql> INSERTINTOt1VALUES (1);

QueryOK, 1 rowaffected (0.00 sec)

mysql> XAEND 'test';

QueryOK, 0 rowsaffected (0.00 sec)

mysql> XA 'test';

QueryOK, 0 rowsaffected (0.00 sec)

mysql> Killed

Nowstartanotherclientsession.

mysql> XA 'test';

 1397 (XAE04): XAER_NOTA: UnknownXID

mysql> XARECOVER;

Emptyset (0.00 sec)

同样在5.7.7之前，如果XA事务处于PREPARED状态且服务器异常退出，则可以在重新启动服务器后恢复该事务-但不会复制该事务。  服务器重新启动后，XA事务仍将以PREPARED状态存在，但其内容无法记录在二进制日志中。因此，二进制日志不同步，导致数据漂移。因此，XA不能安全地用于复制。

overcoming the above mentioned restrictions required changes in the XA transaction recovery mechanism and  binary logging mechanism.  This improvement was made in 5.7.7 through the implementation of work log number 
7193 and 
6860/ 
bug 12161.

• The XA recovery mechansim has been extended such that when a connection is terminated, the PREPARED XA transactions are left in the transaction cache and marked specially in InnoDB. This allows the client to RECOVER the PREPARED XA transactions and then COMMIT/ ROLLBACK.

• The XA transactions are now binlogged in two phases using two different GTIDs which allows the transactions to be interleaved.  During the first phase, when XA PREPARE is issued, the transaction up until that point is logged in the binary log and can be identified by XA_prepare_log_event. During the second phase, when XA COMMIT/ROLLBACK is issued, the second part of the transaction is written into the binary log. Since XA PREPARE is persistent,  the XA transaction is not rolled back and survives  the server restart or client disconnect. The client can perform XA COMMIT/ROLLBACK and the binary log remains up to date. XA transactions also works well when GTID is ON and binary log is turned OFF.

Let us look at the output of the above examples after 5.7.7:

为了克服上述限制，需要对XA事务恢复机制和二进制日志记录机制进行更改。通过执行工作日志编号
7193和
6860 / 
bug 12161在5.7.7中进行了改进。

• XA恢复机制已得到扩展，以便在终止连接时，将PREPARED XA事务保留在事务缓存中，并在InnoDB中进行特殊标记。这允许客户端恢复PREPARED XA事务，然后执行COMMIT / ROLLBACK。

• 现在，使用两个不同的GTID在两个阶段对XA事务进行二进制记录，从而可以使事务交织。在第一阶段中，当发出XA PREPARE时，直到该点的事务都会记录在二进制日志中，并且可以通过以下方式进行标识：XA_prepare_log_event. 在第二阶段中，当发出XA COMMIT / ROLLBACK时，将事务的第二部分写入二进制日志。由于XA PREPARE是持久性的，因此XA事务不会回滚，并且可以在服务器重新启动或客户端断开连接后继续存在。客户端可以执行XA COMMIT / ROLLBACK，并且二进制日志保持最新。当GTID设置为ON并且二进制日志设置为OFF时，XA事务也可以很好地工作。

让我们看看5.7.7之后的上述示例的输出：

客户端断开连接后：

服务器重启后：

以上是“MySQL 5.7中对XA支持的改进有哪些”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注行业资讯频道！