CN105262633A - 一种应用级容灾方法及应用级容灾系统 - Google Patents
一种应用级容灾方法及应用级容灾系统 Download PDFInfo
- Publication number
- CN105262633A CN105262633A CN201510847343.6A CN201510847343A CN105262633A CN 105262633 A CN105262633 A CN 105262633A CN 201510847343 A CN201510847343 A CN 201510847343A CN 105262633 A CN105262633 A CN 105262633A
- Authority
- CN
- China
- Prior art keywords
- application
- cluster
- terminal
- database
- abnormal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Hardware Redundancy (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请提供了一种应用级容灾方法及应用级容灾系统,方法部署在每个数据中心,包括:HAProxy集群的主控终端在判定应用集群中出现连接异常的应用终端数量大于第一预设数量的情况下,确定所述应用集群出现连接异常,并推送所述应用集群出现连接异常的通知;应用集群的主控终端在判定数据库集群中出现连接异常的数据库数量大于第二预设数量的情况下,确定所述数据库集群出现连接异常,并推送所述数据库集群出现连接异常的通知。本申请可以实现准确确定故障位置的目的。由于本申请可以准确故障位置,因此,在进行数据中心切换时,便可以在故障位置处进行切换,而无需对整体数据中心进行切换。
Description
技术领域
本申请涉及网络技术领域,尤其涉及一种基于多中心的系统应用级容灾方法。
背景技术
近年来,计算机网络系统迅速发展。但是由于自然灾害、设备故障或人为因素等原因,可能会导致计算机网络系统信息数据丢失和业务处理中断,这对计算机网络系统会造成严重损害。因此,目前计算机网络系统上增加数据灾备策略。数据灾备策略的核心思想为:建设多套平行系统,在一套系统出现意外情况时,可以切换到另一套系统,以保证计算机网络系统不受影响。
目前,实现数据灾备策略的一种方式为:在应用级容灾系统中具有多个数据中心,每个数据中心的集群配置和运行应用完全一致,在一个数据中心出现故障情况下可以实现数据中心之间的切换。每个数据中心均包括网络层F5负载均衡器、HAProxy集群、应用集群以及数据库集群。当一个中心的上述系统出现连接异常时,可以切换到另一中心,从而保证系统运行不受影响。但是,现有的多中心灾备方案不能够确定故障的位置,例如,不能确定是应用集群发生故障,还是确定数据库集群发生故障。因此在一个数据中心出现连接异常时,只能在数据中心级别进行切换。例如,在A数据中心发生故障时,便将交易请求从用户到A数据中心的网络层设备F5负载均衡器的路径,切换到用户到B中心的网络层设备F5负载均衡器的路径,即将A数据中心整体切换。
因此,现在需要一种可以准确的故障位置的方法,以便可以针对故障点进行灾备切换,而不是将数据中心整体进行灾备切换。
发明内容
本申请提供了一种应用级容灾方法及应用级容灾系统,本申请可以准确确定故障位置,以便可以针对故障点进行灾备切换,而不是将数据中心整体进行灾备切换。
为了实现上述目的,本申请提供了以下技术手段:
一种应用级容灾方法,应用于应用级容灾系统中的每个数据中心,所述数据中心包括位于网络层到应用层的HAProxy集群,以及位于应用层到数据库层的应用集群,所述方法包括:
HAProxy集群的主控终端在判定应用集群中出现连接异常的应用终端数量大于第一预设数量的情况下,确定所述应用集群出现连接异常,并推送所述应用集群出现连接异常的通知;
应用集群的主控终端在判定数据库集群中出现连接异常的数据库数量大于第二预设数量的情况下,确定所述数据库集群出现连接异常,并推送所述数据库集群出现连接异常的通知。
优选的,应用集群中的应用终端出现连接异常的确定过程,包括:
所述HAProxy集群中的主控终端接收HAProxy集群中各个HA终端发送的连接状态信息;其中,每个连接状态信息均包含一个HA终端与所有应用终端的连接状态;若HA终端与应用终端的心跳检测正常,则连接状态为正常,若HA终端与应用终端的心跳检测异常,则连接状态为连接异常;
所述HAProxy集群中的主控终端在分析后得知多个连接状态信息均表示一个应用终端连接状态为连接异常情况下,确定该应用终端出现连接异常,进而判断其故障。
优选的,在推送所述应用集群出现连接异常的通知之后,可自动实现该层级的中心间切换,具体包括:
所述HAProxy集群中的主控终端向各个HA终端发送更换配置文件指令,所述更换配置文件指令包括配置文件标识,该配置文件用于设定HAProxy集群中的每个HA终端的交易转发地址,配置文件标识指定要转发的中心,一旦更换配置文件,该中心的HAProxy集群会将交易请求转发给其他中心的应用集群进行处理;
其中,所述各个中心的配置文件可被各个HA终端预先存储,根据配置文件标识确定对应的配置文件,并且将所述应用集群的配置文件,更换为与所述配置文件标识对应的配置文件。
优选的,数据库集群中的数据库出现连接异常的确定过程,包括:
所述应用集群中的主控终端接收各个应用终端发送的第一连接异常连接状态信息;其中,每个第一连接异常连接状态信息至少包括出现连接异常的数据库标识;若应用终端在weblogic运行日志中检测到数据库连接错误关键字,则确定与数据库连接错误关键字对应的数据库标识,并将该数据库标识对应的数据库为连接异常数据库;
所述应用集群中的主控终端在分析后得知多个连接异常连接状态信息均表示一个数据库标识对应的数据库的连接状态为连接异常情况下,确定该数据库出现连接异常。
优选的,数据库集群中的数据库出现连接异常的确定过程,包括:
所述应用集群中的主控终端接收各个应用终端发送的第二连接异常连接状态信息;其中,每个第二连接异常连接状态信息至少包括出现连接异常的数据库标识;若应用终端在系统错误日志中检测到数据库标识,则该数据库标识对应的数据库为连接异常数据库;
所述应用集群中的主控终端在分析后得知多个连接异常连接状态信息均表示一个数据库标识对应的数据库的连接状态为连接异常情况下,确定该数据库出现连接异常。
优选的,数据库集群中的数据库出现连接异常的确定过程,包括:
所述应用集群中的主控终端接收各个应用终端发送的第三连接异常连接状态信息;其中,每个第三连接状态信息至少包括出现连接异常的数据库标识;若应用终端在weblogic运行日志中检测到连接错误关键字,则确定与数据库连接错误关键字对应的数据库标识所对应的第一时间,与应用终端在系统错误日志中检测到同一数据库标识的第二时间一致,则确定该数据库标识对应的数据库为连接异常数据库。
优选的,在推送所述数据库集群出现连接异常的通知之后,还包括:
所述应用集群中的主控终端向各个应用终端发送更换URL地址指令,所述更换URL地址指令包括URL地址标识;
其中,所述各个数据中心的URL地址可被应用集群预先存储,根据URL地址标识确定对应的URL地址,并且将所述数据库集群的URL地址,更换为与所述URL地址标识对应的URL地址。
一种应用级容灾系统,包括:多个数据中心;
每个数据中心,用于执行所述应用级容灾方法。
通过以上技术内容,可以看出本申请具有以下有益效果:
本申请提供了一种应用级容灾方法,本方法在HAProxy集群上布设检测故障程序,从而可以实现检测应用集群是否出现连接异常;并且在应用层到数据库层的应用集群上也设有检测故障程序,从而可以实现检测数据库集群是否出现连接异常。因此,本申请可以实现准确确定故障位置的目的。由于本申请可以准确故障位置,便于后续的故障恢复工作,同时在进行数据中心切换时,可以在故障位置处进行切换,而无需对整体数据中心进行切换。
本申请可以在故障位置进行切换,而不需在网络层进行整体数据中心切换(即用户至F5负载均衡器的路径),因此提高数据中心的可用性,减少了资源浪费。并且,由于无需在用户连接处进行切换,所以本申请不需要用户的配合,进而提高切换的可行性。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例公开的一种应用级容灾系统的结构示意图;
图2为本申请实施例公开的又一种应用级容灾系统的结构示意图;
图3为本申请实施例公开的又一种应用级容灾系统的结构示意图;
图4为本申请实施例公开的一种应用级容灾方法的流程图;
图5为本申请实施例公开的又一种应用级容灾方法的流程图;
图6为本申请实施例公开的又一种应用级容灾方法的流程图;
图7为本申请实施例公开的又一种应用级容灾方法的流程图;
图8为本申请实施例公开的又一种应用级容灾方法的流程图;
图9为本申请实施例公开的又一种应用级容灾方法的流程图;
图10为本申请实施例公开的又一种应用级容灾方法的流程图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在介绍本申请实施例之前,首先介绍一种基于多中心部署的应用级容灾系统,以方便本领域技术人员更容易理解本申请实施例的应用场景。如图1所示,该系统部署在多个数据中心。为了清楚表示多个数据中心,采用数据中心1、数据中心2……数据中心N表示;其中,N为大于1的自然数。
其中,每个数据中心包括F5负载均衡器、HAProxy集群11、应用集群12以及数据库集群13。F5负载均衡器属于网络设备,商户接入F5负载均衡器,F5负载均衡器连接后端HAProxy集群,对商户的交易请求进行均匀分发。每个数据中心的每套系统分有两台专属F5负载均衡器,一主一备。在F5负载均衡器中进行设置,把不同商户的交易请求路由到不同的HA终端。
HAProxy集群11由多个安装有HAProxy软件的HA终端组成,主要用于接收用户的交易请求并实现负载均衡。应用集群12由安装有应用程序的多个应用终端组成,主要用于处理用户的交易请求。数据库集群13由安装了数据库软件的多个数据库终端组成,用于存储数据信息。数据库以实例分库,通常两台数据库终端以RAC方式运行一个数据库实例,在一台终端损坏时仍能保证数据库的可用性。。应用集群12在处理用户的交易请求时,会不断进行数据库更新操作。
上述应用级容灾系统实现的功能为:用户向F5负载均衡器发送交易请求,F5负载均衡器将交易请求均匀分发给HAProxy集群11的某一个HA终端,该HA终端轮询应用集群12中的各个应用终端,确定出可以处理交易请求应用终端,然后将交易请求发送至该应用终端。应用终端按照业务逻辑处理交易请求,并与数据库集群13中的数据库进行数据交互,完成数据更新的任务。
参见图2,为HAProxy集群11与应用集群12的连接关系图。下面具体介绍HAProxy集群11与应用集群12的具体连接情况:
HAProxy集群11可以包括多个HA终端,在图3采用HA终端1、HA终端2……HA终端L表示多个HA终端;其中,L为非零自然数。并且,在多个HA终端中有一个主控终端(例如,在图3中的HA终端2,当然,HAProxy集群11的主控终端可以是其它HA终端),HAProxy集群中的任意两台HA终端通过无线网络相连,HAProxy集群11的主控终端必然与所有HA终端相连,用于控制所有HA终端。
应用集群13可以包含多个应用终端;在图3中采用应用终端1、应用终端2……应用终端M表示,M为非零自然数。一个HA终端与所有应用终端均相连,即一个应用终端与所有HA终端均相连。本申请中HA终端的数量L和应用终端的数量M依据具体情况而定,在此不做限定。
参见图3,为应用集群12与数据库集群13的连接关系图。下面具体介绍应用集群12与数据库集群13的具体连接情况:
如上所述,应用集群13可以包含多个应用终端;在图4中仍然采用应用终端1、应用终端2……应用终端M表示,M为非零自然数。并且,在多个应用终端中有一个主控终端(例如,在图4中的应用终端2,当然,应用集群的主控终端可以是其它应用终端),应用集群中的任意两台应用终端可以通过无线网络相连,应用集群12的主控终端必然与所有应用终端相连,用于控制所有应用终端。
数据库集群13中有多个数据库,在图4中采用数据库1、数据库2……数据库K表示,K为非零自然数。在实际应用中,数据库可以承载在终端上,例如,两个终端以RAC方式实现一个数据库实例,可在一台终端不可用的情况下保证交易不受影响。一个应用终端与所有数据库均相连,即一个数据库与所有应用终端均相连。本申请中数据库数量K依据具体情况而定,在此不做限定。
在图1所示应用级容灾系统中,多个数据中心中任意两个数据中心之间可以实现灾备切换。例如,数据中心1切换到数据中心2,数据中心3切换到数据中心1等。
本方案只讨论应用集群或数据库集群出现故障的情况。在应用集群出现连接异常之后,其外在表现为HAProxy集群与应用集群连接连接异常。因此,本申请设想通过HAProxy集群与应用集群连接是否连接异常,来确定应用集群是否出现连接异常。在数据库集群出现连接异常之后,其外在表现为应用集群与数据库集群连接连接异常。因此,本申请设想通过应用集群与数据库集群连接是否连接异常,来确定数据库集群是否出现连接异常。
基于图1-3所示的应用级容灾系统,本申请提供了一种基于多中心系统的应用级容灾方法,来准确判定故障位置。如图4所示,本方法具体包括以下步骤:
步骤S401:HAProxy集群的主控终端在判定应用集群中出现连接异常的应用终端数量大于第一预设数量的情况下,确定所述应用集群出现连接异常,并推送所述应用集群出现连接异常的通知。
参见图2或图3,应用集群有M个应用终端。由于应用集群中有多个应用终端,因此,在少量应用终端出现连接异常时,不会影响应用集群执行交易请求。当应用集群中有大量应用终端出现连接异常时,会影响应用集群执行交易请求。
因此,本申请由技术人员在HAProxy集群的主控终端中设置一个第一预设数量,当应用集群中出现连接异常的应用终端的数量达到第一预设数量时,则表示应用集群出现连接异常。第一预设数量小于应用集群中应用终端的总数量M。例如,在应用集群中有5个应用终端时,第一预设数量可以为3。第一预设数量的具体值与具体情况有关,在此不做限定。
HAProxy集群的主控终端可以确定一个应用终端是否出现连接异常,从而统计出现连接异常的应用终端数量。当出现连接异常的应用终端数量达到第一预设数量之后,确定应用集群出现连接异常。
在应用集群出现连接异常之后,HAProxy集群的主控终端可以推送应用集群出现连接异常。具体推送方式可以以短信方式推送,或者以消息方式推送,或者其它方式推送,在此不限定HAProxy集群的主控终端推送应用集群出现连接异常的推送方式。步骤S402:应用集群的主控终端在判定数据库集群中出现连接异常的数据库数量大于第二预设数量的情况下,确定所述数据库集群出现连接异常,并推送所述数据库集群出现连接异常的通知。
参见图3,数据库集群有K个数据库。由于数据库集群中有多个数据库,因此,在少量数据库出现连接异常时,不会影响数据库集群执行更新数据的任务。当数据库集群中有大量数据库出现连接异常时,会响应数据库执行更新数据的任务。
因此,本申请由技术人员在应用集群的主控终端中设置一个第二预设数量,当数据库集群中出现连接异常的数据库的数量达到第二预设数量时,则表示数据库集群出现连接异常。第二预设数量小于数据库集群中数据库的总数量K。例如,在应用集群中有3个数据库时,第二预设数量可以为2。第二预设数量的具体值与具体情况有关,在此不做限定。
应用集群的主控终端可以确定一个数据库是否出现连接异常,从而统计出现连接异常的数据库数量。当出现连接异常的数据库数量达到第二预设数量之后,确定数据库集群出现连接异常。
在数据库集群出现连接异常之后,HAProxy集群的主控终端可以推送数据库集群出现连接异常。具体推送方式可以以短信方式推送,或者以消息方式推送,或者其它方式推送,在此不限定应用集群的主控终端推送数据库集群出现连接异常的推送方式。从以上技术内容可以看出,本申请具有以下有益效果:
本申请提供了一种基于多中心部署系统的应用级容灾方法,本方法在HAProxy集群上布设检测故障程序,从而可以实现检测应用集群是否出现连接异常;并且在应用层到数据库层的应用集群上也设有检测故障程序,从而可以实现检测数据库集群是否出现连接异常。因此,本申请可以实现准确确定故障位置的目的。由于本申请可以准确故障位置,便于后续的故障恢复工作,同时在进行数据中心切换时,可以在故障位置处进行切换,而无需对整体数据中心进行切换。
本申请可以在故障位置进行切换,而不需在用户端进行整体数据中心切换,因此提高数据中心的可用性,减少了资源浪费。并且,由于无需在用户处进行切换,所以本申请不需要用户的配合,进而提高切换的可行性。
下面介绍步骤S401中HAProxy集群的主控终端确定一个应用终端出现连接异常的过程。如图5所示,具体包括以下步骤:
步骤S501:所述HAProxy集群中的主控终端接收各个HA终端发送的连接状态信息;其中,每个连接状态信息均包含一个HA终端与所有应用终端的连接状态;若HA终端与应用终端的心跳检测正常,则连接状态为正常,若HA终端与应用终端的心跳检测连接异常,则连接状态为连接异常。
以HAProxy集群中的一个HA终端为例,对HA终端获得连接状态信息的过程进行详细描述:
为了检测每个应用终端是否正常,HA终端可以以心跳检测的方式,检测HA终端与每个应用终端的连接状态是否正常。若HA终端与一个应用终端的连接状态正常,则表明该应用终端正常;若HA终端与一个应用终端的连接状态连接异常,则表明该应用终端出现连接异常。
HA终端通过心跳检测的方式可以获得自身与各个应用终端的连接状态,然后,将自身与各个应用终端的连接状态,作为连接状态信息发送至HAProxy集群的总控终端。
步骤S502:所述HAProxy集群中的主控终端在分析后得知多个连接状态信息均表示一个应用终端连接状态为连接异常情况下,确定该应用终端出现连接异常。
HA-proxy集群的总控终端可以接收各个HA终端发送的连接状态信息。每个连接状态信息中均包含一个HA终端与各个应用终端之间的连接状态。
参见表1,为HAProxy集群的总控终端接收的连接状态信息的实例。
表1
应用终端1 | 应用终端2 | …… | 应用终端M | |
HA终端1连接状态信息 | 连接异常 | 正常 | 连接异常 | |
HA终端2的连接状态信息 | 连接异常 | 正常 | 正常 | |
…… | …… | …… | …… | …… |
HA终端L的连接状态信息 | 连接异常 | 正常 | 正常 |
HAProxy集群的总控终端的接收各个HA终端发送的连接状态信息后,分析各个连接状态信息,并在多个连接状态信息均表示一个应用终端出现连接异常时,确定该应用终端出现连接异常。例如,参见表1,多个连接状态信息均表示应用终端1出现连接异常,则确定应用终端1出现连接异常。
HAProxy集群的总控终端在确定所有出现连接异常的应用终端之后,便可以确定统计得到出现连接异常的应用终端数量。在出现连接异常的应用终端数量大于第一预设数量时,确定应用集群出现连接异常。HAProxy集群的总控终端可以推送应用集群出现连接异常的通知。
一个数据中心的HAProxy集群与应用集群相连,在与HAProxy集群相连的应用集群出现连接异常之后,可以将HAProxy集群与另一数据中心的应用集群相连。由于应用集群出现连接异常之后,系统不一定崩溃,可能还处于工作状态;所以切换过程可以立即启动,以防系统崩溃;也可以在接收技术人员下发的切换指令之后再启动。具体方式可以依据实际情况而定,在此不做限定。参见图1,本申请提供应用级容灾系统包括多个数据中心,多个数据中心之间可以实现灾备切换。以数据中心1为例,为了实现数据中心1的应用集群,可以切换到其它数据中心的应用集群;本申请可以在数据中心1的HAProxy集群的每个HA终端中存储有连接数据中心1的应用集群的配置文件、连接数据中心2的应用集群的配置文件……连接数据中心N的应用集群的配置文件。当然,可以存储连接一部分数据中心的应用集群的配置文件。
每个HA终端的软件程序中设有一个转发地址,转发地址中所存储的应用集群的配置文件,决定HA终端与哪个应用集群连接。例如,数据中心1的HAProxy集群1中,各个HA终端的转发地址中存储的为应用集群1的配置文件;则表示HAProxy集群1与应用集群1相连。在应用集群1出现连接异常时,可以将各个HA终端的转发地址存储的应用集群1的配置文件,替换为其它应用集群的配置文件;以便HAProxy集群1可以连接到其它数据中心的应用集群。
下面介绍一个数据中心的应用集群出现连接异常之后,切换到另一数据中心的应用集群的具体过程;即将HAProxy集群中所述应用集群的配置文件,更换为其它应用集群的配置文件的过程。
参见图6,切换应用集群的过程,具体包括以下步骤:
步骤S601:所述HAProxy集群中的主控终端向各个HA终端发送更换配置文件指令,所述更换配置文件指令包括配置文件标识。
由于各个HA终端中存储有多个数据中心的应用集群的配置文件,为了保证各个HA终端所切换的应用集群是一致的。HAProxy集群中的主控终端向各个HA终端发送更换配置文件的指令,并在更换配置文件的指令中,指出需要更换为配置文件的配置文件标识。
步骤S602:各个HA终端在接收所述更换配置文件指令之后,在预先存储的其它应用集群配置文件中,确定与所述配置文件标识对应的配置文件。
各个HA终端在接收更换配置文件指令之后,在预先存储的其它应用集群的配置文件,查找与配置文件标识对应的配置文件。
步骤S603:各个HA终端均将所述应用集群的配置文件,更换为与所述配置文件标识对应的配置文件。
各个HA终端在查找到与配置文件标识对应的配置文件之后,将转发地址对应的应用集群的配置文件,替换为配置文件标识对应的配置文件。即可使本数据中心的HAProxy集群将交易请求发往其他数据中心的应用集群。
下面介绍步骤S402中应用集群的主控终端确定一个数据库出现连接异常的过程。本申请提供三种方式来确定一个数据库出现连接异常,下面对三种方式进行详细介绍:
第一种方式:采用weblogic运行日志。
如图7所示,第一种方式具体包括以下步骤:
步骤S701:所述应用集群中的主控终端接收各个应用终端发送的第一连接异常连接状态信息;其中,每个第一连接异常连接状态信息至少包括出现连接异常的数据库标识;若应用终端在weblogic运行日志中检测到数据库连接错误关键字,则确定与数据库连接错误关键字对应的数据库标识,并将该数据库标识对应的数据库为连接异常数据库。
应用集群的每个应用终端中安装有WLST(weblogicScriptingtools)工具。WLST工具为Weblogic脚本工具,是一个能够进行应用程序服务器配置和远程维护工具。WLST工具能够定时检查weblogic运行日志。当应用终端与数据库连接连接异常时,在weblogic运行日志会记录数据库连接错误关键字以及出现连接异常的数据库标识。
各个应用终端在自身的weblogic运行日志检测到数据库连接错误关键字之后,确定与数据库连接错误关键字对应的数据库标识,将至少包含数据库标识的连接异常连接状态信息,发送至应用集群的主控终端。
步骤S702:所述应用集群中的主控终端在分析后得知多个连接异常连接状态信息均表示一个数据库标识对应的数据库的连接状态为连接异常情况下,确定该数据库出现连接异常。
应用集群的主控终端分析各个连接异常连接状态,在多个连接异常连接状态信息均表示一个数据库标识对应的数据库出现连接异常时,应用集群的主控终端确定该数据库出现连接异常。
第二种方式:采用系统错误日志。
如图8所示,第二种方式具体包括以下步骤:
步骤S801:所述应用集群中的主控终端接收各个应用终端发送的第二连接异常连接状态信息;其中,每个第二连接异常连接状态信息至少包括出现连接异常的数据库标识;若应用终端在系统错误日志中检测到数据库标识,则该数据库标识对应的数据库为连接异常数据库。
应用终端中还具有系统程序,系统程序也会记录错误日志,在应用终端与一个数据库发生写失败或读失败时,会记录在系统错误日志中。应用终端可以在系统错误日志中确定出现连接异常的数据库标识。然后,将至少包括出现连接异常的数据库标识发送至应用程序的主控终端。
步骤S802:所述应用集群中的主控终端在分析后得知多个连接异常连接状态信息均表示一个数据库标识对应的数据库的连接状态为连接异常情况下,确定该数据库出现连接异常。
参见步骤S702,在此不再赘述。
第三种方式:采用weblogic运行日志+系统错误日志。
如图9所示,第三种方式具体包括以下步骤:
步骤S901:应用终端在weblogic运行日志确定出现连接异常的数据库标识,并记录该数据库标识对应的第一时间。
weblogic运行日志中记录有数据库连接错误关键字,与数据库连接错误关键字对应的数据库标识,以及与数据库标识对应的时间。在应用终端检测到数据库连接错误关键字时,则表示与数据库连接错误关键字对应的数据库标识为出现连接异常的数据库,因此,将与数据库标识对应的时间,确定为数据库出现连接异常的第一时间。
步骤S902:在系统错误日志中,查找是否有所述数据库标识对应的记录。如果有,则进入步骤S903,否则进入步骤S906。
理论上,WLST工具检测到数据库出现连接异常后,系统程序也能够检测到数据库出现连接异常。因此,若一个数据库出现连接异常,在weblogic运行日志和系统错误日志上均存在记录,由于同一个数据库发生连接异常的时间是确定的,所以两个日志记录中登记错误记录的也应该是一致的。
步骤S903:在系统错误日志中记录与数据库标识对应的第二时间。
步骤S904:判断第一时间与第二时间是否一致,若一致,则进入步骤S905,若不一致,则进入步骤S906。
若两个日志记录中记录的时间一致,则能准确表示数据库出现连接异常;若两个日志记录中记录的时间不一致,则不能准确表示数据库出现连接异常。
步骤S905:判定数据库标识对应的数据库出现连接异常。
步骤S906:判定数据库标识对应的数据库未出现连接异常。
一个数据中心的应用集群与数据库集群相连,在与HAProxy集群相连的应用集群出现连接异常之后,可以将应用集群与另一数据中心的应用集群相连。由于数据库集群出现连接异常之后,系统不一定崩溃,可能还处于工作状态;所以切换过程可以立即启动,以防系统崩溃;也可以在接收技术人员下发的切换指令之后再启动。具体方式可以依据实际情况而定,在此不做限定。
参见图1,本申请提供应用级容灾系统包括多个数据中心,多个数据中心之间可以实现灾备切换。以数据中心1为例,为了实现数据中心1可以切换到其它数据中心的数据库集群;本申请可以在数据中心1的应用集群的每个应用终端中存储有数据中心1的数据库集群的URL地址、数据中心2的数据库集群的URL地址……数据中心N的数据库集群的URL地址。当然,可以存储一部分数据中心的数据库集群的URL地址。
每个应用终端的软件程序中设有一个转发地址,转发地址中所存储的数据库集群的URL地址,决定应用终端与那个数据库集群连接。例如,数据中心1的应用集群1中,各个应用终端的转发地址中存储的为数据库集群1的URL地址;则表示应用集群1与数据库集群1相连。在数据库集群1出现连接异常时,可以将各个应用终端的转发地址存储的数据库集群1的URL地址,替换为其它数据库集群的URL地址;以便应用集群1可以连接到其它数据中心的数据库集群。
每个应用终端安装weblogic软件作为中间件管理工具,在weblogic控制台中设置数据源URL地址(即数据库实例地址)可以决定连接哪个数据库实例,URL地址可以通过weblogic控制台手动更改,也可以通过WLST工具自动更改。
下面介绍一个数据中心的数据库集群出现连接异常之后,切换到另一数据中心的数据库集群的具体过程;即将应用集群中所述数据库集群的URL地址,更换为其它数据库集群的URL地址的过程。URL地址用于设定应用集群中的每个应用终端连接数据库地址,URL地址标识指定要转发的数据中心,一旦更换URL地址,该数据中心的应用集群将会与其他数据中心的数据库集群进行数据交互。
参见图10,切换数据库集群的过程,具体包括以下步骤:
步骤S1001:所述应用集群中的主控终端向各个应用终端发送更换URL地址指令,所述更换URL地址指令包括URL地址标识。
由于各个应用终端中存储有多个数据中心的数据库集群的URL地址,为了保证各个应用终端所切换的数据库集群是一致的。应用集群中的主控终端向各个应用终端发送更换URL地址的指令,并在更换URL地址的指令中,指出需要更换为URL地址的URL地址标识。
步骤S1002:各个应用终端在接收所述更换URL地址指令之后,在预先存储的其它数据库集群URL地址中,确定与所述URL地址标识对应的URL地址。
各个应用终端在接收更换URL地址指令之后,在预先存储的其它数据库集群的URL地址中,查找与URL地址标识对应的URL地址。
步骤S1003:各个应用终端均将所述数据库集群的URL地址,更换为与所述URL地址标识对应的URL地址。
各个应用终端在查找到与URL地址标识对应的URL地址之后,将转发地址对应的数据库集群的URL地址,替换为URL地址标识对应的URL地址。在URL地址更换之后,需要重启weblogic,以便各个应用终端可以使用与URL地址标识对应的URL地址所指向的数据库集群。
本申请提供了一种基于多中心部署系统的应用级容灾方法,本方法在HAProxy集群上布设检测故障程序,从而可以实现检测应用集群是否出现连接异常;并且在应用层到数据库层的应用集群上也布设有检测故障程序,从而可以实现检测数据库集群是否出现连接异常。因此,本申请可以实现准确确定故障位置的目的。由于本申请可以准确故障位置,因此,在进行数据中心切换时,便可以在故障位置处进行切换,而无需对整体数据中心进行切换。
本申请可以在故障位置进行切换,而不需在用户至网络层设备F5的路径进行整体数据中心切换,因此提高数据中心的可用性,减少了资源浪费。并且,由于无需在用户处进行切换,所以本申请不需要用户的配合,进而提高切换的可行性。
本实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算设备可读取存储介质中。基于这样的理解,本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该软件产品存储在一个存储介质中,包括若干指令用以使得一台计算设备(可以是个人计算机,服务器,移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-OnlyMemory)、随机存取存储器(RAM,RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其它实施例的不同之处,各个实施例之间相同或相似部分互相参见即可。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下,在其它实施例中实现。因此,本申请将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (8)
1.一种应用级容灾方法,其特征在于,应用于应用级容灾系统中的每个数据中心,所述数据中心包括位于网络层到应用层的HAProxy集群,以及位于应用层到数据库层的应用集群,所述方法包括:
HAProxy集群的主控终端在判定应用集群中出现连接异常的应用终端数量大于第一预设数量的情况下,确定所述应用集群出现连接异常,并推送所述应用集群出现连接异常的通知;
应用集群的主控终端在判定数据库集群中出现连接异常的数据库数量大于第二预设数量的情况下,确定所述数据库集群出现连接异常,并推送所述数据库集群出现连接异常的通知。
2.如权利要求1所述的方法,其特征在于,应用集群中的应用终端出现连接异常的确定过程,包括:
所述HAProxy集群中的主控终端接收HAProxy集群中各个HA终端发送的连接状态信息;其中,每个连接状态信息均包含一个HA终端与所有应用终端的连接状态;若HA终端与应用终端的心跳检测正常,则连接状态为正常,若HA终端与应用终端的心跳检测异常,则连接状态为连接异常;
所述HAProxy集群中的主控终端在分析后得知多个连接状态信息均表示一个应用终端连接状态为连接异常情况下,确定该应用终端出现连接异常,进而判断其故障。
3.如权利要求1或2所述的方法,其特征在于,在推送所述应用集群出现连接异常的通知之后,可自动实现该层级的中心间切换,具体包括:
所述HAProxy集群中的主控终端向各个HA终端发送更换配置文件指令,所述更换配置文件指令包括配置文件标识,该配置文件用于设定HAProxy集群中的每个HA终端的交易转发地址,配置文件标识指定要转发的中心,一旦更换配置文件,该中心的HAProxy集群会将交易请求转发给其他中心的应用集群进行处理;
其中,所述各个中心的配置文件可被各个HA终端预先存储,根据配置文件标识确定对应的配置文件,并且将所述应用集群的配置文件,更换为与所述配置文件标识对应的配置文件。
4.如权利要求1所述的方法,其特征在于,数据库集群中的数据库出现连接异常的确定过程,包括:
所述应用集群中的主控终端接收各个应用终端发送的第一连接异常连接状态信息;其中,每个第一连接异常连接状态信息至少包括出现连接异常的数据库标识;若应用终端在weblogic运行日志中检测到数据库连接错误关键字,则确定与数据库连接错误关键字对应的数据库标识,并将该数据库标识对应的数据库为连接异常数据库;
所述应用集群中的主控终端在分析后得知多个连接异常连接状态信息均表示一个数据库标识对应的数据库的连接状态为连接异常情况下,确定该数据库出现连接异常。
5.如权利要求1所述的方法,其特征在于,数据库集群中的数据库出现连接异常的确定过程,包括:
所述应用集群中的主控终端接收各个应用终端发送的第二连接异常连接状态信息;其中,每个第二连接异常连接状态信息至少包括出现连接异常的数据库标识;若应用终端在系统错误日志中检测到数据库标识,则该数据库标识对应的数据库为连接异常数据库;
所述应用集群中的主控终端在分析后得知多个连接异常连接状态信息均表示一个数据库标识对应的数据库的连接状态为连接异常情况下,确定该数据库出现连接异常。
6.如权利要求1所述的方法,其特征在于,数据库集群中的数据库出现连接异常的确定过程,包括:
所述应用集群中的主控终端接收各个应用终端发送的第三连接异常连接状态信息;其中,每个第三连接状态信息至少包括出现连接异常的数据库标识;若应用终端在weblogic运行日志中检测到连接错误关键字,则确定与数据库连接错误关键字对应的数据库标识所对应的第一时间,与应用终端在系统错误日志中检测到同一数据库标识的第二时间一致,则确定该数据库标识对应的数据库为连接异常数据库。
7.如权利要求4-6任一项所述的方法,其特征在于,在推送所述数据库集群出现连接异常的通知之后,还包括:
所述应用集群中的主控终端向各个应用终端发送更换URL地址指令,所述更换URL地址指令包括URL地址标识;
其中,所述各个数据中心的URL地址可被应用集群预先存储,根据URL地址标识确定对应的URL地址,并且将所述数据库集群的URL地址,更换为与所述URL地址标识对应的URL地址。
8.一种应用级容灾系统,其特征在于,包括:多个数据中心;
每个数据中心,用于执行如权利要求1-7任一项所述的应用级容灾方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510847343.6A CN105262633B (zh) | 2015-11-27 | 2015-11-27 | 一种应用级容灾方法及应用级容灾系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510847343.6A CN105262633B (zh) | 2015-11-27 | 2015-11-27 | 一种应用级容灾方法及应用级容灾系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105262633A true CN105262633A (zh) | 2016-01-20 |
CN105262633B CN105262633B (zh) | 2019-03-12 |
Family
ID=55102150
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510847343.6A Active CN105262633B (zh) | 2015-11-27 | 2015-11-27 | 一种应用级容灾方法及应用级容灾系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105262633B (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105938490A (zh) * | 2016-04-14 | 2016-09-14 | 北京思特奇信息技术股份有限公司 | 一种web应用系统连接数据源智能切换方法及系统 |
CN106407095A (zh) * | 2016-09-07 | 2017-02-15 | 北京小米移动软件有限公司 | 故障处理方法及装置 |
CN106953937A (zh) * | 2016-11-16 | 2017-07-14 | 阿里巴巴集团控股有限公司 | 一种统一资源定位符url转换方法及装置 |
CN107171817A (zh) * | 2016-03-07 | 2017-09-15 | 中国移动通信集团福建有限公司 | 一种故障信息获取方法和装置 |
CN107453940A (zh) * | 2017-06-19 | 2017-12-08 | 深圳市盛路物联通讯技术有限公司 | 一种基于接入节点的物联网终端设备检测方法及系统 |
CN107870830A (zh) * | 2016-09-23 | 2018-04-03 | 北京京东尚科信息技术有限公司 | 一种提升数据库可用性的方法和装置 |
CN108241554A (zh) * | 2016-12-23 | 2018-07-03 | 深圳市优朋普乐传媒发展有限公司 | 一种数据服务系统 |
CN109508245A (zh) * | 2017-09-15 | 2019-03-22 | 西安中兴新软件有限责任公司 | 一种实现异常分析的方法及终端 |
CN111966538A (zh) * | 2020-10-20 | 2020-11-20 | 支付宝(杭州)信息技术有限公司 | 一种区块链数据的恢复方法和装置 |
CN113568781A (zh) * | 2021-07-26 | 2021-10-29 | 北京奇艺世纪科技有限公司 | 一种数据库错误处理方法、装置及数据库集群访问系统 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102231681B (zh) * | 2011-06-27 | 2014-07-30 | 中国建设银行股份有限公司 | 一种高可用集群计算机系统及其故障处理方法 |
CN103186348B (zh) * | 2011-12-27 | 2016-04-13 | 杭州信核数据科技股份有限公司 | 存储系统及其数据读写方法 |
CN103345439B (zh) * | 2013-07-17 | 2016-05-11 | 国家电网公司 | 一种信息系统全链路健康状态监控方法及装置 |
AU2013403767B2 (en) * | 2013-10-23 | 2017-03-30 | Huawei Cloud Computing Technologies Co., Ltd. | Cloud application disaster recovery method, system and device |
-
2015
- 2015-11-27 CN CN201510847343.6A patent/CN105262633B/zh active Active
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107171817B (zh) * | 2016-03-07 | 2020-09-11 | 中国移动通信集团福建有限公司 | 一种故障信息获取方法和装置 |
CN107171817A (zh) * | 2016-03-07 | 2017-09-15 | 中国移动通信集团福建有限公司 | 一种故障信息获取方法和装置 |
CN105938490A (zh) * | 2016-04-14 | 2016-09-14 | 北京思特奇信息技术股份有限公司 | 一种web应用系统连接数据源智能切换方法及系统 |
CN106407095B (zh) * | 2016-09-07 | 2019-02-22 | 北京小米移动软件有限公司 | 故障处理方法及装置 |
CN106407095A (zh) * | 2016-09-07 | 2017-02-15 | 北京小米移动软件有限公司 | 故障处理方法及装置 |
CN107870830A (zh) * | 2016-09-23 | 2018-04-03 | 北京京东尚科信息技术有限公司 | 一种提升数据库可用性的方法和装置 |
CN106953937B (zh) * | 2016-11-16 | 2020-06-02 | 阿里巴巴集团控股有限公司 | 一种统一资源定位符url转换方法及装置 |
CN106953937A (zh) * | 2016-11-16 | 2017-07-14 | 阿里巴巴集团控股有限公司 | 一种统一资源定位符url转换方法及装置 |
CN108241554A (zh) * | 2016-12-23 | 2018-07-03 | 深圳市优朋普乐传媒发展有限公司 | 一种数据服务系统 |
CN107453940A (zh) * | 2017-06-19 | 2017-12-08 | 深圳市盛路物联通讯技术有限公司 | 一种基于接入节点的物联网终端设备检测方法及系统 |
CN109508245A (zh) * | 2017-09-15 | 2019-03-22 | 西安中兴新软件有限责任公司 | 一种实现异常分析的方法及终端 |
CN111966538A (zh) * | 2020-10-20 | 2020-11-20 | 支付宝(杭州)信息技术有限公司 | 一种区块链数据的恢复方法和装置 |
CN113568781A (zh) * | 2021-07-26 | 2021-10-29 | 北京奇艺世纪科技有限公司 | 一种数据库错误处理方法、装置及数据库集群访问系统 |
CN113568781B (zh) * | 2021-07-26 | 2023-07-21 | 北京奇艺世纪科技有限公司 | 一种数据库错误处理方法、装置及数据库集群访问系统 |
Also Published As
Publication number | Publication date |
---|---|
CN105262633B (zh) | 2019-03-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105262633A (zh) | 一种应用级容灾方法及应用级容灾系统 | |
JP4648447B2 (ja) | 障害復旧方法、プログラムおよび管理サーバ | |
CN103460203B (zh) | 群集唯一标识符 | |
US9785521B2 (en) | Fault tolerant architecture for distributed computing systems | |
US20180095849A1 (en) | Storage cluster failure detection | |
US9639437B2 (en) | Techniques to manage non-disruptive SAN availability in a partitioned cluster | |
CN110807064B (zh) | Rac分布式数据库集群系统中的数据恢复装置 | |
CN106059791B (zh) | 一种存储系统中业务的链路切换方法和存储设备 | |
CN107430603A (zh) | 大规模并行处理数据库的系统和方法 | |
CN105511805A (zh) | 集群文件系统的数据处理方法和装置 | |
CN105933391A (zh) | 一种节点扩容方法、装置及系统 | |
US20090187668A1 (en) | Protocol Independent Server Replacement and Replication in a Storage Area Network | |
CN105721200A (zh) | 主从式服务器系统的应用方法及该系统 | |
US8954808B1 (en) | Systems and methods for performing input/output path failovers | |
CN113300953B (zh) | 一种多路径故障转移组的管理方法、系统及相关装置 | |
CN111176888B (zh) | 云存储的容灾方法、装置及系统 | |
CN104036043A (zh) | 一种mysql高可用的方法及管理节点 | |
CN103473328A (zh) | 一种基于mysql的数据库云及其建立方法 | |
CN104426968B (zh) | 数据管理方法和装置 | |
CN107038094A (zh) | 一种数据备份方法及装置 | |
CN108268210B (zh) | 一种信息处理方法、计算节点及存储节点 | |
CN104407808A (zh) | 写入数据的方法和装置 | |
CN115794769B (zh) | 高可用数据库管理的方法、电子设备及存储介质 | |
CN113535738B (zh) | MySQL数据库系统的故障转移方法、高可用系统及电子设备 | |
US20190124145A1 (en) | Method and apparatus for availability management |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |