2pc，在第一阶段，tm发送prepare到所有参与分布式事务的rm询问是否可以提交操作，参与分布式事务的所有rm接收到请求，实现自身事务提交前的准备工作并返回结果。第二阶段，根据rm返回的结果，如果涉及分布式事务的所有rm都返回可以提交，则tm给rm发送commit命令，每个rm实现自己的提交，同时释放资源，然后rm反馈提交成功，tm完成整个事务。
请问，
如果tm给rm发送commit命令时，其中一个rm没收到（网络故障等原因），结果会怎么样？
或者，rm反馈提交成功时，其中一个rm没反馈或者反馈失败，然后，事务流程怎么走？
在用分库分表？
如果tm给rm发送commit命令时，其中一个rm没收到（网络故障等原因），结果会怎么样？
rm反馈提交成功时，其中一个rm没反馈或者反馈失败，然后，事务流程怎么走？
roll back
（参考In the second phase, the TM tells the RMs whether to commit or roll back. If all branches indicated when they were prepared that they will be able to commit, all branches are told to commit. If any branch indicated when it was prepared that it will not be able to commit, all branches are told to roll back.）
https://dev.mysql.com/doc/refman/5.7/en/xa.html
https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html
评论
有用 0谢谢wayne，可能没看清我的问题。感谢提供的资料。
XA transactions are not fully resilient to an unexpected halt with respect to the binary log. If there is an unexpected halt while the server is in the middle of executing an XA PREPARE, XA COMMIT, XA ROLLBACK, or XA COMMIT … ONE PHASE statement, the server might not be able to recover to a correct state, leaving the server and the binary log in an inconsistent state. In this situation, the binary log might either contain extra XA transactions that are not applied, or miss XA transactions that are applied. Also, if GTIDs are enabled, after recovery @@GLOBAL.GTID_EXECUTED might not correctly describe the transactions that have been applied. Note that if an unexpected halt occurs before XA PREPARE, between XA PREPARE and XA COMMIT (or XA ROLLBACK), or after XA COMMIT (or XA ROLLBACK), the server and binary log are correctly recovered and taken to a consistent state.
这段可能更能解答。
请问，是不是说xa处理不了第二阶段的异常？
评论 有用 0
