CN107038192A - 数据库容灾方法和装置 - Google Patents

Abstract

本申请提供一种数据库容灾方法和装置。所述方法应用在容灾组网中的数据库实例上，所述容灾组网中的数据库实例之间基于分布式选举协议进行数据同步，所述方法包括有：接收到来自客户端的数据库事务；对所述数据库事务进行处理，并根据数据库实例列表通知容灾组网中正常运转的其他数据库实例对所述数据库事务进行处理；当确定容灾组网中半数或半数以上正常运转的数据库实例完成对所述数据库事务的处理时，向所述客户端返回处理完毕的消息。基于本申请的实现方案，可以确保数据库实例之间数据一致，实现数据中心级别的无损容灾，避免跨城市的异地同步时延，提高响应速率。

Description

数据库容灾方法和装置

技术领域

本申请涉及通信技术领域，尤其涉及一种数据库容灾方法和装置。

背景技术

随着互联网技术的快速发展，越来越多的数据存储在数据库中。为确保数据不丢失，数据拥有方通常会部署多个数据中心，以实现数据的备灾。“两地三中心”是目前较为典型的容灾组网架构，可在主城市部署两个数据中心，在备灾城市部署一个数据中心。其中，主城市的两个数据中心中有一个数据中心可作为“主库”运转，另一个数据中心作为“同城备灾库”，而备灾城市的数据中心为“异地备灾库”。然而，当“主库”故障时，无论是“同城备灾库”还是“异地备灾库”，均和“主库”之间有一定的数据延迟，进而导致数据丢失。

发明内容

有鉴于此，本申请提供一种数据库容灾方法和装置。

具体地，本申请是通过如下技术方案实现的：

一种数据库容灾方法，所述方法应用在容灾组网中的数据库实例上，所述容灾组网中的数据库实例之间基于分布式选举协议进行数据同步，所述方法包括有：

接收到来自客户端的数据库事务；

对所述数据库事务进行处理，并根据数据库实例列表通知容灾组网中正常运转的其他数据库实例对所述数据库事务进行处理；

当确定容灾组网中半数或半数以上正常运转的数据库实例完成对所述数据库事务的处理时，向所述客户端返回处理完毕的消息。

一种数据库容灾装置，所述装置应用在容灾组网中运行数据库实例逻辑的服务器上，所述容灾组网中的数据库实例之间基于分布式选举协议进行数据同步，所述装置包括有：

接收单元，接收到来自客户端的数据库事务；

处理单元，对所述数据库事务进行处理，并根据数据库实例列表通知容灾组网中正常运转的其他数据库实例对所述数据库事务进行处理；

返回单元，当确定容灾组网中半数或半数以上正常运转的数据库实例完成对所述数据库事务的处理时，向所述客户端返回处理完毕的消息。

由以上描述可以看出，本申请容灾组网中的数据库实例之间可基于分布式选举协议进行数据同步，任一数据库实例在接收到来自客户端的数据库事务后，如果确定容灾组网中半数或半数以上正常运转的数据库实例完成对所述数据库事务的处理时，就可向客户端返回处理完毕的消息，无需等待全部数据库实例均执行完毕，响应速率快，同时，基于分布式选举协议可以确保各个数据库实例之间的数据一致，不丢失。

附图说明

图1是本申请一示例性实施例示出的一种数据库容灾方法的流程示意图。

图2是本申请一示例性实施例示出的一种容灾组网架构图。

图3是本申请一示例性实施例示出的另一种数据库容灾方法的流程示意图。

图4是本申请一示例性实施例示出的一种用于数据库容灾装置的一结构示意图。

图5是本申请一示例性实施例示出的一种数据库容灾装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

相关技术中，可以采用以下几种模式进行主备数据库之间的数据同步。

一、最大保护模式(Maximum Protection)。数据库事务一定在强同步至所有备库时，才会向客户端返回应答消息。然而，采用这样的模式，响应速率低下，用户体验较差。同时，当任一数据库故障时，均会对服务造成影响，无法保证高可用性。

