一种数据容灾方法、装置及计算机可读介质

技术领域

本申请涉及计算机及通信技术领域，尤其涉及一种动态容灾方法、装置及计算机可读介质。

背景技术

大型多人在线角色扮演游戏（Multiplayer Online Role Playing Game，MMORPG）是电子角色扮演游戏按照人数分类出的一种网络游戏，在MMORPG中，玩家可扮演一个或多个虚拟角色，并控制该角色在游戏中虚拟世界的活动与行为。但是，MMORPG的玩家众多，游戏规则复杂，存储的游戏数据大部分为状态数据，例如玩家货币、经验值等，对于游戏业务而言，游戏数据具有极高的价值，一旦丢失，会对游戏的运营及游戏口碑造成严重影响。然而，目前的数据容灾方案存在恢复时间长、数据易丢失等问题。

发明内容

本申请的实施例提供了一种数据容灾方法、装置及计算机可读介质，进而至少在一定程度上能够缩短容灾方案的服务恢复时间，同时，在容灾切换过程中，保持数据的一致性。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供了一种数据容灾方法，包括：对数据库集群内的各个节点进行监控，所述数据库集群包括主节点和至少一个从节点，所述至少一个从节点保持与所述主节点的数据同步；当监控到所述主节点的状态异常时，从所述至少一个从节点中选择从节点作为当前主节点；添加第一备用节点至所述数据库集群，将所述当前主节点的数据同步至所述第一备用节点；在将所述当前主节点的数据同步至所述第一备用节点之后，将所述第一备用节点作为所述数据库集群的主节点。

根据本申请实施例的一个方面，提供了一种数据容灾方法，包括：若监控到所述至少一个从节点中存在状态异常的目标从节点，添加第二备用节点至所述数据库集群；将所述目标从节点的数据同步至所述第二备用节点，在将所述目标从节点的数据同步至所述第二备用节点之后，将所述第二备用节点作为所述数据库集群的从节点。

根据本申请实施例的一个方面，提供了一种数据容灾装置，包括：监控单元，用于对数据库集群内的各个节点进行监控，所述数据库集群包括主节点和至少一个从节点，所述至少一个从节点保持与所述主节点的数据同步；提取单元，用于当监控到所述主节点的状态异常时，从所述至少一个从节点中选择从节点作为当前主节点；同步单元，用于添加第一备用节点至所述数据库集群，将所述当前主节点的数据同步至所述第一备用节点；替换单元，用于在将所述当前主节点的数据同步至所述第一备用节点之后，将所述第一备用节点作为所述数据库集群的主节点。

根据本申请实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的数据容灾方法。

在本申请的一些实施例所提供的技术方案中，当数据库集群内的主节点的状态异常时，可选择任一状态正常的从节点替代状态异常的节点，从而有效地缩短容灾方案的服务恢复时间，同时，备用节点在数据同步过程中，可获取状态异常节点的全部数据，保持了数据的一致性。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了可以应用于本申请实施例的技术方案的一个示例性系统架构的示意图。

图2示出了可以应用于本申请实施例的技术方案的一个示例性系统架构的示意图。

图3示出了可以应用于本申请实施例的技术方案的一个示例性系统架构的示意图。

图4示出了可以应用于本申请实施例的技术方案的一个示例性系统架构的示意图。

图5示出了根据本申请的一个实施例的数据容灾方法的流程图。

图6示出了根据本申请的一个实施例的客户端路由切换示意图。

图7示出了根据本申请的一个实施例的数据同步示意图。

图8示出了根据图5所对应实施例示出的对步骤S10进行描述的另一流程图。

图9示出了根据图5所对应实施例示出的对步骤S10进行描述的另一流程图。

图10示出了根据本申请的一个实施例的数据容灾装置的框图。

图11示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面 。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

需要说明的是，本申请中所涉及的各集群中的节点可以是服务器也可以是终端。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN（Content Delivery Network，内容分发网络）、以及大数据和人工智能平台等基础云计算服务的云服务器。客户端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

目前，是通过数据容灾以防止数据丢失，通过对操作系统的实时数据块复制，即在数据库写入数据后立即同步到备用的存储设备中，若数据库崩溃，系统可以直接激活备用的存储设备，启动新的数据库服务，实现容灾切换。或，通过数据库主从复制，即系统采用一个主库和多个从库方式，其原理主要是基于日志的主从复制，主库操作以日志的形式发送给各个从库，从库接收到日志后进行数据备份，采用数据库主从复制，一个主库可以连接多个从库，能方便地实现读写分离，同时，每个备库都在运行中，备库里面的数据均为热数据，能够实现快速的容灾切换。但这两种方式均具有缺陷，例如，对操作系统的实时数据块复制的方法中，若系统只有一个数据副本提供服务，无法实现读写分离，另外，若系统崩溃，主库进程中断，容灾切换后需要在崩溃的数据库上做数据库崩溃恢复，系统需要的容灾恢复时间较长，而在数据库主从复制的方法中，进行容灾切换时，从库一定要同步完最新数据以后才能升级为主库，否则极有可能发生数据丢失的情况。

图1示出了可以应用本申请实施例的技术方案的示例性系统架构的示意图。

如图1所示，系统架构包括监控集群、数据库集群和备用集群，其中，监控集群包括多个服务器，用于对数据库集群中各个节点的状态进行监控，并将监控结果进行上报。数据库集群包括主节点和至少一个从节点，主节点用于根据数据处理请求进行数据处理，比如，进行数据的读或写等操作；而从节点可以提供“读”的功能，从节点可以通过数据同步的方式对主节点中的数据进行备份，其原理比如可以是基于日志的主从复制，主节点操作以日志的形式发送给各个从节点，从节点接收到日志后进行数据备份，备用数据库集群包括有多个备用节点，备用节点用于替换数据库集群内状态异常的主节点或从节点。

在本申请的一个实施例中，若监控到数据库集群中的主节点的状态异常，则将主节点作为异常节点进行上报，然后从数据库集群中选择一个状态正常的从节点来作为当前主节点，并且客户端也需要将路由从异常主节点切换至当前主节点或者其他状态正常的从节点。其后，从备用数据库集群中提取备用节点，将备用节点添加至数据库集群内，通过数据同步的方式将当前主节点中的数据备份至备用节点，当数据同步完成之后，以备用节点作为新的主节点，而作为当前主节点的从节点降为从节点。

在本申请的一个实施例中，如图2所示，监控集群是将异常节点上报至接收模块，并通过接收模块通知客户端进行路由的切换处理，即断开与状态异常的节点的连接，并向状态正常的节点发起访问。其中，接收模块内设置有Zookeeper，Zookeeper作为分布式应用程序协调服务，可协调数据库集群、监控集群及备用数据库集群的运作。

在本申请的一个实施例中，若监控到数据库集群中从节点状态异常，将该从节点作为异常节点进行上报，客户端将路由从异常从节点切换至其他状态正常的从节点，并以切换后的状态正常的从节点作为当前从节点，在此之前、同时或者其后，从备用数据库集群中提取备用节点，将备用节点添加至数据库集群内，通过数据同步的方式将当前从节点中的数据备份至备用节点，以备用节点作为新的从节点。

应当理解，图1和图2中被监控的数据库集群的数目仅仅是示意性的，可根据实际需要，通过监控集群实现对多个数据库集群的监控。

在本申请的一个实施例中，如图3所示，监控集群对多个相互之间保持数据同步的数据库集群进行监控（如数据库集群1和数据库集群2），若监控到多个数据库集群中存在有状态异常的数据库集群，将状态异常的数据库集群进行上报，客户端则将路由从状态异常的数据库集群切换至其他状态正常的数据库集群，待状态异常的数据库集群恢复正常后，将数据同步至恢复正常的数据库集群。

在本申请的一个实施例中，基于前述方案，数据库集群1和数据库集群2间的数据同步是通过同步集群来实现的，如图4所示，其中，各个数据库集群包含有主节点和至少一个从节点，同步集群内包含有多个同步机，当客户端修改数据库集群中的数据时，即数据库集群的主节点执行“写”的操作时，主节点除了将写入的数据同步至数据库集群中的从节点，还将写入的数据同步至同步集群，并由同步集群将数据库集群中写入的数据转发至数据库集群的主节点，进一步地，数据库集群的主节点接收到数据库集群写入的数据后，将写入的数据同步给从节点。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

图5示出了根据本申请的一个实施例的数据容灾方法的流程图，参照图5所示，该方法包括：

步骤S10、对数据库集群内的各个节点进行监控，数据库集群包括主节点和至少一个从节点，至少一个从节点保持与主节点的数据同步；

步骤S20、当监控到主节点的状态异常时，从至少一个从节点中选择从节点作为当前主节点；

步骤S30、添加第一备用节点至数据库集群，将当前主节点的数据同步至第一备用节点；

步骤S40、在将当前主节点的数据同步至第一备用节点之后，将第一备用节点作为数据库集群的主节点。

