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

这篇文章主要为大家展示了“MySQL 5.7中对XA支持的改进有哪些”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“MySQL 5.7中对XA支持的改进有哪些”这篇文章吧。 XA解决了当跨分布式资源情况下能在单个事务中保留ACID属性的问题。资源本身可以是其他MySQL服务器，甚至可以其他是不同的数据库技术。XA标准描述了全局事务管理器和本地资源管理器之间的交互。 如引言中所述，MySQL 5.0引入了XA支持，从而增加了参与全局事务的能力。XA支持可以提供可访问事务资源的资源管理器和能够在全局事务中协调事务的事务管理器。MySQL的XA实现了让MySQL服务器来充当资源管理器，而连接到MySQL服务器的客户端执行事务管理器的任务。 XA使用两阶段提交协议，其中第一阶段是发出commit请求，然后再进行实际的commit。全局事务的各个分支完成执行后，将启动两阶段提交协议：在第一阶段，事务管理器向全局事务中涉及的所有分支发出准备commit的消息。在资源管理器确认已准备好提交之前，它会将操作的记录结果记录并保存，为第二阶段执行实际的提交做准备。在第二阶段，事务管理器如果从所有涉及的分支接收到确定的响应，则通知它们提交。但是，如果任何一个分支的答复为否，则会通知所有分支执行回滚。 一个事务管理器与多个资源管理器进行交互，以处理全局事务中的单个事务/分支。以下图描述了涉及一个资源管理器中的XA事务。XA事务的语句以XA关键字，要执行的操作和唯一标识符开头。在下面的示例中，字符串“ xatest”表示全局事务标识符。除了全局事务标识符之外，还可以为XA事务指定分支标识符和格式ID。分支标识符用于标识本地事务，格式ID指定前两个组件使用的格式。XA START / BEGIN启动事务并定义其全局事务标识符。
XA END指定活动事务的结束。
XA PREPARE为事务的COMMIT做准备。
XA COMMIT [ONE PHASE]COMMIT并结束一个已PREPARE的事务。
如果使用“单阶段”选项，则准备和提交将在结束事务的单个步骤中执行。
XA ROLLBACK 回滚并终止事务。
XA RECOVER显示有关所有PREPARED事务的信息。让我们看一下上述XA事务的状态之间转换。
XA START将事务置于活动状态。一旦所有语句由活动事务执行后，就会发出XA_END语句，使该事务处于IDLE状态。对于空闲事务，可以发出XA PREPARE或XA COMMIT ONE PHASE。XA PREPARE将事务置于PREPARED状态。但是，XA COMMIT ONE PHASE会准备并提交事务。对于PREPARED XA事务，将发出XA COMMIT提交以结束事务。在5.7.7之前，如果客户端连接终止或服务器正常退出，则回滚PREPARED事务。当客户端被杀死时，所有交易都会回滚。因此，即使XA事务处于PREPARED状态，它也无法在XA RECOVER期间恢复该事务。理想情况下，在准备事务时，应该可以提交或回滚该事务。对于这种情况，让我们看一下
错误12161中报告的
示例。123456789101112131415161718192021222324252627mysql>CREATETABLEt1(fld1INT);QueryOK,0rowsaffected(0.01sec)mysql>COMMIT;QueryOK,0rowsaffected(0.00sec)mysql>XA’test’;QueryOK,0rowsaffected(0.00sec)mysql>INSERTINTOt1VALUES(1);QueryOK,1rowaffected(0.00sec)mysql>XAEND’test’;QueryOK,0rowsaffected(0.00sec)mysql>XA’test’;QueryOK,0rowsaffected(0.00sec)mysql>KilledNowstartanotherclientsession.mysql>XA’test’;1397(XAE04):XAER_NOTA:UnknownXIDmysql>XARECOVER;Emptyset(0.00sec)同样在5.7.7之前，如果XA事务处于PREPARED状态且服务器异常退出，则可以在重新启动服务器后恢复该事务-但不会复制该事务。 服务器重新启动后，XA事务仍将以PREPARED状态存在，但其内容无法记录在二进制日志中。因此，二进制日志不同步，导致数据漂移。因此，XA不能安全地用于复制。123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354mysql>CREATETABLEt1(fld1INT);QueryOK,0rowsaffected(0.01sec)mysql>COMMIT;QueryOK,0rowsaffected(0.00sec)mysql>XA’test’;QueryOK,0rowsaffected(0.00sec)mysql>INSERTINTOt1VALUES(1);QueryOK,1rowaffected(0.00sec)mysql>XAEND’test’;QueryOK,0rowsaffected(0.00sec)mysql>XA’test’;QueryOK,0rowsaffected(0.00sec)Nowkilltheserver.mysql>XARECOVER;2006(HY000):MySQLserverhasgoneawayNoconnection.Tryingtoreconnect…Connectionid:1Currentdatabase:test+———-+————–+————–+—-免费主机域名–+|formatID|gtrid_length|bqual_length|data|+———-+————–+————–+——+|1|4|0|test|+———-+————–+————–+——+1rowinset(0.02sec)mysql>XA’test’;QueryOK,0rowsaffected(0.02sec)mysql>SHOWBINLOGEVENSG;***************************1.row ***************************Log_name:nisha-PORTEGE-Z30-A-bin.000001Pos:4Event_type:Format_descServer_id:1End_log_pos:120Info:Serverver:5.6.29-debug-log,Binlogver:41rowinset(0.00sec)mysql>SELECT *FROMt1;+——+|fld1|+——+|1|+——+1rowinset(0.00sec)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
7193and
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 thefirst phase, when XA PREPARE is issued, the transaction up until that point is logged in the binary log and can be identified byXA_prepare_log_event.During thesecond 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之后的上述示例的输出：客户端断开连接后：1234567891011121314151617181920212223242526272829303132mysql>CREATETABLEt1(fld1INT);QueryOK,0rowsaffected(0.01sec)mysql>COMMIT;QueryOK,0rowsaffected(0.00sec)mysql>XA’test’;QueryOK,0rowsaffected(0.00sec)mysql>INSERTINTOt1VALUES(1);QueryOK,1rowaffected(0.00sec)mysql>XAEND’test’;QueryOK,0rowsaffected(0.00sec)mysql>XA’test’;QueryOK,0rowsaffected(0.00sec)mysql>KilledNowstartanotherclientsession.mysql>XARECOVER;+———-+————–+————–+——+|formatID|gtrid_length|bqual_length|data|+———-+————–+————–+——+|1|4|0|test|+———-+————–+————–+——+1rowinset(0.00sec)mysql>XA’test’;QueryOK,0rowsaffected(0.02sec)服务器重启后：123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081mysql>CREATETABLEt1(fld1INT);QueryOK,0rowsaffected(0.01sec)mysql>COMMIT;QueryOK,0rowsaffected(0.00sec)mysql>XA’test’;QueryOK,0rowsaffected(0.00sec)mysql>INSERTINTOt1VALUES(1);QueryOK,1rowaffected(0.00sec)mysql>XAEND’test’;QueryOK,0rowsaffected(0.00sec)mysql>XA’test’;QueryOK,0rowsaffected(0.00sec)Nowkilltheserver.mysql>XARECOVER;2006(HY000):MySQLserverhasgoneawayNoconnection.Tryingtoreconnect…Connectionid:1Currentdatabase:test+———-+————–+————–+——+|formatID|gtrid_length|bqual_length|data|+———-+————–+————–+——+|1|4|0|test|+———-+————–+————–+——+1rowinset(0.02sec)mysql>XA’test’;QueryOK,0rowsaffected(0.02sec)mysql>SHOWBINLOGeventsG;***************************3.row ***************************Log_name:nisha-PORTEGE-Z30-A-bin.000001Pos:154Event_type:Anonymous_GtidServer_id:0End_log_pos:219Info:@@SESSION.GTID_NEXT=’ANONYMOUS’***************************4.row ***************************Log_name:nisha-PORTEGE-Z30-A-bin.000001Pos:219Event_type:QueryServer_id:0End_log_pos:319Info:XA’7465免费主机域名7374′,”,1***************************5.row ***************************Log_name:nisha-PORTEGE-Z30-A-bin.000001Pos:319Event_type:QueryServer_id:0End_log_pos:418Info:use`test`;INSERTINTOt1VALUES(1)***************************6.row ***************************Log_name:nisha-PORTEGE-Z30-A-bin.000001Pos:418Event_type:QueryServer_id:0End_log_pos:509Info:XAEND’74657374′,”,1***************************7.row ***************************Log_name:nisha-PORTEGE-Z30-A-bin.000001Pos:509Event_type:XA_prepareServer_id:0End_log_pos:549Info:XA’74657374′,”,1***************************8.row ***************************Log_name:nisha-PORTEGE-Z30-A-bin.000002Pos:219Event_type:Server_id:0End_log_pos:313Info:XA’74657374′,”,18rowsinset(0.00sec)以上是“MySQL 5.7中对XA支持的改进有哪些”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注云技术行业资讯频道！

相关推荐: 什么是dsjob命令

这篇文章主要讲解了“什么是dsjob命令”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“什么是dsjob命令”吧！ Datastage 的job可以通过dsjob命令来调用job或者获得job的信息，以及运行的报…