CN106919473B - 一种数据灾备系统及业务处理方法 - Google Patents

Abstract

本申请公开了一种数据灾备系统及业务处理方法。一种数据灾备系统包括主库、读库和故障切换库；主库与读库部署在不同的网络连接区域、故障切换库与读库部署在相同的网络连接区域；主库和读库：在非故障状态下处理数据操作请求，主库向读库同步数据；故障切换库：在非故障状态下不启用；在故障状态下，利用读库作为数据恢复来源，以代替主库处理数据操作请求；应用本申请方案，可以有效降低灾备系统的部署和维护开销，并且提高资源的实际利用率。

Description

一种数据灾备系统及业务处理方法

技术领域

本申请涉及数据库技术领域，尤其涉及一种数据灾备系统及业务处理方法。

背景技术

在大数据时代，数据的灾备是一个不可忽视的问题，如何以较低的成本实现最佳的灾备性能，一直是研究人员所关注的重要方向。

基于数据量增加、业务类型增加等客观需求，不可避免地需要将业务数据分别存储在多个物理数据库中，并且多个物理数据库可能分别被部署在不同的网络区域，例如不同的物理网络连接区域、不同的逻辑网络连接区域等等。如图1所示，机房A和机房B分别处于不同的网络连接区域，机房A中部署了应用服务器A和数据库A、机房B中部署了应用服务器B和数据库B，两个机房所处理的业务不同，存储的数据也不同。假设机房A网络出现了故障，那么所有的用户业务请求都无法达到应用服务器A，而且数据库A和数据库B中存储的数据不同，因此即使强行把用户业务请求路由到应用服务器B，也仍然无法正常对业务进行处理。

发明内容

针对上述技术问题，本申请提供一种数据灾备系统及业务处理方法，技术方案如下：

一种数据灾备系统，该系统包括：主库、读库和故障切换库；

主库与读库部署在不同的网络连接区域、故障切换库与读库部署在相同的网络连接区域；

主库和读库：在非故障状态下处理数据操作请求，主库向读库同步数据；

故障切换库：在非故障状态下不启用；在故障状态下，利用读库作为数据恢复来源，以代替主库处理数据操作请求；

其中，所述故障状态、非故障状态均指主库侧的状态。

此外，本申请还提供应用于上述系统的业务处理方法。

本申请所提供的技术方案，在数据库读写分离机制的基础上，将读库与主库部署在不同的网络连接区域，并且在读库侧部署用于在故障期间接替主库的故障切换库。该方案的优势在于：相当于针对每个网络连接区域仅需部署一套数据系统即可实现灾备目的，故障切换库仅在故障状态下启用，维护开销基本可以忽略，用于数据灾备的读库在非故障状态下还能够正常处理数据读取业务，也具有较高的资源实际利用率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是现有技术的双机房数据库系统的结构示意图；

图2是本申请的数据灾备系统的第1种结构示意图；

图3是图2所示系统结构下的灾备处理示意图；

图4是本申请的数据灾备系统的第2种结构示意图；

图5是图4所示系统结构下的灾备处理示意图；

图6是本申请的数据灾备系统的第3种结构示意图；

图7是图6所示系统结构下的灾备处理示意图；

图8是本申请的数据灾备系统的第4种结构示意图；

图9是本申请的数据灾备系统的第5种结构示意图。

具体实施方式

针对背景技术中所提出的问题，一种可用的灾备方案是：在机房B(或者其他机房)部署数据库A的全量备份，正常状态下，主库和备库进行实时数据备份，这样当主库侧出现故障(包括数据库自身故障和网络故障)时，备库可以接替主库。但是这种方案的问题在于：相当于针对每个机房都要部署两套数据库系统，不仅部署和维护开销翻倍，而且备库只有在故障发生后才能起到作用，导致资源利用率低下。此外，根据具体的设备配置、应用需求场景的不同，还有可能存在数据同步不及时、故障切换时间较长等具体问题，这些也都有可能影响到故障期间业务的正常处理。