下面对这些步骤进行详细描述。

在步骤S10中，对数据库集群内的各个节点进行监控，数据库集群包括主节点和至少一个从节点，至少一个从节点保持与主节点的数据同步。

在本申请的一个实施例中，这些节点可以部署在同一机房中，也可以部署在不同机房中，可以位于同一区域，也可以是位于不同区域。

在本申请的一个实施例中，对数据库集群的监控可以是通过监控集群实现，监控集群内包括有多个用于监控的服务器，监控的数据库集群包括主节点和至少一个从节点，从节点与主节点之间通过数据同步的方式将主节点内的数据同步至从节点。

继续参见图5，在步骤S20中，当监控到主节点的状态异常时，从至少一个从节点中选择从节点作为当前主节点。

在本申请的一个实施例中，当监控到主节点的状态异常，即主节点的状态为不可读或不可写，或是主节点的状态为不可读且不可写，则将一状态正常的从节点作为当前主节点，并将客户端路由从状态异常的主节点切换至当前主节点，路由切换过程可参见图6，其中，若客户端接收到切换路由通知，将路由从状态异常的主节点切换至状态正常的从节点，并将该状态正常的从节点作为当前主节点。

在本申请的一个实施例中，基于前述方案，在将一状态正常的从节点作为当前主节点的过程中，若数据库集群内从节点均状态正常，则可以直接选择任一从节点作为当前主节点，若数据库集群内从节点也存在有状态异常的目标从节点，则需剔除状态异常的从节点，然后将任一状态正常的从节点作为当前主节点，本实施例中，如果直接将任一状态正常的从节点作为当前主节点，则不需要对从节点进行筛选，这样节省了从多个状态正常的从节点中筛选出适合条件的从节点作为当前主节点的时间，有效缩短了该容灾方案的服务恢复的时间。可选地，在将状态正常的从节点作为当前主节点时，也可以根据从节点的负载、实时网络状态等进行选择，比如可以选择一个状态正常、且负载较小的从节点作为当前主节点。

继续参见图5，在步骤S30中，添加第一备用节点至数据库集群，将当前主节点的数据同步至第一备用节点。

在本申请的一个实施例中，添加至数据库集群的第一备用节点来自备用数据库集群，备用数据库集群内包括多个备用节点，在本实施例中，当前主节点的数据同步至第一备用节点的数据包括前述状态异常的主节点发生异常前同步至当前主节点的数据，以及当前主节点在第一备用节点添加至数据库集群前的窗口时间内接收的来自客户端的请求，数据同步过程可参见图7，其中，待第一备用节点添加至数据库集群，并接收到当前主节点同步的数据后，客户端将主节点从当前主节点切换至备用节点，以备用节点作为新的主节点。

进一步地，在步骤S40中，在将当前主节点的数据同步至第一备用节点之后，将第一备用节点作为数据库集群的主节点。

在本申请的一个实施例中，将当前主节点的数据同步至第一备用节点之后，以第一备用节点作为数据库集群新的主节点，同时，将当前主节点降为从节点，在本实施例中，由于主节点状态异常，添加至数据库集群的第一备用节点可以充当主节点执行读写功能，因此，数据库集群内可执行读写操作的主节点和执行“读”操作的从节点的数量未发生变化。

需要注意的是，从读写分离的角度考虑时，主节点可以是具有读写功能的节点，从节点可以是仅具有“读”的功能，由于从节点作为当前主节点的时间非常短暂，可忽略从节点不具有“写”的功能所带来的影响。当然，在本申请的其它实施例中，主节点和从节点都可以是具有“读”的功能和“写”功能的节点。

在本申请的一个实施例中，如图8所示，图5所示步骤S10具体包括：

步骤S11、分别对数据库集群内各个节点进行周期性访问；

步骤S12、根据周期性访问的结果，确定节点的状态，节点的状态包括异常和正常。

在本申请的一个实施例中，考虑到影响节点的运行状况的因素有多种，包括：节点宕机无法提供服务；由于网络抖动和网络故障导致节点与监控集群之间通信中断；节点高负载运作对接收的请求响应缓慢等。以上几种情况中，由于网络抖动和网络故障导致节点与监控集群之间通信中断，和节点高负载运作对接收的请求响应缓慢，均属于节点能够重新恢复至正常状况的类型，例如，当网络恢复正常后，节点与监控集群之间通信重新连接，或，当节点由高负载运作转为正常负载运作后，节点对接收的客户端的请求响应恢复正常，即恢复为状态正常的节点，因此，需要将能够短期恢复的故障与节点宕机进行区分。

