CN114490188A - 同步主备数据库的方法及装置 - Google Patents

Abstract

本公开提供了一种同步主备数据库的方法及装置。所述方法可以应用于主数据库，所述方法包括：接收第一事务请求，第一事务请求用于请求对主数据库中的数据进行修改；响应于第一事务请求，对主数据库中的数据执行修改操作；根据修改操作，与第一备数据库进行数据同步；如果数据同步失败，向仲裁方发送通知消息，通知消息用于通知仲裁方将第一备数据库从第一数据库集合中删除，第一数据库集合中的数据库均为与主数据库数据同步的备数据库；向第一事务的发起方发送针对第一事务请求的应答。

Description

同步主备数据库的方法及装置

技术领域

本公开涉及数据库技术领域，尤其涉及一种同步主备数据库的方法及装置。

背景技术

灾害可能导致数据库不可用，从而无法继续提供服务。相关技术可以基于主备同步机制实现容灾。例如，在主数据库受灾不可用的情况下，可以进行主备切换，使用备数据库继续提供服务。但是，主备同步容灾机制存在诸多问题。例如，在备数据库不可用时，主数据库无法继续服务。或者，在进行主备切换时，可能存在数据丢失的情况。

发明内容

灾害可能导致数据库不可用，从而无法继续提供服务。相关技术可以基于主备同步机制实现容灾。例如，在主数据库受灾不可用的情况下，可以进行主备切换，使用备数据库继续提供服务。但是，主备同步容灾机制存在诸多问题。例如，在备数据库不可用时，主数据库无法继续服务。或者，在进行主备切换时，可能存在数据丢失的情况。

附图说明

图1为本公开实施例提供的一同步主备数据库的方法的示意性流程图。

图2为本公开实施例提供的另一同步主备数据库的方法的示意性流程图。

图3为本公开实施例提供的又一同步主备数据库的方法的示意性流程图。

图4为本公开实施例提供的一同步主备数据库的装置的结构示意图。

图5为本公开实施例提供的另一同步主备数据库的装置的结构示意图。

图6为本公开实施例提供的又一同步主备数据库的装置的结构示意图。

具体实施方式

下面将结合本公开实施例的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本公开一部分实施例，而不是全部的实施例。

数据库（database，DB）

数据库可以用于按照数据结构来组织、存储和管理数据。数据库可以根据修改事务请求对数据库中的数据进行新增、删除、修改或查找等操作。常见的数据库有Oracle、MySQL、DB2、MongoDB以及Redias等。数据库是一个系统（例如生产系统）的重要组成部分。

数据库难免遭遇灾害，从而出现故障。灾害可以包括：不可抗力（例如自然灾害等）、数据负载过重（例如高并发数据或海量数据等）或者网络故障等。相关技术提出了针对数据库的容灾机制，以实现数据库在遭遇灾害后可以继续服务或恢复服务，从而提高数据库的可用性和稳定性。

作为一种容灾机制，系统（例如生产系统）可以包括多个数据库。系统中的每个数据库可以同步相同的副本，即存储相同的数据。多个数据库可以设置在不同的位置（例如不同的机器、机房或城市）。当某一数据库遭遇灾害时，其他数据库可以继续服务。

主备同步容灾机制

在主备同步容灾机制下，系统可以包括主数据库（primarydatabase）以及一个或多个备数据库（standbydatabase）。主数据库可以实现数据的读写，备数据库可以用于备份主数据库中的数据。主数据库也可以称为主库或生产数据库，备数据库也可以称为备库或从库。

灾害可能导致主数据库和/或备数据库不可用。主数据库不可用的情况可以包括主数据库故障。备数据库不可用的情况可以包括备数据库故障或主备数据库之间的网络故障。

当主数据库受灾不可用时，系统可以切换到备数据库继续服务，以避免灾害的影响。每次对主数据库进行操作时，均需要将该操作同步至备数据库，以实现主数据库和备数据库中数据的一致性，从而在切换时可以保证切换为主数据库的备数据库与原主数据库中的数据是相同的。主备同步方案可以包括Oracle的数据保护方案DataGuard、MySQL主备同步以及基于选举协议的主备同步。

重做日志（undo log）是数据库中的关键结构。重做日志用于记录数据库发生的修改。重做日志可以包括一个或多个日志文件。对于主备同步方案，主数据库和备数据库可以分别关联对应的重做日志。在发生灾害时，可以基于重做日志进行数据的恢复。主数据库可以将重做日志同步到备数据库，以实现数据的备份。

作为一种实现方式，基于主备同步的容灾方法可以包括步骤S101~步骤S105。步骤S101，主数据库接收事务请求。步骤S102，主数据库执行事务请求对应的修改操作。步骤S103，主数据库将修改操作同步至备数据库。作为一种实现方式，主数据库可以将修改操作写入重做日志文件，并将重做日志文件同步至备数据库。步骤S104，主数据库向修改事务的发起方发送事务请求的应答。下面分别对不同模式进行详细说明。

主数据库与备数据库之间的同步可以通过以下模式实现：最高保护模式(maximumprotection)、最高性能模式(maximum performance)或最高可用模式(maximumavailability)。

在最高保护模式下，在修改操作同步到备数据库成功的情况下，主数据库才可以应答修改事务的发起方。因此，最高保护模式可以实现主数据库的数据和备数据库的数据完全一致。作为一种实现方式，如果主数据库接收到备数据库反馈的同步成功消息，主数据库可以应答修改事务发起方反馈修改事务执行成功。或者，如果主数据库在一定时间内未收到备数据库的同步成功消息，主数据库可以不应答修改事务的发起方。

在最高性能模式下，主数据库成功完成事务请求对应的操作后，即可应答事务请求的发起方，而不需要考虑修改事务同步到备数据库的情况。作为一种实现方式，主数据库将本地的重做日志写入成功即可向修改事务发起方反馈修改事务执行成功。后台线程可以将重做日志异步复制到备数据库。

在最高可用模式下，如果备数据库可用，则同步模式为最高保护模式。如果备数据库不可用，例如备数据库发生故障或主数据库和备数据库之间的网络发生故障，则同步模式退化为最高性能模式。

在一些实施例中，最高保护模式可以称为强同步模式，最高性能模式或最高可用模式可以称为异步复制模式。

基于选举协议的主备同步容灾机制

选举协议可以基于多数派投票实现。选举协议可以用于解决如何就某个值（或决议）达成一致的问题。为实现选举协议，需要部署至少3个节点，以支持多数派（超过一半）和少数派。选举协议例如可以包括Paxos或者Raft（即Paxos简化版）。

在基于选举协议的主备同步方案中，系统需要部署至少3个节点（也可以称为副本），每个节点均用于存储数据，即系统中至少包括3个数据库。在实际部署中，系统可以部署3个、5个或更多节点。以系统部署了3个节点为例，每次主备同步或者主备切换，均需要在至少2个节点上执行成功，才可以认为执行成功。以系统部署了5个节点为例，每次主备同步或者主备切换，均需要在至少3个节点上执行成功，才可以认为执行成功。

对于主备同步，当操作同步到多数派（超过一半）节点时，可以向修改事务发起方反馈修改事务执行成功。对于主备切换，当少数派（可以是主数据库也可以是备数据库）发生故障时，可以通过选举协议选出新的节点继续提供服务。

无损自动容灾

容灾机制可以通过恢复点目标（recovery point objective，RPO）和恢复时间目标（recovery time objective）中的至少一个评估。RPO可以指最多可能丢失的数据的时长。RTO可以指从灾难发生到恢复正常所需要的最大时长。可以理解的是，RPO越短，可能丢失的数据越少。RTO越短则数据库可以正常运行的时间越长。