二、最大性能模式(Maximum Performance)。主库处理完毕数据库事务后即可向客户端返回应答消息，后续可异步将数据库事务复制到备库中。然而，采用这样的模式，无法确保不丢失数据，比如：主库故障时，可能存在未复制到备库中的数据库事务。

三、最大可用模式(Maximum Availability)。将数据库事务尽量同步到备库中。当主备数据库均正常运转时，可采用最大保护模式，否则切换为最大性能模式。然而，采用这样的模式，也无法确保不丢失数据。

针对上述问题，本申请提供一种数据库容灾方案，可基于分布式选举协议(Paxos协议)进行数据同步，确保数据的一致性，并可提高响应速率。

图1是本申请一示例性实施例示出的一种数据库容灾方法的流程示意图。

在本实施例中，所述数据库容灾方法可以应用在容灾组网中的数据库实例上。其中，所述容灾组网中通常部署有多个数据中心，每个数据中心部署有一个或多个数据库实例，以实现数据灾备。其中，所述数据库实例是一个逻辑意义上的概念，可用于存储数据、提供数据库事务服务等，硬件架构上通常包括有用于存储数据的物理介质、用于执行数据库事务服务逻辑的处理器等。请参考图1，所述数据库容灾方法可以包括以下步骤：

步骤101，接收到来自客户端的数据库事务。

在本实施例中，容灾组网中的各个数据库实例均可为客户端提供数据库事务服务，各数据库实例之间不存在主备的概念。在一个例子中，来自客户端的数据库事务可以基于负载均衡策略被分配至各个数据库实例中。在另一个例子中，来自客户端的数据库事务也可以被分配至距离其较近的数据库实例中，本申请对此不作特殊限制。

步骤102，对所述数据库事务进行处理，并根据数据库实例列表通知容灾组网中正常运转的其他数据库实例对所述数据库事务进行处理。

在本实施例中，每个数据库实例中均可以维护一个数据库实例列表，该数据库实例列表包括容灾组网中各个数据库实例的信息，比如：数据库实例的通信地址、数据库实例ID等。

基于前述步骤101，数据库实例在接收到来自客户端的数据库事务后，可以对所述数据库事务进行处理，比如：可以采用分布式的方式实现对所述数据库事务的处理。另一方面，数据库实例还可以根据所述数据库实例列表通知容灾组网中正常运转的其他数据库实例对所述数据库事务进行处理，并可以在处理完毕后返回处理完毕的消息。比如：可以将所述数据库事务以SQL语句的形式发送给容灾组网中的其他数据库实例，其他数据库在接收到所述数据库事务后，可以对所述数据库事务进行处理。又比如：还可以在完成对所述数据库事务的处理后，将本次处理的相关数据以数据库重做日志(redo log)的形式发送给容灾组网中正常运转的其他数据库实例，其他数据库实例在接收到该重做日志后，可以根据所述重做日志同步本次数据库事务处理涉及到的相关数据，以实现对所述数据库事务的处理。

在一个例子中，所述数据库实例列表中包括有容灾组网中所有的数据库实例，以及各数据库实例当前的状态，比如：正常状态或者故障状态。在这种情况下，可以将接收到的来自客户端的数据库事务发送给数据库实例列表中状态为正常的数据库实例。

在另一个例子中，所述数据库实例列表中也可以仅存储有容灾组网中正常状态的数据库实例。在这种情况下，可以将接收到的来自客户端的数据库事务发送给数据库实例列表中所有的数据库实例。

步骤103，当确定容灾组网中半数或半数以上正常运转的数据库实例完成对所述数据库事务的处理时，向所述客户端返回处理完毕的消息。

在本实施例中，容灾组网中的数据库实例之间可基于分布式选举协议实现数据同步。基于分布式选举协议，容灾组网中的数据库实例可分为三种角色，分别为：Acceptor、Proposer以及Learner。分布式选举协议主要分为两个阶段，第一个阶段是Prepare阶段，第二个阶段是Accept阶段。

