Narayana-XA事务恢复（5）

2023-11-23 05:32
文章标签 恢复 事务 xa narayana

本文主要是介绍Narayana-XA事务恢复（5），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Narayana-XA事务恢复（5）

说事务恢复流程之前，我们来讨论下，会啥会出现事务恢复？XA二阶段提交协议不是强一致性的吗？要解答这个问题，我们就要来看看XA二阶段协议有什么问题？

问题一 ：单点故障

由于协调者的重要性，一旦协调者TM发生故障。参与者RM会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

问题二 ：数据不一致

数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

如何解决？

解决的方案简单，就是我们在事务的操作的每一步，我们都需要对事务状态的日志进行人为的记录，我们可以把日志记录存储在我们想存储的地方，可以是本地存储，也可以中心化的存储。Narayana的开源版本，提供了file，db 2种方式存储，file只能支持单机环境，而db是可以支持集群环境。

Narayana 事务恢复流程。

Narayana使用了单线程轮询RM，执行XA recovery语句，来判断是否有需要恢复的语句。

具体的代码 com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run() 方法。以下是代码：

 public void run (){doInitialWait();boolean finished = false;do{boolean workToDo = false;// ok, get to the point where we are ready to start a scansynchronized(_stateLock) {if (getStatus() == Status.SCANNING) {// need to wait for some other scan to finishif (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("PeriodicRecovery: background thread waiting on other scan");}doScanningWait();// we don't wait around if a worker scan request has just come inif (getMode() == Mode.ENABLED && !_workerScanRequested) {// the last guy just finished scanning so we ought to wait a bit rather than just// pile straight in to do some workif (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("PeriodicRecovery: background thread backing off");}doPeriodicWait();// if we got told to stop then do sofinished = (getMode() == Mode.TERMINATED);}} else {// status == INACTIVE so we can go ahead and scan if scanning is enabledswitch (getMode()) {case ENABLED:// ok grab our chance to be the scanning threadif (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("PeriodicRecovery: background thread Status <== SCANNING");}setStatus(Status.SCANNING);// must kick any other waiting threads_stateLock.notifyAll();workToDo = true;break;case SUSPENDED:// we need to wait while we are suspendedif (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("PeriodicRecovery: background thread wait while SUSPENDED");}doSuspendedWait();// we come out of here with the lock and either ENABLED or TERMINATEDfinished = (getMode() == Mode.TERMINATED);break;case TERMINATED:finished = true;break;}}}// its ok to start work if requested -- we cannot be stopped now by a mode change to SUSPEND// or TERMINATE until we get through phase 1 and maybe phase 2 if we are luckyif (workToDo) {// ok it is now this thread's turn to run a scan. before starting we check if there is a// worker waiting and reset the waiting flag. we will check again after the scan has// completed to see if a worker request has come in after starting this scan.// if so we avoid notifying the worker ensuring a requst is only confirmed when a// full scan has happened afetr the request was madeboolean notifyRequired;synchronized(_stateLock) {notifyRequired = _workerScanRequested;_workerScanRequested = false;}// we are in state SCANNING so actually do the scanif (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("PeriodicRecovery: background thread scanning");}doWorkInternal();// clear the SCANNING state now we have donesynchronized(_stateLock) {if (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("PeriodicRecovery: background thread Status <== INACTIVE");}setStatus(Status.INACTIVE);// must kick any other waiting threads_stateLock.notifyAll();// check if we need to notify a listener worker that we just finished  a scanif (notifyRequired && !_workerScanRequested) {notifyWorker();}if (getMode() == Mode.ENABLED && !_workerScanRequested) {// we managed a full scan and scanning is still enabled// so wait a bit before the next attemptif (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("PeriodicRecovery: background thread backing off");}doPeriodicWait();}finished = (getMode() == Mode.TERMINATED);}}} while (!finished);// make sure the worker thread is not wedged waiting for a scan to completesynchronized(_stateLock) {if (_workerScanRequested) {notifyWorker();}}if (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("PeriodicRecovery: background thread exiting");}}

  • 别被吓到了，我们重点来关注 doWorkInternal(); 我们来看看这个方法。

         //获取所有的RecoveryModule ，然后一个一个执行Vector copyOfModules = getModules();Enumeration modules = copyOfModules.elements();while (modules.hasMoreElements()){RecoveryModule m = (RecoveryModule) modules.nextElement();// we need to ensure we use the class loader context of the recovery module while we are executing// its methodsClassLoader cl = switchClassLoader(m);try {m.periodicWorkFirstPass();} finally {restoreClassLoader(cl);}if (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug(" ");}}// take the lock again so we can do a backoff wait on itsynchronized (_stateLock) {// we have to wait for a bit to avoid catching (too many)// transactions etc. that are really progressing quite happilydoBackoffWait();// we carry on scanning even if scanning is SUSPENDED because the suspending thread// might be waiting on us to complete and we don't want to risk deadlocking it by waiting// here for a resume.// if we have been TERMINATED we bail out now// n.b. if we give up here the caller is responsible for clearing the active scanif (getMode() == Mode.TERMINATED) {if (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("PeriodicRecovery: scan TERMINATED at phase 1");}return;}}// move on to phase 2if (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("Periodic recovery second pass at "+_theTimestamper.format(new Date()));}modules = copyOfModules.elements();while (modules.hasMoreElements()){RecoveryModule m = (RecoveryModule) modules.nextElement();ClassLoader cl = switchClassLoader(m);try {m.periodicWorkSecondPass();} finally {restoreClassLoader(cl);}if (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debugf("PeriodicRecovery: recovery module '%s' second pass processed", m);}}

  • 首先会获取框架所有的RecoveryModule类，然后一个一个执行，我们先来看看这个类：

public interface RecoveryModule
{/*** Called by the RecoveryManager at start up, and then* PERIODIC_RECOVERY_PERIOD seconds after the completion, for all RecoveryModules,* of the second pass*/public void periodicWorkFirstPass ();/*** Called by the RecoveryManager RECOVERY_BACKOFF_PERIOD seconds* after the completion of the first pass*/public void periodicWorkSecondPass ();
}

RecoveryModule的实现类有 XARecoveryModule ，AtomicActionRecoveryModule，SubordinateAtomicActionRecoveryModule,CommitMarkableResourceRecordRecoveryModule。等4个实现类。

恢复执行第一个阶段

  • XARecoveryModule :
    它的作用就是执行XA recovery 命令从RM，获取 Xid数组。然后缓存起来。核心代码为：

//从数据库获取
trans = xares.recover(XAResource.TMSTARTRSCAN);
//缓存刷新refreshXidScansForEquivalentXAResourceImpl(xares, trans);

  • AtomicActionRecoveryModule:
    从事务日志里面获取需要恢复的UID,具体代码为：

  // Transaction typeboolean AtomicActions = false ;// uids per transaction typeInputObjectState aa_uids = new InputObjectState() ;try{if (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("AtomicActionRecoveryModule first pass");}AtomicActions = _recoveryStore.allObjUids( _transactionType, aa_uids );}catch ( ObjectStoreException ex ) {tsLogger.i18NLogger.warn_recovery_AtomicActionRecoveryModule_1(ex);}if ( AtomicActions ){_transactionUidVector = processTransactions( aa_uids ) ;}
恢复执行第二个阶段

首先执行的代码为 ：

 // move on to phase 2if (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debug("Periodic recovery second pass at "+_theTimestamper.format(new Date()));}modules = copyOfModules.elements();while (modules.hasMoreElements()){RecoveryModule m = (RecoveryModule) modules.nextElement();ClassLoader cl = switchClassLoader(m);try {m.periodicWorkSecondPass();} finally {restoreClassLoader(cl);}if (tsLogger.logger.isDebugEnabled()) {tsLogger.logger.debugf("PeriodicRecovery: recovery module '%s' second pass processed", m);}}

  • AtomicActionRecoveryModule: 进入 processTransactionsStatus(),最终会调用到 com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2()。我们来看看这个方法。

//省略无关代码if ( (_theStatus == ActionStatus.PREPARED) ||(_theStatus == ActionStatus.COMMITTING) ||(_theStatus == ActionStatus.COMMITTED) ||(_theStatus == ActionStatus.H_COMMIT) ||(_theStatus == ActionStatus.H_MIXED) ||(_theStatus == ActionStatus.H_HAZARD) ){super.phase2Commit( _reportHeuristics ) ;}else if ( (_theStatus == ActionStatus.ABORTED) ||(_theStatus == ActionStatus.H_ROLLBACK) ||(_theStatus == ActionStatus.ABORTING) ||(_theStatus == ActionStatus.ABORT_ONLY) ){super.phase2Abort( _reportHeuristics ) ;}

  • 判断事务状态，如果是需要commit阶段的状态，进行commit，否则进行rollback

  • XARecoveryModule : 尝试在进行恢复。核心代码为

private void bottomUpRecovery() {for (XAResource xaResource : _resources) {try {xaRecoverySecondPass(xaResource);} catch (Exception ex) {jtaLogger.i18NLogger.warn_recovery_getxaresource(ex);}}// JBTM-895 garbage collection is now done when we return XAResources {@see XARecoveryModule#getNewXAResource(XAResourceRecord)}// JBTM-924 requires this here garbage collection, see JBTM-1155:if (_xidScans != null) {Set<XAResource> keys = new HashSet<XAResource>(_xidScans.keySet());for(XAResource theKey : keys) {RecoveryXids recoveryXids = _xidScans.get(theKey);if(recoveryXids.isStale()) {_xidScans.remove(theKey);}}}}

文章到此，已经写的很长很多了，我们分析了ShardingSphere对于XA方案，提供了一套SPI解决方案，对Atomikos进行了整合，也分析了Atomikos初始化流程，开始事务流程，获取连接流程，提交事务流程，回滚事务流程，事务恢复流程。
希望对大家理解XA的原理有所帮助。

关于我们

 Apache ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（规划中）这3款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务、数据迁移、数据库治理和管控界面功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

Apache ShardingSphere不断践行Apache Way，致力于打造充满活力、规范、互助的社区！开源路上，我们欢迎你的加入。

项目地址：

https://github.com/apache/shardingsphere

更多信息请浏览官网：

https://shardingsphere.apache.org/

作者介绍：肖宇，Apache ShardingSphere Committer，开源hmily分布式事务框架作者，
开源soul网关作者，热爱开源，追求写优雅代码。目前就职于京东数科，参与ShardingSphere的开源建设，以及分布式数据库的研发工作。

扫码关注

ShardingSphere

这篇关于Narayana-XA事务恢复（5）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/415702。

相关文章

SpringKafka消息发布之KafkaTemplate与事务支持功能

SpringKafka消息发布之KafkaTemplate与事务支持功能

《SpringKafka消息发布之KafkaTemplate与事务支持功能》通过本文介绍的基本用法、序列化选项、事务支持、错误处理和性能优化技术,开发者可以构建高效可靠的Kafka消息发布系统,事务支... 目录引言一、KafkaTemplate基础二、消息序列化三、事务支持机制四、错误处理与重试五、性能优
阅读更多...
Spring事务中@Transactional注解不生效的原因分析与解决

Spring事务中@Transactional注解不生效的原因分析与解决

《Spring事务中@Transactional注解不生效的原因分析与解决》在Spring框架中,@Transactional注解是管理数据库事务的核心方式,本文将深入分析事务自调用的底层原理,解释为... 目录1. 引言2. 事务自调用问题重现2.1 示例代码2.2 问题现象3. 为什么事务自调用会失效3
阅读更多...
使用Python实现网络设备配置备份与恢复

使用Python实现网络设备配置备份与恢复

《使用Python实现网络设备配置备份与恢复》网络设备配置备份与恢复在网络安全管理中起着至关重要的作用,本文为大家介绍了如何通过Python实现网络设备配置备份与恢复,需要的可以参考下... 目录一、网络设备配置备份与恢复的概念与重要性二、网络设备配置备份与恢复的分类三、python网络设备配置备份与恢复实
阅读更多...
MySQL使用binlog2sql工具实现在线恢复数据功能

MySQL使用binlog2sql工具实现在线恢复数据功能

《MySQL使用binlog2sql工具实现在线恢复数据功能》binlog2sql是大众点评开源的一款用于解析MySQLbinlog的工具,根据不同选项,可以得到原始SQL、回滚SQL等,下面我们就来... 目录背景目标步骤准备工作恢复数据结果验证结论背景生产数据库执行 SQL 脚本，一般会经过正规的审批
阅读更多...
通过ibd文件恢复MySql数据的操作方法

通过ibd文件恢复MySql数据的操作方法

《通过ibd文件恢复MySql数据的操作方法》文章介绍通过.ibd文件恢复MySQL数据的过程,包括知道表结构和不知道表结构两种情况,对于知道表结构的情况,可以直接将.ibd文件复制到新的数据库目录并... 目录第一种情况：知道表结构第二种情况：不知道表结构总结今天干了一件大事，安装1Panel导致原来服务
阅读更多...
Seata之分布式事务问题及解决方案

Seata之分布式事务问题及解决方案

《Seata之分布式事务问题及解决方案》：本文主要介绍Seata之分布式事务问题及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Seata–分布式事务解决方案简介同类产品对比环境搭建1.微服务2.SQL3.seata-server4.微服务配置事务模式1
阅读更多...
MySQL InnoDB引擎ibdata文件损坏/删除后使用frm和ibd文件恢复数据

MySQL InnoDB引擎ibdata文件损坏/删除后使用frm和ibd文件恢复数据

《MySQLInnoDB引擎ibdata文件损坏/删除后使用frm和ibd文件恢复数据》mysql的ibdata文件被误删、被恶意修改,没有从库和备份数据的情况下的数据恢复,不能保证数据库所有表数据... 参考：mysql Innodb表空间卸载、迁移、装载的使用方法注意！此方法只适用于innodb_fi
阅读更多...
mysql通过frm和ibd文件恢复表_mysql5.7根据.frm和.ibd文件恢复表结构和数据

mysql通过frm和ibd文件恢复表_mysql5.7根据.frm和.ibd文件恢复表结构和数据

《mysql通过frm和ibd文件恢复表_mysql5.7根据.frm和.ibd文件恢复表结构和数据》文章主要介绍了如何从.frm和.ibd文件恢复MySQLInnoDB表结构和数据,需要的朋友可以参... 目录一、恢复表结构二、恢复表数据补充方法一、恢复表结构（从 .frm 文件）方法 1：使用 mysq
阅读更多...
mysql8.0无备份通过idb文件恢复数据的方法、idb文件修复和tablespace id不一致处理

mysql8.0无备份通过idb文件恢复数据的方法、idb文件修复和tablespace id不一致处理

《mysql8.0无备份通过idb文件恢复数据的方法、idb文件修复和tablespaceid不一致处理》文章描述了公司服务器断电后数据库故障的过程,作者通过查看错误日志、重新初始化数据目录、恢复备... 周末突然接到一位一年多没联系的妹妹打来电话，“刘哥，快来救救我”，我脑海瞬间冒出妙瓦底，电信火苲马扁.
阅读更多...
MYSQL事务死锁问题排查及解决方案

MYSQL事务死锁问题排查及解决方案

《MYSQL事务死锁问题排查及解决方案》：本文主要介绍Java服务报错日志的情况,并通过一系列排查和优化措施,最终发现并解决了服务假死的问题,文中通过代码介绍的非常详细,需要的朋友可以参考下... 目录问题现象推测 1 - 客户端无错误重试配置推测 2 - 客户端超时时间过短推测 3 - mysql 版本问
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2