在本申请的一个实施例中，根据周期性访问的结果，确定节点的状态，包括：若主节点在预定的时间段内均为不可读和/或不可写，则确定主节点的状态异常；若至少一个从节点中的目标从节点在预定的时间段内不可读，则确定目标从节点的状态异常。

可理解的是，监控集群对数据库集群内各个节点的周期性访问是持续性的，本实施例中，若主节点在预定的时间段内为不可读和不可写，或不可读，或不可写，则确定主节点的状态异常，仅有主节点在预定的时间段内为可读且可写，才可确定主节点的状态正常，其中，预定的时间段不超过5秒，可根据实际需求对预定的时间段进行设置。

进一步地，主节点在预定的时间段内为可读且可写，可分为主节点在预定的时间段均为可读且可写，及主节点在预定的时间段内间断性的可读且可写，若主节点在预定的时间段内均为可读且可写，则确定为状态正常，若主节点在预定的时间段内间断性的可读且可写，即在某时间段内主节点为不可读和不可写，或不可读，或不可写，而在另一时间段内恢复为可读且可写，例如，由于网络抖动和网络故障，导致节点与监控集群之间通信中断，在一段时间内主节点为不可读且不可写，或不可读，或不可写，其后，网络抖动和网络故障得以解决，主节点又恢复为可读且可写，则可将由于网络抖动和网络故障，导致节点与监控集群之间短暂的通信中断视为正常状况，确定主节点状态正常，或，主节点高负载运作，在某时间段内对接收的请求响应缓慢，为短暂的不可读和不可写，或短暂的不可写，或短暂的不可读，其后，主节点由高负载运作转为正常负载运作，主节点对接收的请求响应正常，恢复为可读且可写状态，则将暂时的高负载运作导致的不可读和不可写，或不可写，或不可读视为正常状况，确定主节点状态正常。

在本申请的一个实施例中，如图9所示，图5所示步骤S10具体包括：

步骤S13、接收数据库集群内各个节点的上报数据；

步骤S14、根据上报数据，确定节点的状态，节点的状态包括异常和正常。

在本实施例中，可通过向数据库集群发送心跳包的方式，对数据库集群内各个节点进行周期性访问，从而接收数据库集群内各个节点的上报数据，根据预定的时间段内接收的各个节点的上报数据，确定各个节点的状态异常或正常。

在本申请的一个实施例中，还可以在若监控到至少一个从节点中存在状态异常的目标从节点，添加第二备用节点至数据库集群；然后，将目标从节点节点的数据同步至第二备用节点，在将目标从节点的数据同步至第二备用节点之后，将第二备用节点作为数据库集群的从节点。

本实施例中，若监控到数据库集群中存在状态异常的目标从节点，将任一状态正常的其他从节点作为当前从节点，当前从节点可代替目标从节点与数据库集群内主节点进行数据同步，其后，从备用数据库中提取第二备用节点，并添加至数据库集群内，将目标从节点的数据同步至第二备用节点，其中，目标从节点的数据包括状态异常之前目标从节点的数据，以及当前从节点替代目标从节点与数据库集群内主节点进行数据同步的数据。

在本申请的一个实施例中，当数据库集群为多个，数据库集群之间保持数据同步，该数据容灾方法还包括：若监控的多个数据库集群中存在状态异常的目标数据库集群，从状态正常的其他数据库集群中筛选出备用数据库集群，以备用数据库集群替代状态异常的目标数据库集群响应客户端发送给状态异常的目标数据库集群的请求消息，状态异常的目标数据库集群为不能响应客户端请求的数据库集群。

具体地，比如数据库集群1中包含有主节点A和多个从节点（例如，从节点B、从节点C），数据库集群2中包含有主节点X和多个从节点（例如，从节点Y、从节点Z），同步集群内包括多个同步机（例如，同步机1和同步机2 ），当客户端修改数据库集群1中的数据时，即主节点A执行“写”的操作时，主节点A除了将写入的数据同步至数据库集群1中的从节点B和从节点C，还将写入的数据同步至同步集群，并由同步集群将写入的数据转发至数据库集群2的主节点X，进一步地，在数据库集群2中，写入的数据由主节点X同步给从节点Y和从节点Z。

在本实施例中，以数据库集群1和数据库集群2为例，,若监控的数据库集群1状态异常，则直接将客户端的路由从数据库集群1切换至数据库集群2。