故障发生后，如果系统可以在较短的时间内自动恢复，并且不丢失数据，则该系统可以实现无损自动容灾。例如，如果一个系统的RPO=0，且RTO比较短（例如RTO小于一分钟），则可以认为该系统可以实现无损容灾。

下面逐一分析上述主备同步方案对于无损自动容灾的支持情况。

在最高保护模式下，备数据库的数据与主数据库的数据是强一致的，当主数据库发生故障时，进行主备切换不会丢失数据。当备数据库发生故障时，无法进行主备同步，需要暂停服务。

在最高性能模式下，当备数据库发生故障时，主数据库可以继续服务，因此可以实现高可用。当主数据库发生故障时，由于可能存在主数据库数据尚未同步至备数据库的情况，无法保证备数据库与主数据库数据的一致性，切换到备数据库存在数据丢失的可能。

最高可用模式是最高保护模式和最高性能模式的结合。因此，依然无法确定备数据库中的数据与主数据库中的数据是一致的。当主数据库发生故障时，难以实现无损主备切换。

有此可知，最高保护模式、最高性能模式或最高可用模式在主数据库或备数据库发生故障后，可能出现服务暂停或者数据损失的情况。因此，上述三种模式均难以实现自动无损容灾。

基于选举协议的主备机制在少数派不可用（例如节点发生故障或节点间的通信发生故障）时，可以继续服务。以系统包括3个储存数据的节点为例，少数派为1个节点。也就是说，当3个节点中的任意一个（主数据库或备数据库）不可用时，多数派可以继续服务。有此可知，基于选举协议的主备机制可以实现自动无损容灾。以同机房3个节点的部署模式为例，该模式可以支持机房中一台机器上的数据库故障后无损容灾。或者，以同城市三个机房的部署模式为例，该模式可以支持一个机房的数据库故障后无损容灾。或者，以三地五中心的部署模式为例，该模式可以支持一个城市的数据库故障后无损容灾。

由上文可知，最高保护模式、最高性能模式或最高可用模式要么只可以在主数据库不可用时正常服务，要么只可以在备数据库不可用时正常服务，难以实现主数据库或者备数据库中任一不可用时仍可以正常提供服务。因此，上述三种模式均难以实现自动无损容灾。基于选举协议的主备同步虽然可以实现任一节点（主数据库或备数据库）的无损容灾，但是存储数据的节点较多，存储成本较高。有此可知，相关技术难以实现无损自动容灾，或者实现无损自动容灾的成本较高。

针对上述问题，本公开提出一种同步主备数据库的方法。图1是本公开实施例提出的一种同步主备数据库的方法的示意性流程图。图1所示的方法可以由主数据库、第一备数据库、仲裁方以及发起方实现。图1所示的方法可以包括步骤S110~步骤S160。

步骤S110，主数据库接收第一事务请求。

第一事务请求可以用于请求对主数据库中的数据进行修改。发起方可以通过向主数据库发送至少一个事务请求，第一事务请求可以为至少一个事务请求中的任意一项。第一事务请求的发起方可以为客户端。

步骤S120，响应于第一事务请求，对主数据库中的数据执行修改操作。

修改操作与第一事务请求对应。修改操作可以包括对主数据库中的数据进行新增、删除以及更改等操作中的至少一项。

步骤S130，根据修改操作，对第一备数据库进行数据同步。

作为一种实现方式，可以将修改操作发送到第一备数据库，以供第一备数据库进行同步。

主数据库与第一备数据库之间的数据同步可以基于重做日志实现。作为一种实现方式，步骤S130可以包括步骤S131和步骤S132。

步骤S131，根据所述修改操作，生成重做日志。例如，主设备库可以将修改操作写入本地日志文件，以生成重做日志。

步骤S132，向第一备数据库发送重做日志。

第一备数据库可以根据接收到的重做日志生成第一备数据库的重做日志。例如，第一备数据库可以将主数据库的重做日志复制到第一备数据库。