本申请所提供的灾备解决方案是：利用目前已有的数据库读写分离机制，将读库与主库部署在不同的网络连接区域，并且在读库侧部署用于在故障期间接替主库的故障切换库。这样做的优势在于：相当于针对每个网络连接区域仅需部署一套数据系统即可实现灾备目的，故障切换库仅在故障状态下启用，维护开销基本可以忽略，用于数据灾备的读库在非故障状态下还能够正常处理数据读取业务，也具有较高的实际资源利用率。

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

图2所示，为本申请一种数据灾备系统的结构示意图，该系统至少包括：主库、读库和故障切换(Failover，FO)库；

主库：常规意义上的数据库，能够处理写入业务处理请求和读取业务处理请求。

读库：自动从主库中同步数据，仅处理读取业务处理请求，作用是帮助主库分担一部分读取请求以减轻主库压力，读写分离的数据库访问机制属于现有技术，本申请中不做进一步的详细说明。

故障切换库：在非故障状态下不启用(图2中以虚线框表示)；在故障状态下代替主库处理数据操作请求。

为描述方便，本申请中的“故障状态”、“非故障状态”均指主库侧的状态，而且这里的“故障”应理解为对各种“主库不可用”情况的统称，具体原因既可以是数据库自身的故障，也可以是主库所处网络方面的故障等等。

从图中可以看出，主库与读库部署在不同的网络连接区域、故障切换库与读库部署在相同的网络连接区域。这里的“网络连接区域”可以是物理意义上网络连接区域，例如机房等，也可以是逻辑意义上的网络连接区域，例如网段等，本申请对“网络连接区域”所对应的具体概念、也即本申请方案的应用场景并不需要进行限定。另外需要说明的是，本申请方案的要点在于提供新的数据库部署方案，对于应用服务器所处的网络位置并不需要进行限定，例如，应用服务器可以与数据库系统的组件处于相同的网络连接区域、也可以与数据库系统的组件处于不同的网络连接区域，这些并不影响本申请方案的实施，因此，在图2以及本后续说明书附图中所示的应用服务器位置不应理解为对本申请方案的限定。

在非故障状态下，主库和读库除了位于不同的网络连接区域之外，工作方式与现有的主库/读库工作方式基本相同。故障切换库在非故障状态下不启用，避免平时额外的资源占用和维护开销。

如图3所示，在主库侧出现故障后，主库变为不可用，原本需要转发给主库的业务处理请求将转发至读库和故障切换库所处的另一网络连接区域。

在另一网络连接区域，需要启用故障切换库(图3中以实线框表示)，并且由故障切换库代替主库来处理数据操作请求。一方面，由于故障切换库在非故障期间是不启用的，因此在启用的初始阶段，故障切换库中并不存在有效的可用数据；另一方面，由于在故障之前，读库一直保持与主库的自动数据同步，因此读库中基本保存有故障之前主库的完整数据备份(由于数据同步存在延时，因此有可能缺少最新的数据，解决方案将在后面实施例中介绍)。基于上述两个方面，可用利用读库作为故障切换库的数据恢复来源。

一种可行的数据恢复方式是：发生故障后，立即将读库中的全量数据恢复至故障切换库；然而在实际应用中，考虑到故障切换库只是临时代替主库，因此没有必要恢复全量数据。在本申请的一种具体实施方式中，可以采用按需恢复数据的方式，即：在发生故障后，不需要将全量数据恢复至故障切换库，而是待后续正常网络连接区域收到数据操作请求后，再将处理该数据操作请求所需的数据恢复至故障切换库。这样可以减少不要的数据恢复所消耗的时间，基本上可以做到故障恢复用户无感知。

当然，在实际应用中，还可以采用其他针对性的数据恢复方案，例如在发生故障后，仅将访问需求频率较高的数据恢复到故障切换库，等等，本申请对具体的数据恢复方案不需要进行限定。

