首页> 中国专利> 数据库的异常处理系统、数据库的异常处理方法及装置

数据库的异常处理系统、数据库的异常处理方法及装置

摘要

本申请公开数据库的异常处理系统、数据库的异常处理方法及装置,属于数据库技术领域,该系统包括控制层组件和至少一个代理组件,每个代理组件对应一个数据库系统,其中,代理组件用于监测数据库系统的服务状态,若确定监测到的服务状态满足异常上报条件,则向控制层组件发送异常处理请求;控制层组件用于接收异常处理请求,根据异常处理请求中的异常描述信息确定处理异常所需的目标信息,该目标信息至少包括异常类型,若确定异常类型属于自动修复类型,则采用自动修复流程,对异常处理请求中系统标识对应的数据库系统进行修复处理;若确定异常类型属于告警类型,则发送数据库系统存在异常的告警信息。这样,数据库系统的可用性更高。

著录项

  • 公开/公告号CN112764956A

    专利类型发明专利

  • 公开/公告日2021-05-07

    原文格式PDF

  • 申请/专利权人 网宿科技股份有限公司;

    申请/专利号CN202110046365.8

  • 发明设计人 张帆;

    申请日2021-01-14

  • 分类号G06F11/07(20060101);G06F9/54(20060101);

  • 代理机构11291 北京同达信恒知识产权代理有限公司;

  • 代理人赵祎

  • 地址 200030 上海市徐汇区斜土路2899号光启文化广场A幢5楼

  • 入库时间 2023-06-19 10:54:12

说明书

技术领域

本申请涉及数据库技术领域,尤其涉及数据库的异常处理系统、数据库的异常处理方法及装置。

背景技术

目前,新兴领域如人工智能、大数据等大多需要基于海量数据来提供业务服务,因此,数据变得越来越重要,而作为数据载体的数据库也变得十分重要。

现有技术中,数据库的异常首先是由客户端发现的,且只有当客户端主动上报数据库异常信息后,技术人员才知道数据库出了问题,之后,再手动对数据库进行修复。这样,数据库的异常发现比较困难,不利于快速修复数据库、且会降低数据库的可用性。

发明内容

本申请实施例提供数据库的异常处理系统、数据库的异常处理方法及装置,用以解决现有技术中数据库的异常发现比较困难,不利于快速修复数据库、且会降低数据库的可用性的问题。

第一方面,本申请实施例提供一种数据库的异常处理系统,包括控制层组件和至少一个代理组件,每个代理组件对应一个数据库系统,其中:

所述代理组件,用于监测所述数据库系统的服务状态,若确定监测到的服务状态满足异常上报条件,则向所述控制层组件发送异常处理请求,所述异常处理请求中包括所述数据库系统的系统标识和异常描述信息;

所述控制层组件,用于接收所述代理组件发送的异常处理请求,根据所述异常处理请求中的异常描述信息确定处理异常所需的目标信息,所述目标信息至少包括异常类型,若确定异常类型属于自动修复类型,则采用自动修复流程,对所述异常处理请求中系统标识对应的数据库系统进行修复处理;若确定异常类型属于告警类型,则发送所述数据库系统存在异常的告警信息。

在一种可能的实施方式中,所述代理组件,具体用于监测所述数据库系统与所述数据库系统对应的请求分发服务之间的连通状态,和/或,监测所述数据库系统中每个数据库的服务状态表征数据。

在一种可能的实施方式中,所述数据库系统包括至少两个数据库,所述至少两个数据库中的每个数据库均对应有代理组件,且所述数据库和所述代理组件部署在相同服务器上;所述代理组件,具体用于对所述数据库系统中与自身部署在相同服务器上的数据库,监测以下至少一种服务状态表征数据:所述数据库的请求响应情况,所述服务器的进程列表中是否存在所述数据库的进程,所述服务器中存储的所述数据库的日志;对所述数据库系统中与自身未部署在相同服务器上的数据库,监测所述数据库的请求响应情况。

在一种可能的实施方式中,所述目标信息还包括所述数据库系统中出现异常的数据库的数据库标识;所述控制层组件,还用于在确定异常类型属于自动修复类型后,根据所述数据库标识检查对应数据库的请求响应情况,在检查结果为异常时,采用自动修复流程,对所述数据库系统进行修复处理。

在一种可能的实施方式中,所述数据库系统中有一个数据库主数据库和至少一个从数据库,所述目标信息还包括所述数据库系统中出现异常的数据库是主数据库还是从数据库的指示信息;所述控制层组件,具体用于若根据所述指示信息确定出现异常的是主数据库,则从所述数据库系统中的从数据库中挑选一个数据库,将挑选的数据库切换为所述数据库系统中新的主数据库,并为所述数据库系统添加一个新的从数据库;若根据所述指示信息确定出现异常的是从数据库,则为所述数据库系统添加一个新的从数据库。

在一种可能的实施方式中,所述控制层组件,还用于在将挑选的数据库切换为所述数据库系统中新的主数据库之后,将所述新的主数据库的真实访问地址发送给所述数据库系统对应的请求分发服务,由所述请求分发服务对保存的所述数据库系统的虚拟访问地址与所述数据库系统中主数据库的真实访问地址之间的对应关系进行更新。