主数据库可以与多个备数据库进行数据同步。第一备数据库可以是多个数据库中的任意一个。

主数据库将数据同步至第一备数据库可能成功也可能失败。在同步成功的情况下，第一备数据库可以反馈消息，例如“同步成功”的消息。在同步失败的情况下，第一数备据库可以反馈消息，例如“同步失败”的消息。或者，在一些情况下，第一备数据库无法进行反馈或者反馈信息无法送达主数据库。因此，如果第一备数据库超过一定时间未反馈同步结果，主数据库也可以确定第一数据同步到第一备数据库失败。

步骤S140，如果所述数据同步失败，主数据库向仲裁方发送通知消息。

通知消息用于通知仲裁方将第一备数据库从第一数据集合中删除。

步骤S150，根据通知消息，仲裁方将第一备数据库从第一数据库集合中删除。

仲裁方可以维护第一数据库集合。第一数据库集合中的数据库均可以为与主数据库数据同步的备数据库。可以理解的是，第一数据库集合中的备数据库的数据与主数据库的数据是具有强一致性的。

仲裁方可以参考第一数据库集合选择进行主备切换的备数据库，从而可以避免主备切换时主备数据库中的数据不一致导致数据丢失的情况。作为一种实现方式，仲裁方检测到主数据库不可用（例如主数据库发生故障）时，仲裁方可以在第一数据库集合中自动选择一个备数据库进行切换，而不选择第一数据库集合中没有的备数据库。

不论步骤S130中的数据同步是否成功，主数据库均可以执行步骤S160。

步骤S160，向所述第一事务的发起方发送针对所述第一事务请求的应答。

可以理解的是，主数据库可以应答第一事务请求的发起方成功修改事务。发起方收到应答后，可以继续发送其他事务请求。主数据库对发起方的应答可以与第一备数据库的数据是否与主数据库同步成功无关。因此，即使数据同步至第一备数据库失败（即主数据库向仲裁方发送了通知消息），只要成功修改事务执行，就可以应答第一事务的发起方。

作为一种实现方式，主数据库与第一备数据库同步数据失败后，后续其他事务请求产生的修改操作只需要在主数据库执行成功和/或写入主数据库的日志成功即可应答发起方，后续可以不向第一备数据库同步数据。需要说明的是，主数据可以在不向第一备数据库同步数据之前，向仲裁方发送通知消息将第一备数据库从第一数据库集合中移除，从而使得仲裁者维护的第一数据库集合中的备数据库中的数据总是最新的。

由此可知，修改操作同步至第一备数据库失败的情况下，即第一备数据库不可用（例如第一备数据库发生故障或主数据库与第一备数据库之间的网络发生故障），主数据库可以不停止服务并且通知仲裁方将第一备数据库从第一数据库集合中删除。当主数据库不可用时，仲裁方可以通过第一数据库集合，选择与主数据库数据一致的备数据库切换为主数据库，而不会导致数据丢失。因此，基于本公开提供的方法，在主数据库或者第一备数据库中任意一个不可用时，系统仍可以继续服务，并且不会出现数据丢失的问题。有此可知，本公开提供的主备同步方案的RPO等于0，RTO小于一分钟，即可以实现自动无损容灾。也就是说，本公开不仅可以实现数据库高可用，也可以实现主备切换时数据不丢失。

另外，本公开需要至少2个用于数据存储的节点（一个主数据库和一个备数据库）即可实现无损容灾。与需要至少3个用于存储的节点（一个主数据库和两个备数据库）的方案（例如基于选举协议的主备同步方案）相比，减少了需要存储的数据副本，从而降低了数据存储的成本。

本公开不限制第一数据库集合记录的方式。作为一种实现方式，第一数据库集合可以通过列表的方式记录，即通过同步列表记录与主数据库数据一致的备数据库。