具体地，在Prepare阶段，Proposer角色的数据库实例(后续简称为Proposer)可向所有Acceptor角色的数据库实例(后续简称为Acceptor)发送Prepare申请访问权，并携带一个提案号(epoch)，Acceptor赋予访问权或拒绝，并且返回该Acceptor已经接受的值和对应的提案号。如果Proposer获得超过半数Acceptor的访问权，那么会进入Accept阶段。在Accept阶段，如果所有的Acceptor返回值都为空，Proposer可向获取到访问权的Acceptor发送携带自己数据和自己epoch号的请求。如果Proposer在第一阶段获得某些Acceptor的返回值不为空，则可将epoch号最大的提案号对应的数据作为自己的预设数据，并连同自己的提案号一起携带在请求中发送给Acceptor。对于Acceptor而言，当它接收到Proposer的请求时，可通过一系列规则来决定是否接受Proposer的数据。在分布式选举协议中，Learner角色的数据库实例可学习已学习过的数据和epoch号。

在本实施例中，当容灾组网中半数或半数以上正常运转的数据库实例已完成对所述数据库事务的处理时，基于所述分布式选举协议，可以确保容灾组网中各数据库实例的数据一致性，因此，接收到客户端数据库事务的数据库实例可以在容灾组网中半数或半数以上正常运转的数据库实例已完成对所述数据库事务的处理时，向所述客户端返回处理完毕的消息。

由以上描述可以看出，本申请容灾组网中的数据库实例之间可基于分布式选举协议进行数据同步，任一数据库实例在接收到来自客户端的数据库事务后，如果确定容灾组网中半数或半数以上正常运转的数据库实例完成对所述数据库事务的处理，就可向客户端返回处理完毕的消息，无需等待全部数据库实例均执行完毕，响应速率快，同时，基于分布式选举协议可以确保各个数据库实例之间的数据一致，不丢失。

下面结合具体的应用场景来描述本申请的实现过程。

图2是本申请一示例性实施例示出的一种容灾组网架构图。

请参考图2，示出了一种“两地三中心”的容灾组网架构。在该架构中，上海为主城市，部署有数据中心1和数据中心2，数据中心1和数据中心2中均部署有两个数据库实例。深圳是备灾城市，部署有数据中心3，数据中心3中部署有数据库实例5。在该架构中，一共部署有5个数据库实例，这5个数据库实例之间基于分布式选举协议进行数据同步。

数据库实例ID	数据库实例IP地址	数据库实例状态
			1	IP1	正常
2	IP2	正常
			3	IP3	正常
4	IP4	正常
			5	IP5	正常

表1

在本实施例中，每个数据库实例中均维护有一张该容灾组网的数据库实例列表，请参考图1的实例，所述数据库实例列表中通常包括有数据库实例ID、数据库实例地址、数据库实例状态等信息。值得注意的是，表1仅为示例性的数据库实例列表，在实际实现中，也可以不组织这样的表格，本申请对此不作特殊限制。

请参考图3，以数据库实例1为例，数据库实例1实现数据库容灾方法可以包括以下步骤：

步骤301，数据库实例1接收到来自客户端的数据库事务。

步骤302，数据库实例1对所述数据库事务进行处理，并通知容灾组网中的数据库实例2至数据库实例5对所述数据库事务进行处理。

在本实施例中，基于表1所示的数据库实例列表，当前容灾组网中所有的数据库实例均正常运转，数据库实例1可以将所述数据库事务发送给数据库实例2至数据库实例5。

步骤303，数据库实例1在接收到任一数据库实例返回的数据库事务处理完毕的消息时，确定该数据库实例已完成对所述数据库事务的处理。

步骤304，数据库实例1在确定容灾组网中3个数据库实例完成对所述数据库事务的处理时，向所述客户端返回处理完毕的消息。