在一种可能的实施方式中,所述代理组件,还用于定期向所述控制层组件发送心跳包;所述控制层组件,还用于若确定在预设时长内未接收到所述代理组件发送的心跳包,则确定所述代理组件出现异常,并发送所述代理组件出现异常的告警信息。

第二方面,本申请实施例提供一种数据库的异常处理方法,应用于数据库的异常处理系统,所述数据库的异常处理系统包括控制层组件和至少一个代理组件,每个代理组件对应一个数据库系统,所述方法包括:所述控制层组件接收所述代理组件发送的异常处理请求;根据所述异常处理请求中的异常描述信息确定处理异常所需的目标信息,所述目标信息至少包括异常类型;若确定异常类型属于自动修复类型,则采用自动修复流程,对所述异常处理请求中系统标识对应的数据库系统进行修复处理;若确定异常类型属于告警类型,则发送所述数据库系统存在异常的告警信息。

在一种可能的实施方式中,所述目标信息还包括所述数据库系统中出现异常的数据库的数据库标识,还包括:在确定异常类型属于自动修复类型后,根据所述数据库标识检查对应数据库的请求响应情况;在检查结果为异常时,采用自动修复流程,对所述数据库系统进行修复处理。

在一种可能的实施方式中,所述数据库系统中有一个数据库主数据库和至少一个从数据库,所述目标信息还包括所述数据库系统中出现异常的数据库是主数据库还是从数据库的指示信息;采用自动修复流程,对所述数据库系统进行修复处理,包括:

若根据所述指示信息确定出现异常的是主数据库,则从所述数据库系统中的从数据库中挑选一个数据库,将挑选的数据库切换为所述数据库系统中新的主数据库,并为所述数据库系统添加一个新的从数据库;若根据所述指示信息确定出现异常的是从数据库,则为所述数据库系统添加一个新的从数据库。

在一种可能的实施方式中,在将挑选的数据库切换为所述数据库系统中新的主数据库之后,还包括:将所述新的主数据库的真实访问地址发送给所述数据库系统对应的请求分发服务,由所述请求分发服务对保存的所述数据库系统的虚拟访问地址与所述数据库系统中主数据库的真实访问地址之间的对应关系进行更新。

在一种可能的实施方式中,还包括:若确定在预设时长内未接收到所述代理组件发送的心跳包,则确定所述代理组件出现异常,并发送所述代理组件出现异常的告警信息。

第三方面,本申请实施例提供一种数据库的异常处理方法,应用于数据库的异常处理系统,所述数据库的异常处理系统包括控制层组件和至少一个代理组件,每个代理组件对应一个数据库系统,所述方法包括:所述代理组件监测所述数据库系统的服务状态;若确定监测到的服务状态满足异常上报条件,则向所述控制层组件发送异常处理请求,由所述控制层组件对所述数据库系统进行异常处理,所述异常处理请求中包括所述数据库系统的系统标识和异常描述信息。

在一种可能的实施方式中,监测所述数据库系统的服务状态,包括:

监测所述数据库系统与所述数据库系统对应的请求分发服务之间的连通状态;

和/或,

监测所述数据库系统中每个数据库的服务状态表征数据。

在一种可能的实施方式中,所述数据库系统包括至少两个数据库,所述至少两个数据库中的每个数据库均对应有代理组件,且所述数据库和所述代理组件部署在相同服务器上;

监测所述数据库系统中每个数据库的服务状态表征数据,包括:

对所述数据库系统中与自身部署在相同服务器上的数据库,监测以下至少一种服务状态表征数据:所述数据库的请求响应情况,所述服务器的进程列表中是否存在所述数据库的进程,所述服务器中存储的所述数据库的日志;对所述数据库系统中与自身未部署在相同服务器上的数据库,监测所述数据库的请求响应情况。

在一种可能的实施方式中,还包括:

定期向所述控制层组件发送心跳包,使所述控制层组件在预设时长内未接收到所述代理组件发送的心跳包,则判定所述代理组件出现异常,并发送所述代理组件出现异常的告警信息。

第四方面,本申请实施例提供一种数据库的异常处理装置,应用于数据库的异常处理系统,所述数据库的异常处理系统包括控制层组件和至少一个代理组件,每个代理组件对应一个数据库系统,所述装置设置于所述控制层组件中,所述装置包括:

接收模块,用于接收所述代理组件发送的异常处理请求;

确定模块,用于根据所述异常处理请求中的异常描述信息确定处理异常所需的目标信息,所述目标信息至少包括异常类型;

处理模块,用于若确定异常类型属于自动修复类型,则采用自动修复流程,对所述异常处理请求中系统标识对应的数据库系统进行修复处理;若确定异常类型属于告警类型,则发送所述数据库系统存在异常的告警信息。

第五方面,本申请实施例提供一种数据库的异常处理装置,应用于数据库的异常处理系统,所述数据库的异常处理系统包括控制层组件和至少一个代理组件,每个代理组件对应一个数据库系统,所述装置设置于所述代理组件中,所述装置包括:

监测模块,用于监测所述数据库系统的服务状态;

发送模块,用于若确定监测到的服务状态满足异常上报条件,则向所述控制层组件发送异常处理请求,由所述控制层组件对所述数据库系统进行异常处理,所述异常处理请求中包括所述数据库系统的系统标识和异常描述信息。