作为一种实现方式，如果主数据库的所有修改操作均同步至第一备数据库成功，主数据库可以发送添加第一备数据库的第一消息仲裁方可以根据第一消息将第一备数据库添加至第一数据库集合中。例如，在仲裁方将第一备数据库从第一数据库集合中删除后，如果第一备数据库恢复可用状态，并且主数据库与第一备数据库进行数据同步成功，主数据库可以通知仲裁方将第一备数据库添加到第一数据库集合中。或者，在第一备数据库初始注册到主数据库后，主数据库与第一备数据库进行数据同步成功，主数据库可以通知仲裁方将第一备数据库添加到第一数据库集合中。

主数据库可以有多个与之关联的备数据库，第一备数据库可以为多个备数据库中的任意一个。对于这种情况，第一备数据库集合中可以包括一个或多个备数据库。主数据库可以向仲裁方发送针对不同备数据库的通知消息，以通知仲裁方将哪个或哪些备数据库从第一数据库集合中删除。

仲裁方可以是与主数据库以及备数据库相对独立的第三方，因此，仲裁方可以被称为第三方仲裁方或第三方仲裁者。

在部署仲裁方时，可以将仲裁方与数据库（包括主数据库、第一备数据库或其他备数据库）分开部署。例如仲裁方可以与数据库部署在不同的机器、不同的机房或不同的城市。在数据库遭受灾害的情况下，与数据库分开部署的仲裁方可以免于遭受灾害，从而使得即使数据库遭遇灾害仲裁方也可以正常服务。

仲裁方可以通过选举协议实现，以实现仲裁方的高可用。作为一种实现方式，仲裁方可以采用Paxos或Raft选举协议实现。仲裁方可以包括至少3个节点（例如3个或5个节点）。当仲裁方的少数节点不可用（例如出现节点故障或者网络故障），则可以通过选举协议选出新的节点继续提供服务，从而使得仲裁方具有高可用性。可以理解的是，除了选举协议，仲裁方也可以通过其他能够实现高可用性的方式实现。

多个系统可以共享一个仲裁方，从而降低仲裁方的部署成本。也就是说，仲裁方可以用于维护与多个主数据库一一对应的多个数据库集合。每个数据库集合包括与对应主数据库数据同步的备数据库。例如，一个公司可以部署一套全局可用的仲裁方服务，所述的数据库节点均可以共享这一套仲裁方服务。

图2和图3为本公开实施例提供的一种主备同步容灾方法的示意图。

图2示出了主数据库和第一备数据库均可用时的主备同步方法。图2所示的方法可以由客户端、主数据库以及第一备数据库执行。仲裁方可以包括3个节点（节点通过图3中的圆圈表示），基于选举协议实现。

图2所示的方法可以包括步骤S210~步骤S240。

步骤S210，客户端向主数据库发送修改事务请求。

步骤S221，主数据库在本地日志文件中写日志。本地日志文件可以为主数据库的重做日志文件。

步骤S222，将修改操作同步到第一备数据库。步骤S221和步骤S222可以同步进行。

步骤S230，响应于主备同步操作，第一备数据库将修改操作写入备数据库的日志文件。

步骤S240，第一备数据库向主数据库应答“同步成功”。

步骤S250，主数据库向客户端发送第二信息，第二信息用于应答客户端成功执行修改事务。

图3示出了第一备数据库不可用情况下故障处理方法。图3所示的方法可以由客户端、主数据库、第一备数据库以及仲裁方执行。仲裁方可以包括3个节点（节点通过图3中的圆圈表示），基于选举协议实现。

图3所示的方法可以包括步骤S310~步骤S340。

步骤S310，客户端向主数据库发送修改事务请求。

步骤S321，主数据库在本地日志文件中写日志。本地日志文件即主数据库的重做日志文件。

步骤S322，将修改操作同步到第一备数据库。步骤S321和步骤S322可以同步进行。