另外，在实际应用中，也可以对故障期间读库与故障切换库的功能进行适当调整，其中故障切换库至少需要处理数据写入业务，还可以进一步处理数据读取业务，读库可以正常处理数据读取业务，也可以暂时停用。对于写入故障切换库的数据，可以同步到读库中；也可以不进行同步、待故障排除后一并恢复至主库，本领域技术人员可以根据实际需求灵活设置。

在实际应用中，上述方案可能存在一个问题：由于主库和读库处于不同的网络连接区域，而且采用的是常规的数据库同步机制，受到通信距离、数据库性能等多方面因素的影响，难免存在数据同步时延，尽管在有些应用场景下，该时延可以忽略，但是在理论上仍然存在故障后读库中缺少最新写入的数据、从而导致业务处理错误的问题。针对该问题，本申请提供的一种改进方案是：利用数据快照的方式保存最新写入的数据，当出现故障时，利用快照和读库作为共同的数据恢复来源，从而避免由于数据库同步时延所导致的最新写入数据缺失问题。

数据快照也是一种常用的数据安全技术，与常规的数据库同步方式相比，快照方式具有更快的处理速度，参见图4所示，在读库所在的网络区域中，进一步配置快照库，作用是以快照方式保存主库的最新数据写入情况。具体而言，在非故障状态下，应用服务器接收到用户侧的写入业务处理请求，将对象数据写入主库，同时也将对象数据以快照方式写入快照库，其中快照方式的具体实现可以包括：利用即时消息传输数据、利用高速缓存存储数据、等等，本申请并不需要对快照的具体实现技术进行限定。

由于读库与主库之间一直在进行数据同步，因此在快照库中不需要保存全量数据，只需要保存“最新”写入主库的数据快照即可满足故障恢复需求。实际应用时，可以将快照库中保留的最新数据对应时长设置为不小于主库到读库的数据同步时延，从而降低快照存储所带来的额外开销。

如图5所示，在主库侧出现故障后，读库与快照库将共同成为故障切换库的数据恢复来源，可以理解的是，实际进行数据恢复时，可能需要同时使用读库与快照库，也可能仅需使用其中之一，读库仍然是主要的数据恢复来源，而快照库则可以有效弥补主库到读库的数据同步时延所导致的最新数据缺失，从而保证故障期间业务的正常处理。具体的数据恢复方式与前面的实施例类似，本实施例不再赘述。

以上介绍了一种基本的数据灾备方案，实际应用中，在上述方案的基础上，还可以衍生出多种具体的实施方案。

图6示出了一种利用本申请基本方案实现的双机房交叉备份系统，要求在两个处于不同网络连接区域的机房中，实现A和B两套业务处理系统的正常运行及故障恢复需求，根据本申请方案，提供具体的部署方式如下：

对于业务处理系统A：

主库A部署在机房1；

读库A、故障切换库A、快照库A部署在机房2；

对于业务处理系统B：

主库B部署在机房2；

读库B、故障切换库B、快照库B部署在机房1；

图6中，以实心箭头和虚心箭头来区分两条业务系统的业务信息流向。两套业务系统的数据库在处理逻辑上是相互独立的，对于任意一套业务系统，其主库、读库、故障切换库、快照库的工作方式与前面实施例的介绍相同，这里不再做详细说明。此外，在某些情况下，同一房内部的不同业务系统的组件可以复用相同的物理资源，本申请对此并不需要进行限定。

应用上述方案，可以形成机房1与机房2之间的交叉备份关系。例如，当机房1中出现故障后，主库A不可用，位于机房2的故障切换库A启用，利用读库A和快照库A恢复数据，以代替主库A处理数据操作请求。并且，在此期间主库B仍然能够正常处理业务处理系统B的自身数据操作请求。

具体而言，任一主库侧故障状态下，应用服务器接收用户侧的业务处理请求后，首先判断该业务对应的数据操作是属于哪套业务处理系统，然后根据判断结果分别进行转发：

对于非故障侧(即主库可用)业务处理系统的数据操作请求，正常转发至位于非故障侧的主库进行业务数据处理；

对于故障侧(即主库不可用)业务处理系统的数据操作请求，将转发至位于非故障侧的故障切换库进行业务数据处理。