第六方面,本申请实施例提供一种电子设备,包括:至少一个处理器,以及与所述至少一个处理器通信连接的存储器,其中:

存储器存储有可被至少一个处理器执行的指令,该指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行上述任一数据库的异常处理方法。

第七方面,本申请实施例提供一种存储介质,当所述存储介质中的指令由电子设备的处理器执行时,所述电子设备能够执行上述任一数据库的异常处理方法。

本申请实施例中的数据库的异常处理系统包括控制层组件和至少一个代理组件,每个代理组件对应一个数据库系统,其中,代理组件用于监测对应数据库系统的服务状态,若确定监测到的服务状态满足异常上报条件,则向控制层组件发送异常处理请求,该异常处理请求中包括数据库系统的系统标识和异常描述信息;控制层组件用于接收代理组件发送的异常处理请求,根据异常处理请求中的异常描述信息确定处理异常所需的目标信息,该目标信息至少包括异常类型,若确定异常类型属于自动修复类型,则采用自动修复流程,对异常处理请求中系统标识对应的数据库系统进行修复处理;若确定异常类型属于告警类型,则发送数据库系统存在异常的告警信息。这样,能够主动发现数据库系统的异常,并能自动处理异常或告警,数据库系统的可用性更高。

附图说明

此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:

图1为本申请实施例提供的一种数据库的异常处理系统的架构示意图;

图2为本申请实施例提供的又一种数据库的异常处理系统的架构示意图;

图3为本申请实施例提供的再一种数据库的异常处理系统的架构示意图;

图4为本申请实施例提供的一种数据库的异常处理方法的流程图;

图5为本申请实施例提供的又一种数据库的异常处理方法的流程图;

图6为本申请实施例提供的一种数据库的异常处理装置的结构示意图;

图7为本申请实施例提供的又一种数据库的异常处理装置的结构示意图;

图8为本申请实施例提供的一种用于实现任一种数据库的异常处理方法的电子设备的硬件结构示意图。

具体实施方式

为了解决现有技术中数据库的异常发现比较困难,不利于快速修复数据库、且会降低数据库的可用性的问题,本申请实施例提供了数据库的异常处理系统、数据库的异常处理方法及装置。

以下结合说明书附图对本申请的优选实施例进行说明,应当理解,此处所描述的优选实施例仅用于说明和解释本申请,并不用于限定本申请,并且在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。

图1为本申请实施例提供的一种数据库的异常处理系统的架构示意图,包括控制层组件1、代理组件1、代理组件2和代理组件3,其中,代理组件1对应数据库系统1,数据库系统1包括数据库11和数据库12,代理组件2对应数据库系统2,数据库系统2包括数据库21和数据库22,代理组件3对应数据库系统3,数据库系统3包括数据库31和数据库32。

具体实施时,控制层组件可以部署在单独的服务器上也可以部署在服务器集群上。并且,当控制层组件部署在服务器集群上时,服务器集群共用一个消息队列,代理组件或数据库系统中的任一个数据库若需与控制层组件进行通信,则可将自身的业务数据放入消息队列,后续,服务器集群中的任一服务器都可从处理消息队列中读取业务数据进行处理,即服务器集群中的服务器不必固定服务于哪些代理组件或哪些数据库系统。

为了能够提高数据库的稳定性,每个数据库系统中的不同数据库可以部署在不同的服务器上。并且,每个数据库系统可以对应有一个、两个或更多个代理组件。当每个数据库系统对应一个代理组件时,代理组件可以部署在该数据库系统所部署的服务器上,比如部署在该数据库系统中任何一个数据库所在的服务上器(图1所示),也可以部署在该数据库系统所部署的服务器之外的其它服务器上。

下面基于图1对本申请实施例提供的数据库的异常处理系统进行介绍。

具体实施时,每个代理组件可监测自身对应的数据库系统的服务状态,若确定监测到的服务状态满足异常上报条件,则可向控制层组件发送异常处理请求,该异常处理请求中可以包括数据库系统的系统标识和异常描述信息。

其中,异常描述信息如异常原因、数据库系统中出现异常的数据库的数据库标识等。另外,当数据库系统中包括主数据库和从数据库时,异常描述信息还可以包括数据库系统中出现异常的数据库是主数据库还是从数据库的指示信息。

需要说明的是,异常描述信息越详细越利于后续的异常处理,此处的异常描述信息仅为举例,并不构成对本申请实施例中异常描述信息的限制。

实际应用中,每个代理组件可监测自身对应的数据库系统与数据库系统对应的请求分发服务之间的连通状态,和/或,监测数据库系统中每个数据库的服务状态表征数据如每个数据库的请求响应情况。在本发明的实施例中,请求分发服务可部署在请求发送端或者请求发送端的网络通信线路中的任一服务设备上,包括但不限于服务器、路由器、交换机等,并可与数据库系统进行网络通信。请求发送端可以是需要对数据库进行操作的业务服务器(例如,APP后台服务器),或业务客户端(例如APP),当请求发送端需要对数据库进行业务操作时,可基于预先获得的数据库系统的虚拟访问地址生成并发送业务请求,请求分发服务可接收请求发送端向数据库系统的虚拟访问地址发送的业务请求,并根据本地记录的虚拟访问地址与数据库真实地址的对应关系,查找该业务请求所对应的真实访问地址,并将该业务请求转发至该真实访问地址对应的数据库。