在本申请的一个实施例中，还可以在若状态异常的目标数据库集群的状态恢复正常，则将备用数据库集群替代状态异常的目标数据库集群获取的数据同步至状态恢复正常的数据库集群；然后，在同步完成之后，通过状态恢复正常的数据库集群对客户端发送的请求进行响应。

在本申请的一个实施例中，以备用数据库集群替代状态异常的目标数据库集群响应客户端发送给状态异常的目标数据库集群的请求消息之后，若状态异常数据库集群恢复为状态正常的数据库集群，通过同步集群，将备用数据库集群替代状态异常的目标数据库集群获取的数据同步至状态正常的数据库集群，通过该状态正常的数据库集群响应客户端请求。

在本实施例中，当异常数据库集群恢复为状态正常的数据库集群，备用数据库集群将数据库集群从异常恢复至正常的窗口期所写的数据，同步至同步集群，并通过同步集群将该数据传送至状态恢复正常的数据库集群中。例如，当前述的状态异常的数据库集群1恢复为状态正常的数据库集群，数据库集群2将在数据库集群1的恢复窗口期内所写的数据，同步至同步集群，其后，通过同步集群将该数据传送至数据库集群1。

在本申请的一个实施例中，从状态正常的其他数据库集群中筛选出备用数据库集群，包括：

分别获取状态正常的数据库集群与状态异常的目标数据库集群的相隔距离，以与状态异常的目标数据库集群相隔距离最小的状态正常的数据库集群作为备用数据库集群。

在本实施例中，以地域集群为例进行说明，当监控的多个数据库集群分别为深圳数据库集群、广州数据库集群、上海数据库集群和北京数据库集群，当深圳数据库集群出现故障，分别获取广州数据库集群、上海数据库集群和北京数据库集群与出现故障的深圳数据库集群的相隔距离，明显可看出，广州数据库集群与出现故障的深圳数据库集群的相隔距离最小，因此，可优先选择广州数据库集群作为出现故障的深圳数据库集群的备用数据库集群，以提供正常的服务。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的数据容灾方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的图像处理方法的实施例。

图10示出了根据本申请的一个实施例的数据容灾装置的框图，参照图10所示，根据本申请的一个实施例的数据容灾装置800，包括：监控单元810、提取单元820、同步单元830和替换单元840。

其中，监控单元810，用于对数据库集群内的各个节点进行监控，数据库集群包括主节点和至少一个从节点，至少一个从节点保持与主节点的数据同步。

提取单元820，用于当监控到主节点的状态异常时，从至少一个从节点中选择从节点作为当前主节点；

同步单元830，用于添加第一备用节点至数据库集群，将当前主节点的数据同步至第一备用节点；

替换单元840，用于在将当前主节点的数据同步至第一备用节点之后，将第一备用节点作为数据库集群的主节点。

图11示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图11示出的电子设备的计算机系统1600仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图11所示，计算机系统1600包括中央处理单元（Central Processing Unit，CPU）1601，其可以根据存储在只读存储器（Read-Only Memory，ROM）1602中的程序或者从储存部分1608加载到随机访问存储器（Random Access Memory，RAM）1603中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 1603中，还存储有系统操作所需的各种程序和数据。CPU 1601、ROM 1602以及RAM 1603通过总线1604彼此相连。输入/输出（Input /Output，I/O）接口1605也连接至总线1604。

以下部件连接至I/O接口1605：包括键盘、鼠标等的输入部分1606；包括诸如阴极射线管（Cathode Ray Tube，CRT）、液晶显示器（Liquid Crystal Display，LCD）等以及扬声器等的输出部分1607；包括硬盘等的储存部分1608；以及包括诸如LAN（Local AreaNetwork，局域网）卡、调制解调器等的网络接口卡的通信部分1609。通信部分1609经由诸如因特网的网络执行通信处理。驱动器1610也根据需要连接至I/O接口1605。可拆卸介质1611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1610上，以便于从其上读出的计算机程序根据需要被安装入储存部分1608。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分1609从网络上被下载和安装，和/或从可拆卸介质1611被安装。在该计算机程序被中央处理单元（CPU）1601执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（Erasable Programmable Read Only Memory，EPROM）、闪存、光纤、便携式紧凑磁盘只读存储器（Compact Disc Read-Only Memory，CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在的，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。

本申请的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的数据容灾方法。

上述内容，仅为本申请的较佳示例性实施例，并非用于限制本申请的实施方案，本领域普通技术人员根据本申请的主要构思和精神，可以十分方便地进行相应的变通或修改，故本申请的保护范围应以权利要求书所要求的保护范围为准。