步骤S330，在主数据库超过一定时间后未收到第一备数据库对主备同步的应答（即第一备数据库以及第一备数据库与主数据库之间的网络中至少一项故障）的情况下，主数据库向仲裁方发送第一信息，以通知仲裁方将第一备数据库从同步列表中剔除。

步骤S340，主数据库向客户端发送第二信息，第二信息用于应答客户端成功修改事务。

基于图2和图3所示的方法，可以实现中在这维护的同步列表中的备数据库中的数据与主数据库的数据是一致的。后续无论是主数据库或者备数据库不可用，仲裁方都可以在检测到故障后再同步列表中选择一个数据库（例如一台服务器）继续进行同步服务。

例如，在第一备数据库故障的情况下，主数据库向第一备数据库同步失败后可以将第一备数据库从同步列表中剔除。后续主数据库写本地日志文件成功后即可向客户端反馈第二信息。

或者，在主数据库与第一备数据库之间网络发生故障的情况下，主数据库往第一备数据库同步失败后可以将第一备数据库从同步列表中剔除。后续主数据库写本地日志文件成功后即可向客户端反馈第二信息。接下来，如果第一备数据库发生故障，可以无需处理。后续如果主数据库故障，由于第一备数据库不在同步列表中，仲裁者可以不选择第一备数据库切换为主数据库，从而避免了数据丢失的情况。

或者，在主数据库发生故障的情况下，仲裁方检测到主数据库故障，在一段时间后，可以将同步列表中的备数据库（如果同步列表中包括第一备数据库，可以选择第一备数据库）切换为主数据库继续进行服务。

上文通过图1~图3介绍了本公开提供的方法实施例，下面结合图4~图6介绍本公开提供的装置实施例。

图4为本公开实施例提供的一种同步主备数据库的装置400的结构示意图。装置400可以是具有计算功能的计算设备，例如服务器。装置400部署有主数据库。装置400可以包括第一接收单元410、执行单元420、同步单元430、第一发送单元440和应答单元450。

第一接收单元410可以用于接收第一事务请求，所述第一事务请求用于请求对主数据库中的数据进行修改；

执行单元420可以用于响应于所述第一事务请求，对所述主数据库中的数据执行修改操作；

同步单元430可以用于根据所述修改操作，与第一备数据库进行数据同步；

第一发送单元440可以用于如果所述数据同步失败，向仲裁方发送通知消息，所述通知消息用于通知所述仲裁方将所述第一备数据库从第一数据库集合中删除，所述第一数据库集合中的数据库均为与所述主数据库数据同步的备数据库；

应答单元450可以用于向所述第一事务的发起方发送针对所述第一事务请求的应答。

可选地，所述同步单元430可以包括：生成单元和第二发送单元。生成单元可以用于根据所述修改操作，生成重做日志。第二发送单元可以用于向所述第一备数据库发送重做日志。

图5本公开实施例提供的一种同步主备数据库的装置500的结构示意图。装置500可以是具有计算功能的计算设备，例如服务器。装置500部署有仲裁方。装置500可以包括第二接收单元510以及删除单元520。

第二接收单元510可以用于接收主数据库发送的通知消息，所述通知消息用于通知所述仲裁方将所述第一备数据库从第一数据库集合中删除，所述第一数据库集合中的数据库均为与所述主数据库数据同步的备数据库。

删除单元520可以用于根据所述通知消息，将所述第一备数据库从所述第一数据库集合中删除。

可选地，装置500还可以包括：选择单元。选择单元可以用于从所述第一数据库集合中选择用于切换为主数据库的数据库。

可选地，所述第一数据集合通过列表记录。

可选地，所述仲裁方基于选举协议实现。