进一步地,每个代理组件可在确定自身对应的数据库系统与数据库系统对应的请求分发服务之间不连通,或者,在确定数据库系统中任一数据库的服务状态表征数据异常时,向控制层组件发送异常处理请求。

具体实施时,控制层组件在接收到任一代理组件发送的异常处理请求后,可根据异常处理请求中的异常描述信息确定处理异常所需的目标信息,该目标信息至少包括异常类型,之后,若确定异常类型属于自动修复类型,则可采用自动修复流程,对异常处理请求中系统标识对应的数据库系统进行修复处理,比如当确定数据库系统中的某个数据库无法正常提供服务时,自动为数据库系统添加一个新的数据库;若确定异常类型属于告警类型,则可发送数据库系统存在异常的告警信息,其中,告警信息中可以携带告警原因,以便技术人员能够更多细致地了解异常情况,及时正确地处理数据库系统的异常。

比如,异常描述信息中的异常原因是数据库系统中某个数据库无法提供服务,则确定的异常类型可以是自动修复类型,进而可采用自动修复流程,对相应数据库系统进行修复处理。

再比如,异常描述信息中的异常原因是数据库系统与数据库系统对应的请求分发服务之间不连通,则确定的异常类型可以是告警类型,进而发送数据库系统存在异常的告警信息,并可在告警信息中携带告警原因。

考虑到代理组件对数据库的服务状态的监测频率比较高,由于短暂的网络异常而导致的数据库异常也可能被代理组件捕捉到,而实际上此类异常并不是数据库本身的异常,不必进行处理。

为了应对这种情况,上述目标信息还可以包括出现异常的数据库,这样,控制层组件在确定异常类型属于自动修复类型后,还可以检查出现异常的数据库的请求响应情况,在检查结果为异常时,再采用自动修复流程,对相应数据库系统进行修复处理,以提升异常处理的准确性和合理性。

图2是本申请实施例提供的又一种数据库的异常处理系统的架构示意图,包括控制层组件2、代理组件4、代理组件5、代理组件6、代理组件7、代理组件8和代理组件9,其中,代理组件4和代理组件5对应数据库系统4,数据库系统4包括数据库41和数据库42,代理组件6和代理组件7对应数据库系统5,数据库系统5包括数据库51和数据库52,代理组件8和代理组件9对应数据库系统6,数据库系统6包括数据库61和数据库62,并且,每个数据库均对应有代理组件,且每个数据库和自身对应的代理组件部署在相同服务器上。

在图2所示的数据库的异常处理系统中,每个数据库系统相当于对应两个代理组件。对每个代理组件而言,对相应数据库系统中与自身部署在相同服务器上的数据库,可监测以下至少一种服务状态表征数据:数据库的请求响应情况,服务器的进程列表中是否存在数据库的进程,服务器中存储的数据库的日志;而对数据库系统中与自身未部署在相同服务器上的数据库,则可监测数据库的请求响应情况。

其中,对每个代理组件而言,对相应数据库系统中与自身部署在相同服务器上的数据库,可以通过本地连接监测数据库的响应情况;而对数据库系统中与自身未部署在相同服务器上的数据库,可以通过网络连接监测数据库的响应情况。

另外,图2中的每个数据库系统可以是负载均衡式的数据库系统即数据库系统中的各数据库地位平等、不分主次,也可以是主从式的数据库系统即数据库系统中有一个主数据库和至少一个从数据库,从数据库对主数据库中的数据进行备份。

而无论图2中的数据库系统是何种类型的数据库系统,每个代理组件执行的操作是相同的。下面以每个数据库系统是主从式的数据库系统为例,对图2中代理组件执行的操作进行介绍。

假设某个数据库系统M包括主数据库a、从数据库b和从数据库c,且主数据库a对应代理组件A、从数据库b对应代理组件B、从数据库c对应代理组件C。

那么,代理组件A、代理组件B和代理组件C均可监测数据库系统M与数据库系统M对应的请求分发服务之间的连通状态。并且:

代理组件A还可以监测:主数据库a的请求响应情况,自身所在服务器的进程列表中是否存在主数据库a的进程,自身所在服务器中存储的主数据库a的日志,从数据库b的请求响应情况和从数据库c的请求响应情况。

代理组件B还可以监测:从数据库b的请求响应情况,自身所在服务器的进程列表中是否存在从数据库b的进程,自身所在服务器中存储的从数据库b的日志,主数据库a的请求响应情况和从数据库c的请求响应情况。

代理组件C还可以监测:从数据库c的请求响应情况,自身所在服务器的进程列表中是否存在从数据库c的进程,自身所在服务器中存储的从数据库c的日志,主数据库a的请求响应情况和从数据库b的请求响应情况。

这样,每个代理组件既可检查数据库系统中与自身部署在相同服务器上的数据库是否出现异常,又可检查数据库系统中其它数据库是否出现异常,在一个数据库系统内形成多向检查。即便一个数据库系统中某个数据库和该数据库的代理组件都出现异常,数据库系统中其它数据库的代理组件也可及时发现该数据库的异常并上报,异常发现的准确性更高,利于及时处理异常,利于进一步提升数据库系统的可用性。