在本实施例中，请继续参考图2，由于数据库实例2与数据库实例1同属于数据中心1，一般而言，数据库实例2的响应速度最快。数据库实例3和数据库实例4所属的数据中心2与数据中心1是同城数据中心，响应时间通常在1到2毫秒，响应速度次快。而数据库实例5位于深圳，由于距离上海较远，响应时间通常在40至60毫秒，响应速度最慢。

在本实施例中，假设，数据库实例1最先接收到数据库实例2的处理完毕消息，然后接收到数据库实例3的处理完毕消息，如果数据库实例1也已处理完毕所述数据库事务，数据库实例1就可以向客户端返回处理完毕的消息，无需等待数据库实例4和数据库实例5的响应，大大提高的响应速率，同时又可确保数据一致性。

可选的，在另一个例子中，当容灾组网中任一数据库实例故障时，其他数据库实例在经多数派投票同意后，可以将数据库实例列表中故障数据库实例的状态更新为故障。假设，数据中心2发生火灾，导致数据库实例3和数据库实例4故障，该容灾组网中的其他数据库实例可以通过数据库实例之间的保活报文确定得知故障，在得知该故障事件后，可以基于分布式选举协议对所述故障事件进行投票，投票结果包括：同意或不同意。依据当前的数据库实例列表，容灾组网中5个数据库实例均为正常状态，则在容灾组网中的5个数据库实例中，如果3个数据库实例同意所述故障事件，比如：数据库实例1、数据库实例2以及数据库实例5均同意所述故障事件，则可以将数据库实例列表中数据库实例3和数据库实例4的状态由正常更新为故障，形成表2所示的数据库实例列表。值得注意的是，如果容灾组网中只有两个数据库实例同意所述故障事件，则不能对所述数据库实例列表进行更新。

数据库实例ID	数据库实例IP地址	数据库实例状态
			1	IP1	正常
2	IP2	正常
			3	IP3	故障
4	IP4	故障
			5	IP5	正常

表2

基于图2所示的数据库实例列表，当数据库实例1接收到客户端的数据库事务时，可以将该数据库事务发送给数据库实例2以及数据库实例5。当前容灾组网中正常运转的数据库实例一共有3个，当数据库实例1执行完毕所述数据库事务并确定数据库实例2也执行完毕所述数据库事务时，即3个数据库实例中2个数据库实例已执行完毕所述数据库事务，数据库实例1就可以向客户端返回执行完毕的消息，以实现数据中心级(机房级)的无损容灾能力。而在相关技术中，要想实现数据中心级的无损容灾，通常需要在主城市部署三个或三个以上数据中心或者忍受跨城市同步的时延，采用本申请的上述方案，在主城市的数据中心部署两个数据中心即可，大大降低了数据中心的建设成本。此外，采用本申请的上述方案，整个响应过程无需等待位于深圳的数据库实例5完成对所述数据库事务的处理，避免了跨城市同步的时延，提高了数据库实例故障时的响应速率。另一方面，基于分布式选举协议，可以确保数据库实例1、数据库实例2以及数据库实例5之间的数据一致性。

需要说明的是，在另一个例子中，数据库实例维护的数据库实例列表中可以仅存储正常状态的数据库实例，在这样的情况下，当确定任一数据库实例故障时，经多数派投票同意后也可将该故障数据库实例从数据库实例列表中删除。当确定故障数据库实例恢复正常时，同样也需要经多数派投票同意后，才可在数据库实例列表中添加恢复正常的故障数据库实例。

可选的，在另一个例子中，请继续参考图2，为避免跨地域的网络时延，上海的每个数据中心都部署有两个数据库实例，而这两个数据库实例中有一个数据库实例的作用就是数据灾备。为降低成本，针对主城市的数据中心，可以配置一个数据库实例用于提供数据库事务服务，另一个数据库实例用于存储数据库日志，基于数据库日志，可以恢复出数据库数据。比如：可将数据库实例2和数据库实例4设置为用于存储数据库日志的数据库实例。由于数据库日志文件可以循环存储，不占用额外的存储空间，通过合理的部署无需增加额外的服务器，可以节省部署成本。当然，在实际应用中，也可以在主城市的数据中心部署三个或三个以上的数据库实例，在这样的情况下，仍可以配置一个数据库实例用于提供数据库事务服务，其他数据库实例用于存储数据库日志。