图6是本公开又一实施例提供的同步主备数据库的装置的结构示意图。该装置600例如可以是具有计算功能的计算设备。比如，装置600可以是移动终端或者服务器。装置600可以包括存储器610和处理器620。存储器610可用于存储可执行代码。处理器620可用于执行所述存储器610中存储的可执行代码，以实现前文描述的各个方法中的步骤。在一些实施例中，该装置600还可以包括网络接口630，处理器620与外部设备的数据交换可以通过该网络接口630实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其他任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber line，DSL））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质（例如，软盘、硬盘、磁带）、光介质（例如数字视频光盘（digital video disc，DVD））、或者半导体介质（例如固态硬盘（solid state disk，SSD））等。

本领域普通技术人员可以意识到，结合本公开实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

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

Claims (13)

1.一种同步主备数据库的方法，所述方法应用于主数据库，所述方法包括：

接收第一事务请求，所述第一事务请求用于请求对主数据库中的数据进行修改；

响应于所述第一事务请求，对所述主数据库中的数据执行修改操作；

根据所述修改操作，与第一备数据库进行数据同步；

如果所述数据同步失败，向仲裁方发送通知消息，所述通知消息用于通知所述仲裁方将所述第一备数据库从第一数据库集合中删除，所述第一数据库集合中的数据库均为与所述主数据库数据同步的备数据库；

向所述第一事务的发起方发送针对所述第一事务请求的应答。

2.根据权利要求1所述的方法，所述根据所述修改操作，与第一备数据库进行数据同步包括：

根据所述修改操作，生成重做日志；

向所述第一备数据库发送重做日志。

3.一种同步主备数据库的方法，所述方法应用于仲裁方，所述方法包括：

接收主数据库发送的通知消息，所述通知消息用于通知所述仲裁方将第一备数据库从第一数据库集合中删除，所述第一数据库集合中的数据库均为与所述主数据库数据同步的备数据库；

根据所述通知消息，将所述第一备数据库从所述第一数据库集合中删除。

4.根据权利要求3所述的方法，所述方法还包括：

从所述第一数据库集合中选择用于切换为主数据库的数据库。

5.根据权利要求3所述的方法，所述第一数据集合通过列表记录。

6.根据权利要求3所述的方法，所述仲裁方基于选举协议实现。

7.一种同步主备数据库的装置，所述装置部署有主数据库，所述装置包括：

第一接收单元，用于接收第一事务请求，所述第一事务请求用于请求对主数据库中的数据进行修改；

执行单元，用于响应于所述第一事务请求，对所述主数据库中的数据执行修改操作；

同步单元，用于根据所述修改操作，与第一备数据库进行数据同步；

第一发送单元，用于如果所述数据同步失败，向仲裁方发送通知消息，所述通知消息用于通知所述仲裁方将所述第一备数据库从第一数据库集合中删除，所述第一数据库集合中的数据库均为与所述主数据库数据同步的备数据库；

应答单元，用于向所述第一事务的发起方发送针对所述第一事务请求的应答。

8.根据权利要求7所述的装置，所述同步单元包括：

生成单元，用于根据所述修改操作，生成重做日志；和

第二发送单元，用于向所述第一备数据库发送重做日志。

9.一种同步主备数据库的装置，所述装置部署有仲裁方，所述装置包括：

第二接收单元，用于接收主数据库发送的通知消息，所述通知消息用于通知所述仲裁方将第一备数据库从第一数据库集合中删除，所述第一数据库集合中的数据库均为与所述主数据库数据同步的备数据库；

删除单元，用于根据所述通知消息，将所述第一备数据库从所述第一数据库集合中删除。

10.根据权利要求9所述的装置，所述装置还包括：

选择单元，从所述第一数据库集合中选择用于切换为主数据库的数据库。

11.根据权利要求9所述的装置，所述第一数据集合通过列表记录。

12.根据权利要求9所述的装置，所述仲裁方基于选举协议实现。

13.一种同步主备数据库的装置，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器被配置为执行所述可执行代码，以实现权利要求1-6中任一项所述的方法。

Images