具体实施时,每个代理组件可以在确定满足以下任一异常上报条件时向控制层组件发送异常处理请求:

自身对应的数据库系统与数据库系统对应的请求分发服务之间不连通,数据库系统中任一数据库的请求响应异常,自身所在服务器的进程列表中不存在自身对应的数据库的进程,服务器中存储的自身对应的数据库的日志中存在表示数据库服务异常的预设关键字比如Warning、Error等。

实际应用中,对任一代理组件上报的异常处理请求,控制层组件都执行相同的处理操作,而不关心上报异常处理请求的代理组件和代理组件上报的出现异常的数据库是否部署在相同的服务器上。

图3是本申请实施例提供的再一种数据库的异常处理系统的架构示意图,包括控制层组件3、代理组件10、代理组件11、代理组件12、代理组件13、代理组件14和代理组件15,其中,代理组件10和代理组件11对应数据库系统7,数据库系统7包括主数据库71和从数据库72,代理组件12和代理组件13对应数据库系统8,数据库系统8包括主数据库81和从数据库82,代理组件14和代理组件15对应数据库系统9,数据库系统9包括主数据库91和从数据库92,其中,每个数据库系统包括一个主数据库和一个从数据库,其中主数据库用于响应业务请求,从数据库与主数据库保持数据同步。为了简化起见,图3未画出代理组件对相应数据库系统中未与自身部署在相同服务器上的数据库的监测情况。

现有技术中,请求发送端,如安装在客户端设备上的应用程序(Application,APP)直接访问一个数据库系统中的主数据库,一旦数据库系统切换主数据库,APP需要重启才能正常使用数据库系统中切换后的主数据库。

为了应对上述问题,本申请实施例中,参见图3,请求发送端(APP)对应一个请求分发服务,请求分发服务中保存各数据库系统的虚拟访问地址与各数据库系统中主数据库的真实访问地址之间的对应关系。APP可基于目标数据库系统的虚拟访问地址发起业务请求,该业务请求会先到达请求分发服务,请求分发服务在接收到业务请求后,可根据保存的各数据库系统的虚拟访问地址与各数据库系统中主数据库的真实访问地址之间的对应关系,确定业务请求中虚拟访问地址对应的主数据库的真实访问地址,然后,基于该真实访问地址将访问请求发送给相应的主数据库,使得该主数据库可接收到该业务请求,以完成对业务请求的响应。需要说明的是,请求发送端和请求分发服务可以是一一对应的,也可以是一个请求分发服务对应多个请求发送端。

在图3中,虽然为APP提供数据服务的是数据库系统中的主数据库,但保持从数据库的正常运行,在主备架构中同样是非常重要的,在实际情况中,数据库系统中的主数据库和从数据库都可能出现异常,为了能够更好地自动修复数据库系统出现的异常,上述目标信息还可以包括出现异常的是主数据库还是从数据库的指示信息。

后续,控制层组件若根据指示信息确定出现异常的是主数据库,则可从对应数据库系统中的从数据库中挑选一个数据库,将挑选的数据库切换为数据库系统中新的主数据库,并为数据库系统添加一个新的从数据库;若根据指示信息确定出现异常的是从数据库,则为数据库系统添加一个新的从数据库。这样,对数据库系统中主数据库异常和从数据库异常采用不同的异常处理策略,更符合主从式数据库系统的特点。

在本申请实施例中,除了可以主动发现主数据库的异常,自动并及时进行主从数据库切换,而且能够采用各种方式主动发现从数据库的异常,自动添加新的从数据库,数据库系统的可用性比较高。

另外,为了能够使请求发送端无感知,即无需关心数据库系统的主从数据库切换或从数据库更新,在数据库系统中主从数据库切换或从数据库更新后仍然能够按照原有的方式正常访问数据库系统。上述过程中,控制层组件在将挑选的数据库切换为数据库系统中新的主数据库之后,还可以将新的主数据库的真实访问地址发送给请求分发服务,由请求分发服务对保存的该数据库系统的虚拟访问地址与该数据库系统中主数据库的真实访问地址之间的对应关系进行更新,即将对应关系中原来的主数据库的真实访问地址替换为新的主数据库的真实访问地址,从而使得请求分发服务在接收到针对该虚拟访问地址的业务请求时,根据更新后的记录,发送给新的主数据库,而对于请求发送端来说,则无需进行任何修改。

此外,每个代理组件还可以定期向控制层组件发送心跳包。

相应地,控制层组件若在预设时长内未接收到任一代理组件发送的心跳包,则确定该代理组件出现异常,进而可发送该代理组件出现异常的告警信息,以便技术人员及时对该代理组件进行修复。

下面分别对本申请实例提供的数据库的异常处理系统中的代理组件和控制层组件分别进行介绍,并且,在后续的介绍中假设每个数据库和数据库对应的代理组件部署在相同服务器上。

具体实施时,每个代理组件可以定时向控制层组件上报心跳包,表示自身健康运行未出现异常,并且,代理组件可维护一个秒级定时任务列表,任务列表中的任务包含:

1)检查自身所在服务器的进程列表中是否存在与自身部署在相同服务器上的数据库的服务进程;