与前述数据库容灾方法的实施例相对应，本申请还提供了数据库容灾装置的实施例。

本申请数据库容灾装置的实施例可以应用在容灾组网中运行数据库实例逻辑的服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务器的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请数据库容灾装置所在服务器的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的服务器通常根据该服务器的实际功能，还可以包括其他硬件，对此不再赘述。

图5是本申请一示例性实施例示出的一种数据库容灾装置的框图。

请参考图5，该容灾组网中的数据库实例之间基于分布式选举协议进行数据同步，所述数据库容灾装置400可以应用在图4所示的服务器中，包括有：接收单元401、处理单元402、返回单元403以及维护单元404。

其中，接收单元401，接收到来自客户端的数据库事务；

处理单元402，对所述数据库事务进行处理，并根据数据库实例列表通知容灾组网中正常运转的其他数据库实例对所述数据库事务进行处理；

返回单元403，当确定容灾组网中半数或半数以上正常运转的数据库实例完成对所述数据库事务的处理时，向所述客户端返回处理完毕的消息。

维护单元404，当确定容灾组网中任一数据库实例故障时，基于所述分布式选举协议对故障事件进行投票，当容灾组网中半数或半数以上正常运转的数据库实例同意所述故障事件时，将所述数据库实例列表中故障数据库实例的状态由正常更新为故障，或在所述数据库实例列表中删除故障数据库实例；当确定容灾组网中所述故障数据库实例恢复正常时，基于所述分布式选举协议对恢复事件进行投票，当容灾组网中半数或半数以上正常运转的数据库实例同意所述恢复事件时，将所述数据库实例列表中所述故障数据库实例的状态由故障更新为正常，或在所述数据库实例列表中添加已恢复正常的所述故障数据库实例。

可选的，所述返回单元403，当接收到任一数据库实例返回的数据库事务处理完毕的消息时，确定该数据库实例已完成对所述数据库事务的处理。

可选的，所述处理单元402，具体根据数据库实例列表将所述数据库事务发送给容灾组网中正常运转的其他数据库实例；或者

在完成对所述数据库事务的处理后，根据数据库实例列表将本次处理的相关数据以数据库重做日志的形式发送给容灾组网中正常运转的其他数据库实例。

可选的，所述容灾组网中的数据库实例位于主城市以及备灾城市；

其中，所述主城市包括多个数据中心，所述主城市的每个数据中心均包括多个数据库实例，所述备灾城市包括一个数据中心，所述备灾城市的数据中心包括有一个或多个数据库实例。

可选的，在所述主城市的每个数据中心的多个数据库实例中，均包括一个用于提供数据库事务服务的数据库实例以及一个或多个用于存储数据库日志的数据库实例。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (12)

1.一种数据库容灾方法，其特征在于，所述方法应用在容灾组网中的数据库实例上，所述容灾组网中的数据库实例之间基于分布式选举协议进行数据同步，所述方法包括有：

接收到来自客户端的数据库事务；

对所述数据库事务进行处理，并根据数据库实例列表通知容灾组网中正常运转的其他数据库实例对所述数据库事务进行处理；

当确定容灾组网中半数或半数以上正常运转的数据库实例完成对所述数据库事务的处理时，向所述客户端返回处理完毕的消息。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当确定容灾组网中任一数据库实例故障时，基于所述分布式选举协议对故障事件进行投票，当容灾组网中半数或半数以上正常运转的数据库实例同意所述故障事件时，将所述数据库实例列表中故障数据库实例的状态由正常更新为故障，或在所述数据库实例列表中删除故障数据库实例；