需要说明的是，在上述的交叉备份机制下，当某一侧出现故障、并且故障是网络问题所导致的情况下，另一侧的主库虽然仍可以正常处理业务，但是却无法正常进行备份。如图7所示，当机房1出现故障后，除主库A之外，读库B、快照库B也处于不可用状态，这种情况下，可以临时停止非故障侧的主库(主库B)向位于故障侧的读库(读库B)数据同步，同时也临时停止向位于故障侧的快照库(快照库B)写入快照数据，以避免无效操作，当故障排除后，再重新恢复上述备份机制。

另外，尽管图6和图7都示出了配置快照库的情况，然而根据本申请方案，在某些应用场景下，仍然允许不在系统中配置快照库，或者仅在单侧配置快照库，因此图6和图7不应理解为对本申请方案的限定。

可以理解的是，除上述的双机房交叉备份系统之外，基于本申请原理，还可以设计出其他的数据灾备方案，例如n区域交叉备份系统(如图8所示)、或者集中式备份系统(如图9所示)，对于这些设计方案，本申请无法一一列举，但是对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰均应视为本申请的保护范围。

Claims (8)

1.一种数据灾备系统，其特征在于，该系统包括：主库、读库、快照库和故障切换库；

主库与读库部署在不同的网络连接区域；快照库、故障切换库与读库部署在相同的网络连接区域；

主库和读库：在非故障状态下处理数据操作请求，主库向读库同步数据；

快照库：用于在非故障状态下，在所接收的数据不经过所述主库的情况下，以快照的方式保存主库在预设时长内的最新数据写入情况；

故障切换库：在非故障状态下不启用；在故障状态下，利用读库和/或快照库作为数据恢复来源，以代替主库处理数据操作请求；

其中，所述故障状态、非故障状态均指主库侧的状态。

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

用于存储第一业务数据的第一主库、第一读库和第一故障切换库、

用于存储第二业务数据的第二主库、第二读库和第二故障切换库；

所述第一主库与第二读库、第二故障切换库部署在第一网络连接区域；

所述第二主库与第一读库、第一故障切换库部署在第二网络连接区域；

第一快照库，部署在第二网络连接区域，用于在第一主库非故障状态下，以快照的方式保存第一主库在预设时长内的最新数据写入情况；

第二快照库，部署在第一网络连接区域，用于在第二主库非故障状态下，以快照的方式保存第二主库在预设时长内的最新数据写入情况。

3.根据权利要求2所述的系统，其特征在于，在任一主库侧出现故障后，非故障侧的主库停止向位于故障侧的读库同步数据。

4.根据权利要求2所述的系统，其特征在于，在任一主库侧出现故障后，非故障侧停止向位于故障侧的快照库写入快照数据。

5.根据权利要求1至4任一项所述的系统，其特征在于，所述故障切换库在故障状态下的数据恢复方式包括：

发生故障后，将全量数据恢复至故障切换库；

或者

在故障状态下，根据接收到的数据操作请求，将处理所述数据操作请求所需的数据恢复至故障切换库。

6.一种应用于如权利要求1所述系统的业务处理方法，其特征在于，该方法包括：

在故障状态下，应用服务器接收用户侧的业务处理请求后，将所述业务处理请求转发至故障切换库进行业务数据处理。

7.一种应用于如权利要求1或2所述系统的业务处理方法，其特征在于，该方法包括：

在非故障状态下，应用服务器接收用户侧的写入业务处理请求，将对象数据写入主库，并且将对象数据写入快照库。

8.一种应用于如权利要求2所述系统的业务处理方法，其特征在于，该方法包括：

任一主库侧故障状态下，应用服务器接收用户侧的业务处理请求后，判断对应的数据操作所属侧；

将非故障侧数据操作请求转发至位于非故障侧的主库进行业务数据处理；

将故障侧数据操作请求转发至位于非故障侧的故障切换库进行业务数据处理；

停止向位于故障侧的快照库写入快照数据。

Images