2)通过本地连接进入数据库查看与自身部署在相同服务器上的数据库的服务是否正常;

3)查看数据库所属数据库系统对应的请求分发服务的通信端口是否连通,以确定通过虚拟访问地址访问数据库系统的服务是否正常;

4)通过网络检查数据库系统中未与自身部署在相同服务器上的其它数据库是否正常;

5)监控服务器中存储的与自身部署在相同服务器上的数据库的日志。

代理组件可基于监测到的数据,自行判断数据库系统是否出现异常,若发现数据库系统出现异常,则可将异常描述信息上报至控制层组件。

其中,代理组件基于第1)-4)项的监测结果可确定数据库是否已无法正常提供服务,基于第5)项的监测结果可确定数据库是否存在安全隐患。

具体实施时,控制层组件基于各代理组件上报的心跳包和异常描述信息进行异常修复和/或告警,包括以下几种情况:

第一种情况:主数据库出现异常,主数据库的代理组件和从数据库的代理组件均正常。

这种情况下,主数据库和从数据库各自代理组件的秒级定时任务都会发现主数据库出现异常,主动上报异常描述信息给控制层组件,控制层组件接收到任何一方上报的异常描述信息后,可以检查主数据库是否能够正常响应,以确定主数据库是否真的出现异常。

比如,控制层组件可以向主数据库所属数据库系统对应的虚拟访问地址发送访问请求,若能正常响应,则表示主数据库正常,若未能正常响应,则可确定主数据库出现异常。

进步一地,若控制层组件确定主数据库出现异常,则可与主数据库的从数据库通信,将从数据库提升为新的主数据库,然后把主数据库所属数据库系统对应的虚拟访问地址与新的主数据库的真实访问地址相关联,并同步给数据库系统对应的请求分发服务。然后,再创建一个新的数据库,将新的数据库作为从数据库连接到新的主数据库。

其中,当一个数据库系统中存在至少两个从数据库时,控制层组件可从这至少两个从数据库中选择一个主从延时最小的从数据库作为新的主数据库。

第二种情况:主数据库和主数据库的代理组件均异常(例如服务器宕机),从数据库和从数据库的代理组件正常。

这种情况下,控制层组件能够发现主数据库的代理组件的心跳包丢失,之后,可主动与主数据库的代理组件进行通信,若通信异常,则可确认主数据库的代理组件出现异常。并且,从数据库的代理组件也能够发现主数据库出现异常,并上报异常描述信息给控制层组件,控制层组件在接收到异常描述信息后,可进一步检查主数据库的请求响应情况,以确认主数据库是否真的出现异常,若检查结果表示主数据库出现异常,则可进行主从数据库的切换。

第三种情况:从数据库出现异常。

这种情况下,主数据库的代理组件和从数据库的代理组件均可发现从数据库出现异常,并上报异常描述信息给控制层组件。控制层组件在接收到任一异常描述信息后,可检查从数据库的服务状态,若检查结果表示从数据库出现异常,则可则新建一个数据库,将新建的数据库作为主数据库的从数据库,以保证主数据库所在的数据库系统高可用。

第四种情况:主数据库的代理组件和从数据库的代理组件均异常。

这种情况下,控制层组件会发现主数据库的代理组件和从数据库的代理组件的心跳包均丢失,可通过检查相应数据库系统的虚拟访问地址的方式确定主数据库是否出现异常,并告警,以便技术人员及时修复主数据库的代理组件和从数据库的代理组件。

第五种情况:日志中发现表示数据库异常的指定关键字。

当代理组件在自身所在的服务器中存储的相应数据库的日志中发现表示数据库异常的指定关键字(如Error、Warning)时,可将日志中与指定关键字相关的数据库操作记录发送给控制层组件,触发控制层组件进行告警,比如,与告警平台对接告警、给指定人员发送邮件或短信等。

另外,当控制层组件检测到任一代理组件的心跳包缺失时,意味着代理组件可能出现异常,也可以进行告警,以便让运维人员及早介入,降低数据库系统出问题的可能性。

本申请通过部署的监控层组件和数据库的代理组件,实时监测数据库系统的服务状态,当发现数据库系统中主数据库出现异常时,可自动进行主从数据库切换,在极短时间内恢复数据库系统的服务而无需人工介入,在发现数据库系统中从数据库出现异常时,可自动为数据库系统添加新的从数据库,且可在数据库系统中任一数据库的代理组件出现异常时,及时告警,从而提供了一种具有异常发现、异常告警和自动修复异常能力的高可用数据库系统。

图4为本申请实施例提供的一种数据库的异常处理方法,该方法的执行主体是控制层组件,该方法包括以下步骤:

S401:接收代理组件发送的异常处理请求。

S402:根据异常处理请求中的异常描述信息确定处理异常所需的目标信息,其中,目标信息至少包括异常类型。

S403:若确定异常类型属于自动修复类型,则采用自动修复流程,对异常处理请求中系统标识对应的数据库系统进行修复处理;若确定异常类型属于告警类型,则发送数据库系统存在异常的告警信息。

为了避免由于网络问题而造成的异常误报,上述目标信息还可以包括数据库系统中出现异常的数据库的数据库标识,这样,在确定异常类型属于自动修复类型后,还可根据数据库标识检查对应数据库的请求响应情况,在检查结果为异常时,再采用自动修复流程,对相应数据库系统进行修复处理,以提升异常处理的准确性和合理性。