当确定容灾组网中所述故障数据库实例恢复正常时，基于所述分布式选举协议对恢复事件进行投票，当容灾组网中半数或半数以上正常运转的数据库实例同意所述恢复事件时，将所述数据库实例列表中所述故障数据库实例的状态由故障更新为正常，或在所述数据库实例列表中添加已恢复正常的所述故障数据库实例。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当接收到任一数据库实例返回的数据库事务处理完毕的消息时，确定该数据库实例已完成对所述数据库事务的处理。

4.根据权利要求1所述的方法，其特征在于，所述根据数据库实例列表通知容灾组网中正常运转的其他数据库实例对所述数据库事务进行处理，包括：

根据数据库实例列表将所述数据库事务发送给容灾组网中正常运转的其他数据库实例；或者

在完成对所述数据库事务的处理后，根据数据库实例列表将本次处理的相关数据以数据库重做日志的形式发送给容灾组网中正常运转的其他数据库实例。

5.根据权利要求1所述的方法，其特征在于，

所述容灾组网中的数据库实例位于主城市以及备灾城市；

其中，所述主城市包括多个数据中心，所述主城市的每个数据中心均包括多个数据库实例，所述备灾城市包括一个数据中心，所述备灾城市的数据中心包括有一个或多个数据库实例。

6.根据权利要求5所述的方法，其特征在于，

在所述主城市的每个数据中心的多个数据库实例中，均包括一个用于提供数据库事务服务的数据库实例以及一个或多个用于存储数据库日志的数据库实例。

7.一种数据库容灾装置，其特征在于，所述装置应用在容灾组网中运行数据库实例逻辑的服务器上，所述容灾组网中的数据库实例之间基于分布式选举协议进行数据同步，所述装置包括有：

接收单元，接收到来自客户端的数据库事务；

处理单元，对所述数据库事务进行处理，并根据数据库实例列表通知容灾组网中正常运转的其他数据库实例对所述数据库事务进行处理；

返回单元，当确定容灾组网中半数或半数以上正常运转的数据库实例完成对所述数据库事务的处理时，向所述客户端返回处理完毕的消息。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

维护单元，当确定容灾组网中任一数据库实例故障时，基于所述分布式选举协议对故障事件进行投票，当容灾组网中半数或半数以上正常运转的数据库实例同意所述故障事件时，将所述数据库实例列表中故障数据库实例的状态由正常更新为故障，或在所述数据库实例列表中删除故障数据库实例；

当确定容灾组网中所述故障数据库实例恢复正常时，基于所述分布式选举协议对恢复事件进行投票，当容灾组网中半数或半数以上正常运转的数据库实例同意所述恢复事件时，将所述数据库实例列表中所述故障数据库实例的状态由故障更新为正常，或在所述数据库实例列表中添加已恢复正常的所述故障数据库实例。

9.根据权利要求7所述的装置，其特征在于，

所述返回单元，当接收到任一数据库实例返回的数据库事务处理完毕的消息时，确定该数据库实例已完成对所述数据库事务的处理。

10.根据权利要求7所述的装置，其特征在于，

所述处理单元，具体根据数据库实例列表将所述数据库事务发送给容灾组网中正常运转的其他数据库实例；或者

在完成对所述数据库事务的处理后，根据数据库实例列表将本次处理的相关数据以数据库重做日志的形式发送给容灾组网中正常运转的其他数据库实例。

11.根据权利要求7所述的装置，其特征在于，

所述容灾组网中的数据库实例位于主城市以及备灾城市；

其中，所述主城市包括多个数据中心，所述主城市的每个数据中心均包括多个数据库实例，所述备灾城市包括一个数据中心，所述备灾城市的数据中心包括有一个或多个数据库实例。

12.根据权利要求11所述的装置，其特征在于，

在所述主城市的每个数据中心的多个数据库实例中，均包括一个用于提供数据库事务服务的数据库实例以及一个或多个用于存储数据库日志的数据库实例。