在一种可能的实施方式中,数据库系统中有一个数据库主数据库和至少一个从数据库,此时,上述目标信息还可以包括数据库系统中出现异常的数据库是主数据库还是从数据库的指示信息。

相应地,控制层组件若根据指示信息确定出现异常的是主数据库,则可从数据库系统中的从数据库中挑选一个数据库,将挑选的数据库切换为数据库系统中新的主数据库,并为数据库系统添加一个新的从数据库;若根据指示信息确定出现异常的是从数据库,则可为数据库系统添加一个新的从数据库。

并且,上述过程中,在将挑选的数据库切换为数据库系统中新的主数据库之后,还可以将新的主数据库的真实访问地址发送给数据库系统对应的请求分发服务,由请求分发服务对保存的数据库系统的虚拟访问地址与数据库系统中主数据库的真实访问地址之间的对应关系进行更新,以便APP可以不关注数据库系统中的数据库变换。

另外,若确定在预设时长内未接收到任一代理组件发送的心跳包,则可确定代理组件出现异常,并可发送该代理组件出现异常的告警信息,以便技术人员能够及时处理。

图5为本申请实施例提供的又一种数据库的异常处理方法,该方法的执行主体是代理组件,该方法包括以下步骤:

S501:监测数据库系统的服务状态。

具体实施时,可以监测数据库系统与数据库系统对应的请求分发服务之间的连通状态,和/或,监测数据库系统中每个数据库的服务状态表征数据。

在一种可能的实施方式中,数据库系统包括至少两个数据库,这至少两个数据库中的每个数据库均对应有代理组件,且每个数据库和自身对应的代理组件部署在相同服务器上。

该种情况下,对代理组件而言,对相应数据库系统中与自身部署在相同服务器上的数据库,可以监测以下至少一种服务状态表征数据:数据库的请求响应情况,服务器的进程列表中是否存在对应数据库的进程,服务器中存储的对应数据库的日志;对数据库系统中与自身未部署在相同服务器上的数据库,可以监测对应数据库的请求响应情况。

S502:若确定监测到的服务状态满足异常上报条件,则向控制层组件发送异常处理请求,由控制层组件对数据库系统进行异常处理,其中,异常处理请求中包括数据库系统的系统标识和异常描述信息。

具体实施时,每个代理组件可以在确定满足以下任一异常上报条件时向控制层组件发送异常处理请求:

数据库系统与数据库系统对应的请求分发服务之间不连通,数据库系统中任一数据库的请求响应异常,自身所在服务器的进程列表中不存在对应数据库的进程,服务器中存储的对应数据库的日志中存在表示数据库服务异常的预设关键字比如Warning、Error等。

此外,还可定期向控制层组件发送心跳包,使控制层组件在预设时长内未接收到任一代理组件发送的心跳包时,判定代理组件出现异常,发送代理组件出现异常的告警信息。

当本申请实施例中提供的方法以软件或硬件或软硬件结合实现的时候,电子设备中可以包括多个功能模块,每个功能模块可以包括软件、硬件或其结合。

图6为本申请实施例提供的一种数据库的异常处理装置的结构示意图,包括接收模块601、确定模块602、处理模块603。

接收模块601,用于接收代理组件发送的异常处理请求;

确定模块602,用于根据所述异常处理请求中的异常描述信息确定处理异常所需的目标信息,所述目标信息至少包括异常类型;

处理模块603,用于若确定异常类型属于自动修复类型,则采用自动修复流程,对所述异常处理请求中系统标识对应的数据库系统进行修复处理;若确定异常类型属于告警类型,则发送所述数据库系统存在异常的告警信息。

在一种可能的实施方式中,所述目标信息还包括所述数据库系统中出现异常的数据库的数据库标识,还包括:

检查模块604,用于在确定异常类型属于自动修复类型后,根据所述数据库标识检查对应数据库的请求响应情况;

所述处理模块603,具体用于在检查结果为异常时,采用自动修复流程,对所述数据库系统进行修复处理。

在一种可能的实施方式中,所述数据库系统中有一个数据库主数据库和至少一个从数据库,所述目标信息还包括所述数据库系统中出现异常的数据库是主数据库还是从数据库的指示信息;

处理模块603,具体用于若根据所述指示信息确定出现异常的是主数据库,则从所述数据库系统中的从数据库中挑选一个数据库,将挑选的数据库切换为所述数据库系统中新的主数据库,并为所述数据库系统添加一个新的从数据库;若根据所述指示信息确定出现异常的是从数据库,则为所述数据库系统添加一个新的从数据库。

在一种可能的实施方式中,还包括:

发送模块605,用于在将挑选的数据库切换为所述数据库系统中新的主数据库之后,将所述新的主数据库的真实访问地址发送给所述数据库系统对应的请求分发服务,由所述请求分发服务对保存的所述数据库系统的虚拟访问地址与所述数据库系统中主数据库的真实访问地址之间的对应关系进行更新。

在一种可能的实施方式中,还包括:

发送模块605,用于若确定在预设时长内未接收到所述代理组件发送的心跳包,则确定所述代理组件出现异常,并发送所述代理组件出现异常的告警信息。

图7为本申请实施例提供的又一种数据库的异常处理装置的结构示意图,包括监测模块701、发送模块702。

监测模块701,用于监测数据库系统的服务状态;

发送模块702,用于若确定监测到的服务状态满足异常上报条件,则向所述控制层组件发送异常处理请求,由所述控制层组件对所述数据库系统进行异常处理,所述异常处理请求中包括所述数据库系统的系统标识和异常描述信息。

在一种可能的实施方式中,监测模块701,具体用于监测所述数据库系统与所述数据库系统对应的请求分发服务之间的连通状态;和/或;监测所述数据库系统中每个数据库的服务状态表征数据。

在一种可能的实施方式中,所述数据库系统包括至少两个数据库,所述至少两个数据库中的每个数据库均对应有代理组件,且所述数据库和所述代理组件部署在相同服务器上;

所述监测模块701,具体用于对所述数据库系统中与自身部署在相同服务器上的数据库,监测以下至少一种服务状态表征数据:所述数据库的请求响应情况,所述服务器的进程列表中是否存在所述数据库的进程,所述服务器中存储的所述数据库的日志;对所述数据库系统中与自身未部署在相同服务器上的数据库,监测所述数据库的请求响应情况。

在一种可能的实施方式中,所述发送模块702,还用于定期向所述控制层组件发送心跳包,使所述控制层组件在预设时长内未接收到所述代理组件发送的心跳包,则判定所述代理组件出现异常,并发送所述代理组件出现异常的告警信息。

当本申请实施例中提供的方法以软件或硬件或软硬件结合实现的时候,电子设备中可以包括多个功能模块,每个功能模块可以包括软件、硬件或其结合。

本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,另外,在本申请各个实施例中的各功能模块可以集成在一个处理器中,也可以是单独物理存在,也可以两个或两个以上模块集成在一个模块中。各个模块相互之间的耦合可以是通过一些接口实现,这些接口通常是电性通信接口,但是也不排除可能是机械接口或其它的形式接口。因此,作为分离部件说明的模块可以是或者也可以不是物理上分开的,既可以位于一个地方,也可以分布到同一个或不同设备的不同位置上。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。

图8为本申请实施例提供的一种电子设备的结构示意图,该电子设备包括收发器801以及处理器802等物理器件,其中,处理器802可以是一个中央处理单元(CentralProcessing Unit,CPU)、微处理器、专用集成电路、可编程逻辑电路、大规模集成电路、或者为数字处理单元等等。收发器801用于电子设备和其他设备进行数据收发。

该电子设备还可以包括存储器803用于存储处理器802执行的软件指令,当然还可以存储电子设备需要的一些其他数据,如电子设备的标识信息、电子设备的加密信息、用户数据等。存储器803可以是易失性存储器(Volatile Memory),例如随机存取存储器(Random-Access Memory,RAM);存储器803也可以是非易失性存储器(Non-VolatileMemory),例如只读存储器(Read-Only Memory,ROM),快闪存储器(Flash Memory),硬盘(Hard Disk Drive,HDD)或固态硬盘(Solid-State Drive,SSD)、或者存储器803是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。存储器803可以是上述存储器的组合。

本申请实施例中不限定上述处理器802、存储器803以及收发器801之间的具体连接介质。本申请实施例在图8中仅以存储器803、处理器802以及收发器801之间通过总线804连接为例进行说明,总线在图8中以粗线表示,其它部件之间的连接方式,仅是进行示意性说明,并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图8中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。

处理器802可以是专用硬件或运行软件的处理器,当处理器802可以运行软件时,处理器802读取存储器803存储的软件指令,并在所述软件指令的驱动下,执行前述实施例中涉及的任一种数据库的异常处理方法。

本申请实施例还提供了一种存储介质,当所述存储介质中的指令由电子设备的处理器执行时,所述电子设备能够执行前述实施例中涉及的任一种数据库的异常处理方法。

在一些可能的实施方式中,本申请提供的数据库的异常处理方法的各个方面还可以实现为一种程序产品的形式,所述程序产品中包括有程序代码,当所述程序产品在电子设备上运行时,所述程序代码用于使所述电子设备执行前述实施例中涉及的任一种数据库的异常处理方法。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式盘、硬盘、RAM、ROM、可擦式可编程只读存储器(Erasable Programmable Read-Only Memory,EPROM)、闪存、光纤、光盘只读存储器(Compact Disk Read Only Memory,CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请实施例中用于数据库的异常处理的程序产品可以采用CD-ROM并包括程序代码,并可以在计算设备上运行。然而,本申请的程序产品不限于此,在本文件中,可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了可读程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质,该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于无线、有线、光缆、射频(Radio Frequency,RF)等等,或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码,所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等,还包括常规的过程式程序设计语言诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中,远程计算设备可以通过任意种类的网络如局域网(Local AreaNetwork,LAN)或广域网(Wide Area Network,WAN)连接到用户计算设备,或者,可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意,尽管在上文详细描述中提及了装置的若干单元或子单元,但是这种划分仅仅是示例性的并非强制性的。实际上,根据本申请的实施方式,上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之,上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外,尽管在附图中以特定顺序描述了本申请方法的操作,但是,这并非要求或者暗示必须按照该特定顺序来执行这些操作,或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号