CN115994044A - 基于监控服务的数据库故障处理方法、装置及分布式集群 - Google Patents
基于监控服务的数据库故障处理方法、装置及分布式集群 Download PDFInfo
- Publication number
- CN115994044A CN115994044A CN202310027120.XA CN202310027120A CN115994044A CN 115994044 A CN115994044 A CN 115994044A CN 202310027120 A CN202310027120 A CN 202310027120A CN 115994044 A CN115994044 A CN 115994044A
- Authority
- CN
- China
- Prior art keywords
- database
- monitoring
- fault
- node
- scene
- 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
- 238000012544 monitoring process Methods 0.000 title claims abstract description 466
- 238000003672 processing method Methods 0.000 title abstract description 18
- 230000008439 repair process Effects 0.000 claims abstract description 156
- 238000000034 method Methods 0.000 claims abstract description 86
- 238000012545 processing Methods 0.000 claims abstract description 67
- 238000005192 partition Methods 0.000 claims description 40
- 230000002159 abnormal effect Effects 0.000 claims description 34
- 238000001514 detection method Methods 0.000 claims description 23
- 238000013508 migration Methods 0.000 claims description 22
- 230000005012 migration Effects 0.000 claims description 22
- 238000004590 computer program Methods 0.000 claims description 11
- 238000010586 diagram Methods 0.000 description 11
- 230000008569 process Effects 0.000 description 10
- 238000004891 communication Methods 0.000 description 6
- 230000001960 triggered effect Effects 0.000 description 6
- 238000000926 separation method Methods 0.000 description 4
- 230000005856 abnormality Effects 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005067 remediation Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本发明提供一种基于监控服务的数据库故障处理方法、装置及分布式集群,属于分布式存储技术领域。该方法包括:基于管理节点反馈的告警消息,确定数据库故障类型;在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景;利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复。本发明提供的基于监控服务的数据库故障处理方法、装置及分布式集群,解决了现有实现方式每次都需要对DB导致的相同故障重复投入大量人力和时间,提高数据库损坏相关的故障处理效率和完成度。
Description
技术领域
本发明涉及分布式存储技术领域,尤其涉及一种基于监控服务的数据库故障处理方法、装置及分布式集群。
背景技术
在分布式存储系统中,监控(Monitor)服务会部署在不同的物理服务器上,负责监控、维护和查询集群中各对象存储设备(Object-based Storage Device,OSD)等其他服务的数据库运行状态,并在产生异常进行告警的上报,是集群底层最为重要和关键的组成部分之一。由于Monitor进程需要对集群的其他各服务状态进行监控和维护,因此Monitor 数据库(DataBase,DB)中需要保存许多其他服务相关的信息,这些信息以各类结构体的形式进行保存,如OSDmap、PGmap等集群信息。通过对DB中保存信息的维护、查询和更新,monitor进而可以实现对集群各服务状态的监控。
现有技术背景下,在某一节点监控服务的数据库出现异常时,虽然集群中其他节点上的监控服务不会受到影响,但本节点的服务是不会进行自动的识别和修复的。并且,对于所有监控服务的数据库均发生异常所导致的集群业务阻塞的情况,也只将故障定位至监控服务存在异常,后续还需专业的工作人员手动进行故障的逐一排查和修复。所以,现有技术中对于监控服务所发生的故障无法进行精准定位,导致故障处理效率低下,容易带来业务被长时间阻塞的问题和风险。
发明内容
本发明提供一种基于监控服务的数据库故障处理方法、装置及分布式集群,用以解决现有技术中故障处理效率低下的缺陷。
本发明提供一种基于监控服务的数据库故障处理方法,包括:
基于管理节点反馈的告警消息,确定数据库故障类型;
在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景;
利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复;
其中,所述告警消息是所述管理节点在确定监控节点对监控服务数据库所监控到的数据库运行状态与预设的数据库故障状态匹配的情况下,所生成的携带有与数据库故障状态对应故障类型信息的通知消息;所述集群状态是各所述监控节点之间通过投票决策的方式对分布式集群所部署的监控服务进行评估得到的。
根据本发明提供的一种基于监控服务的数据库故障处理方法,在所述确定数据库故障类型之后,还包括:
在确定所述数据库故障类型为监控服务数据库过载的情况下,基于目标监控节点的磁盘空间状态,确定数据库过载场景;
利用修复策略库匹配到与所述数据库过载场景对应的第二修复策略,以供监控节点根据所述第二修复策略对所述数据库过载场景进行修复;
其中,所述目标监控节点为所述数据库运行状态为异常状态的监控节点。
根据本发明提供的一种基于监控服务的数据库故障处理方法,所述数据库损坏场景与第一目标场景识别码相匹配;
其中,所述第一目标场景识别码为用于在所述修复策略库中区分第一修复策略的唯一标识信息。
根据本发明提供的一种基于监控服务的数据库故障处理方法,所述数据库过载场景与第二目标场景识别码相匹配;
其中,所述第二目标场景识别码为用于在所述修复策略库中区分第二修复策略的唯一标识信息。
根据本发明提供的一种基于监控服务的数据库故障处理方法,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,包括:
在确定所有监控节点的数据库运行状态为异常状态的情况下,将所述第一目标场景识别码设置为第一场景识别码;
与所述第一场景识别码对应的第一修复策略为:
通过对象存储设备的数据库中所保存的集群信息来对所有监控节点的监控服务数据库进行重建。
根据本发明提供的一种基于监控服务的数据库故障处理方法,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,还包括:
在确定所述集群状态为ERROR,且至少存在一个监控节点的数据库运行状态为正常状态的情况下,将所述第一目标场景识别码设置为第二场景识别码;
与所述第二场景识别码对应的第一修复策略为:
将数据库运行状态为正常状态的监控节点的监控服务数据库拷贝替换数据库运行状态为异常状态的监控节点。
根据本发明提供的一种基于监控服务的数据库故障处理方法,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,还包括:
在确定所述集群状态为WARN,且至少存在三个数据库运行状态为正常的监控节点的情况下,将所述第一目标场景识别码设置为第三场景识别码;
与所述第三场景识别码对应的第一修复策略为:
将数据库运行状态为正常状态的监控节点的监控服务数据库拷贝替换数据库运行状态为异常状态的监控节点。
根据本发明提供的一种基于监控服务的数据库故障处理方法,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,还包括:
在确定所述集群状态为WARN,且存在两个或两个以下数据库运行状态为正常的监控节点的情况下,将所述第一目标场景识别码设置为第四场景识别码;
与所述第四场景识别码对应的第一修复策略为:
对数据库运行状态为异常状态的监控节点的监控服务进行重新部署。
根据本发明提供的一种基于监控服务的数据库故障处理方法,所述基于目标监控节点的磁盘空间状态,确定数据库过载场景,包括:
在确定所述目标监控节点的磁盘空间状态为部署在为监控服务数据库预先划分的独立分区的情况下,将所述第二目标场景识别码设置为第五场景识别码;
与所述第五场景识别码对应的第二修复策略为:
对所述目标监控节点的监控服务数据库进行压缩。
根据本发明提供的一种基于监控服务的数据库故障处理方法,所述基于目标监控节点的磁盘空间状态,确定数据库过载场景,还包括:
在确定所述目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间满足迁移条件的情况下,将所述第二目标场景识别码设置为第六场景识别码;
与所述第六场景识别码对应的第二修复策略为:
先将所述目标监控节点的监控服务数据库从系统盘上迁移至指定的快速盘分区上,再对迁移后的监控服务数据库进行压缩;
其中,所述迁移条件为所述目标监控节点的磁盘空间存在快速盘分区,且所述目标监控节点的磁盘空间容量大于监控服务数据库容量。
根据本发明提供的一种基于监控服务的数据库故障处理方法,所述基于目标监控节点的磁盘空间状态,确定数据库过载场景,还包括:
在确定所述目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间满足迁移条件的情况下,将所述第二目标场景识别码设置为第七场景识别码;
与所述第七场景识别码对应的第二修复策略为:
对所述目标监控节点的监控服务数据库进行压缩。
本发明还提供一种基于监控服务的数据库故障处理装置,包括:
故障检测模块,用于基于管理节点反馈的告警消息,确定数据库故障类型;
第一故障识别模块,用于在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景;
第一故障修复模块,用于利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复;
其中,所述告警消息是所述管理节点在确定监控节点对监控服务数据库所监控到的数据库运行状态与预设的数据库故障状态匹配的情况下,所生成的携带有与数据库故障状态对应故障类型信息的通知消息;所述集群状态是各所述监控节点之间通过投票决策的方式对分布式存储系统所部署的监控服务进行评估得到的。
根据本发明提供的一种基于监控服务的数据库故障处理装置,还包括:
第二故障识别模块,用于在确定所述数据库故障类型为监控服务数据库过载的情况下,基于目标监控节点的磁盘空间状态,确定数据库过载场景;
第二故障修复模块,用于利用修复策略库匹配到与所述数据库过载场景对应的第二修复策略,以供监控节点根据所述第二修复策略对所述数据库过载场景进行修复;
其中,所述目标监控节点为异常监控节点所部署的集群计算节点。
本发明还提供一种分布式集群,包括至少n个在集群计算节点上部署监控服务的监控节点,以及至少1个在集群计算节点上部署软件管理服务的管理节点,每一所述监控节点用于实现如上任一所述的基于监控服务的数据库故障处理方法;
所述监控节点,用于对其自身部署的监控服务数据库进行监控,将获取到的数据库运行状态反馈至所述管理节点;
所述管理节点,用于根据所述数据库运行状态与预设的数据库故障状态进行匹配,生成携带有与数据库故障状态对应的故障类型信息的告警消息,并将所述告警消息下发至数据库运行状态为异常状态的监控节点;
其中,所述n为大于1的奇数,所述集群计算节点的总数量大于所述监控节点的总数量。
本发明还提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现如上述任一种所述基于监控服务的数据库故障处理方法。
本发明还提供一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现如上述任一种所述基于监控服务的数据库故障处理方法。
本发明提供的基于监控服务的数据库故障处理方法、装置及分布式集群,基于管理节点反馈的告警消息进行数据库故障类型的识别,在确定数据库故障类型为监控服务数据库损坏时,决策根据集群状态和各监控节点的数据库运行状态,确定集群各监控节点的监控服务数据库的损坏程度,并以此将故障定位至具体的数据库损坏场景,进而根据数据库损坏场景选择对应的第一修复策略来实现自动化的DB故障检测、识别和修复的完整流程。能够通过将monitor DB可能存在的损坏故障情况进行场景分离,再按照相应策略实现了当monitor DB 发生损坏时的自动识别和修复,解决了现有实现方式每次都需要对DB导致的相同故障重复投入大量人力和时间,提高数据库损坏相关的故障处理效率和完成度。
附图说明
为了更清楚地说明本发明或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明提供的基于监控服务的数据库故障处理方法的流程示意图;
图2是本发明提供的基于监控服务的数据库故障处理方法中的故障修复流程示意图之一;
图3是本发明提供的基于监控服务的数据库故障处理方法中的故障修复流程示意图之二;
图4是本发明提供的基于监控服务的数据库故障处理方法的部分流程示意图之一;
图5是本发明提供的基于监控服务的数据库故障处理方法的部分流程示意图之二;
图6是本发明提供的基于监控服务的数据库故障处理装置的结构示意图;
图7是本发明提供的分布式集群的结构示意图;
图8是本发明提供的电子设备的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合本发明中的附图,对本发明中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本申请中的术语“第一”、“第二”等是用于区别类似的对象,而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施,且“第一”、“第二”等所区分的对象通常为一类,并不限定对象的个数,例如第一对象可以是一个,也可以是多个。
应当理解,在本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明中所使用的那样,除非上下文清楚地指明其它情况,否则单数形式的“一”、“一个”及“该”意在包括复数形式。
术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在,但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
图1是本发明提供的基于监控服务的数据库故障处理方法的流程示意图。如图1所示,本发明实施例提供的基于监控服务的数据库故障处理方法,包括:步骤101、基于管理节点反馈的告警消息,确定数据库故障类型。
其中,所述告警消息是所述管理节点在确定监控节点对监控服务数据库所监控到的数据库运行状态与预设的数据库故障状态匹配的情况下,所生成的携带有与数据库故障状态对应故障类型信息的通知消息。
需要说明的是,本发明实施例提供的基于监控服务的数据库故障处理方法的执行主体为基于监控服务的数据库故障处理装置,该装置可以以电子芯片、中央处理器(Central Processing Unit,CPU)、微控制器单元(Micro Control Unit,MCU)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)等形式集成在分布式集群中的物理服务器中的处理器。
需要说明的是,在步骤101之前,需要通过在分布式集群中的监控节点(monitor),以及管理节点的管理软件侧增加关于监控服务的数据库(monitor Database,monitor DB)故障状态的告警项。
紧接着,由监控节点根据预先设置好的告警项,实时对其自身的monitor DB进行监控,将所采集到的数据库运行状态上传至管理节点,由管理节点中的管理软件对其进行处理。
管理节点中的管理软件将监控节点上传的数据库运行状态与在告警项中预先配置的数据库故障状态进行对比匹配,若二者一致,则说明该监控节点的monitor DB正常运行,并未触发告警项。反之,则说明该监控节点的monitor DB发生异常,触发告警项的同时,向该监控节点下发携带有用于表征其数据库故障状态的故障类型信息的通知消息,以实现对monitor DB的告警进行监控和上报。
其中,告警项主要包括monitor DB是否过大,monitor DB是否损坏。
具体地,在步骤101中,基于监控服务的数据库故障处理装置在接收到管理节点在触发告警项时所反馈的告警消息,将告警消息中所携带的故障类型信息作为数据库故障类型输出。
步骤102、在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景。
其中,所述集群状态是各所述监控节点之间通过投票决策的方式对分布式集群所部署的监控服务进行评估得到的。
需要说明的是,在分布式集群中,存在着节点故障、网络故障、网络延时等异常情况,通过paxos协议能够保证发生上述异常情况时数据依然能够在分布式系统中保持一致性,paxos协议是通过投票的方式,每个节点投出自己的一票,当得票数大于总节点数的一半,表示在分布式系统中达成了一致,则本次提议生效。当得票数等于或者小于总节点数的一半时,则表示没有达成一致,本次提议不生效。
根据paxos协议的原理,必须在分布式集群中部署奇数个监控节点。当部署3个monitor服务时,允许任意一个节点故障,剩余的两个节点仍然可以通过paxos协商一致,则集群提供正常服务,即集群状态为正常。如果monitor服务部署成偶数,比如2个,则任意一个节点故障,剩余一个节点的投票始终无法超过半数,则服务还是无法使用。
具体地,在步骤102中,基于监控服务的数据库故障处理装置若确定步骤101得到的数据库故障类型所对应的告警内容为监控服务数据库损坏,则利用分布式集群的集群状态,以及各监控节点的数据库运行状态对当前集群中由所有监控节点构成的决议委员会(quorum)的损坏程度进行判断,进一步识别出其故障隶属于该故障分类下哪一种具体的数据库损坏场景。
其中,数据库损坏场景主要包括两种,一是quorum中所有的监控节点均发生损坏。二是quorum中存在部分监控节点的monitor DB发生损坏,但仍有可以正常提供服务的monitor进程存在,则需要再依据可以正常提供服务的monitor数量进行更具体的判断和识别。
步骤103、利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复。
需要说明的是,在步骤103之前,需要将monitor DB可能存在的损坏故障情况进行分类,并将预先为每一种损坏故障制定相应的解决措施作为第一修复策略,存储在修复策略库中,并根据分布式集群的设计需求或者故障类型的改变而进行实时的维护和更新。
具体地,在步骤103中,基于监控服务的数据库故障处理装置根据步骤102识别到的数据库损坏场景与修复策略库进行匹配,若匹配成功,即说明该修复策略库中预先部署好该数据库损坏场景所对应的解决策略,则采取与该场景对应的第一修复策略对当前所面临的数据库损坏场景进行故障修复,恢复集群的monitor服务。
反之,即说明该修复策略库中预先并未枚举到该数据库损坏场景,所以并未部署好所对应的解决策略,则需要为其制定新的第一修复策略去解决该故障,并利用新的第一修复策略更新修复策略库。
本发明实施例基于管理节点反馈的告警消息进行数据库故障类型的识别,在确定数据库故障类型为监控服务数据库损坏时,决策根据集群状态和各监控节点的数据库运行状态,确定集群各监控节点的监控服务数据库的损坏程度,并以此将故障定位至具体的数据库损坏场景,进而根据数据库损坏场景选择对应的第一修复策略来实现自动化的DB故障检测、识别和修复的完整流程。能够通过将monitor DB可能存在的损坏故障情况进行场景分离,再按照相应策略实现了当monitor DB 发生损坏时的自动识别和修复,解决了现有实现方式每次都需要对DB导致的相同故障重复投入大量人力和时间,提高数据库损坏相关的故障处理效率和完成度。
在上述任一实施例的基础上,在所述确定数据库故障类型之后,还包括:在确定所述数据库故障类型为监控服务数据库过载的情况下,基于目标监控节点的磁盘空间状态,确定数据库过载场景。
其中,所述目标监控节点为所述数据库运行状态为异常状态的监控节点。
需要说明的是,目标监控节点,是指其自身对其所属的monitor DB所监控到的数据库运行状态触发了管理节点的告警项后,被判定为异常状态的监控节点。
具体地,在步骤101之后,基于监控服务的数据库故障处理装置若确定步骤101得到的数据库故障类型所对应的告警内容为监控服务数据库过载,则需要利用触发告警的目标监控节点的monitor DB在当前节点中用于表征空间占用情况的磁盘空间状态进行判断,进一步识别出其故障隶属于该故障分类下哪一种具体的数据库过载场景。
其中,数据库过载场景主要包括两种,一是当前目标监控节点的monitor DB已经处于为其单独划分的快速盘分区上。二是当前目标监控节点的monitor DB未处于为其单独划分的快速盘分区上,则需要进一步根据该节点的磁盘空间状态对其是否有条件配置独立的磁盘分区进行判断。
利用修复策略库匹配到与所述数据库过载场景对应的第二修复策略,以供监控节点根据所述第二修复策略对所述数据库过载场景进行修复。
具体地,基于监控服务的数据库故障处理装置根据识别到的数据库过载场景与修复策略库进行匹配,若匹配成功,即说明该修复策略库中预先部署好该数据库过载场景所对应的解决策略,则采取与该场景对应的第二修复策略对当前所面临的数据库过载场景进行故障修复,缓解集群过载。
反之,即说明该修复策略库中预先并未枚举到该数据库过载场景,所以并未部署好所对应的解决策略,则需要为其制定新的第二修复策略去解决该故障,并利用新的第二修复策略更新修复策略库。
可以理解的是,第一修复策略和第二修复策略可以同时维护在一个修复策略库中,也可以相对独立的维护在不同的数据库中。
本发明实施例基于管理节点反馈的告警消息进行数据库故障类型的识别,在确定数据库故障类型为监控服务数据库过载时,决策根据触发告警的目标监控节点的磁盘空间状态,将故障定位至具体的数据库过载场景,进而根据数据库过载场景选择对应的第二修复策略来实现自动化的DB故障检测、识别和修复的完整流程。能够通过将monitor DB可能存在的过载故障情况进行场景分离,再按照相应策略实现了当monitor DB 发生过载时的自动识别和修复,解决了现有实现方式每次都需要对DB导致的相同故障重复投入大量人力和时间,提高数据库损坏相关的故障处理效率和完成度。
在上述任一实施例的基础上,所述数据库损坏场景与第一目标场景识别码相匹配。
其中,所述第一目标场景识别码为用于在所述修复策略库中区分第一修复策略的唯一标识信息。
需要说明的是,在步骤103之前,可以在修复策略库中为不同的数据库损坏场景,分配一个用于区分与其他数据库损坏场景的第一目标场景识别码,并以第一目标场景识别码为索引,存储着与该数据库损坏场景唯一对应的第一修复策略。
具体地,在步骤103中,基于监控服务的数据库故障处理装置利用识别出的数据库损坏场景所对应的第一目标场景识别码在修复策略库进行查询,将与之唯一对应的第一修复策略下发至监控节点。
监控节点接收到第一修复策略之后,便按照其所携带的流程进行故障修复的相关处理。
本发明实施例利用与数据库损坏场景相匹配的第一目标场景识别码,在修复策略库查询出与之对应的第一修复策略后实现自动化的DB故障检测、识别和修复的完整流程。能够直接利用monitor DB已经存在过的损坏故障情况进行映射,避免了后续发生类似故障时对由monitor DB损坏引起的故障原因的重新定位过程,提高数据库损坏相关的故障处理效率。
在上述任一实施例的基础上,所述数据库过载场景与第二目标场景识别码相匹配。
其中,所述第二目标场景识别码为用于在所述修复策略库中区分第二修复策略的唯一标识信息。
需要说明的是,在进行过载故障修复之前,可以在修复策略库中为不同的数据库过载场景,分配一个用于区分与其他数据库过载场景的第二目标场景识别码,并以第二目标场景识别码为索引,存储着与该数据库过载场景唯一对应的第二修复策略。
具体地,基于监控服务的数据库故障处理装置利用识别出的数据库过载场景所对应的第二目标场景识别码在修复策略库进行查询,将与之唯一对应的第二修复策略下发至监控节点。
监控节点接收到第二修复策略之后,便按照其所携带的流程进行故障修复的相关处理。
本发明实施例利用与数据库过载场景相匹配的第二目标场景识别码,在修复策略库查询出与之对应的第二修复策略后实现自动化的DB故障检测、识别和修复的完整流程。能够直接利用monitor DB已经存在过的过载故障情况进行映射,避免了后续发生类似故障时对由monitor DB损坏引起的故障原因的重新定位过程,提高数据库过载相关的故障处理效率。
在上述任一实施例的基础上,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,包括:在确定所有监控节点的数据库运行状态为异常状态的情况下,将所述第一目标场景识别码设置为第一场景识别码。
与所述第一场景识别码对应的第一修复策略为:
通过对象存储设备的数据库中所保存的集群信息来对所有监控节点的监控服务数据库进行重建。
具体地,在步骤102中,基于监控服务的数据库故障处理装置若确定各监控节点的数据库运行状态均触发告警被判定为异常状态时,即说明集群的所有监控节点均发生损坏,则将此种数据库损坏场景的第一目标场景识别码设置并体现为第一场景识别码。
利用第一场景识别码在修复策略库所查询到的第一修复策略为需要通过对象存储设备的数据库(Object-based Storage Device DataBase,OSD DB)中保存的集群信息来对所有监控节点的monitor DB进行重建。
本发明实施例在确定所有监控节点的数据库运行状态为异常状态时,决策将第一目标场景识别码设置为第一场景识别码,并控制监控节点执行与之对应的第一修复策略,利用OSD DB中所保存的集群信息来对所有监控节点的monitor DB进行重建,实现自动化的DB故障检测、识别和修复的完整流程。能够对关于集群所有monitor节点均发生DB损坏的故障及处理实现自动化,可以在该故障发生的第一时间就完成对故障的识别和修复,提高数据库过载相关的故障处理效率。
在上述任一实施例的基础上,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,还包括:在确定所述集群状态为ERROR,且至少存在一个监控节点的数据库运行状态为正常状态的情况下,将所述第一目标场景识别码设置为第二场景识别码。
与所述第二场景识别码对应的第一修复策略为:
将数据库运行状态为正常状态的监控节点的监控服务数据库拷贝替换数据库运行状态为异常状态的监控节点。
具体地,在步骤102中,基于监控服务的数据库故障处理装置在确定集群中并非所有监控节点均发生损坏时,若确定quorum所反馈的集群状态为ERROR,且能够正常提供监控服务的监控节点的数量大于或者等于1,即说明可能由于操作不当等原因造成集群所有的monitor数据库显示为均发生异常的ERROR状态,但实际上却存在能够正常提供服务的监控节点,则将此种数据库损坏场景的第一目标场景识别码设置并体现为第二场景识别码。
利用第二场景识别码在修复策略库所查询到的第一修复策略为需要将当前能够正常提供服务的监控节点的monitor DB拷贝替换成能够正常提供服务的监控节点的monitor DB,采用DB拷贝的方法重新恢复监控服务。
本发明实施例在确定当前集群状态为ERROR,且至少存在一个监控节点的数据库运行状态为正常状态时,决策将第一目标场景识别码设置为第二场景识别码,并控制监控节点执行与之对应的第一修复策略,利用DB拷贝的方法重新恢复监控服务,实现自动化的DB故障检测、识别和修复的完整流程。能够对关于集群状态为ERROR但仍存在提供正常服务的监控节点的故障及处理实现自动化,可以在该故障发生的第一时间就完成对故障的识别和修复,提高数据库过载相关的故障处理效率。
在上述任一实施例的基础上,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,还包括:在确定所述集群状态为WARN,且至少存在三个数据库运行状态为正常的监控节点的情况下,将所述第一目标场景识别码设置为第三场景识别码。
与所述第三场景识别码对应的第一修复策略为:
将数据库运行状态为正常状态的监控节点的监控服务数据库拷贝替换数据库运行状态为异常状态的监控节点。
具体地,在步骤102中,基于监控服务的数据库故障处理装置在确定集群中并非所有监控节点均发生损坏时,若确定quorum所反馈的集群状态为WARN,且能够正常提供监控服务的监控节点的数量大于或者等于3,即说明集群虽然能正常读写,但仍具有决策功能,则将此种数据库损坏场景的第一目标场景识别码设置并体现为第三场景识别码。
利用第三场景识别码在修复策略库所查询到的第一修复策略为需要将当前能够正常提供服务的监控节点的monitor DB拷贝替换成能够正常提供服务的监控节点的monitor DB,采用DB拷贝的方法重新恢复监控服务。
本发明实施例在确定当前集群状态为WARN,且至少存在三个监控节点的数据库运行状态为正常状态时,决策将第一目标场景识别码设置为第三场景识别码,并控制监控节点执行与之对应的第一修复策略,利用DB拷贝的方法重新恢复监控服务,实现自动化的DB故障检测、识别和修复的完整流程。能够对关于集群状态为WARN但仍有条件进行quorum决策的故障及处理实现自动化,可以在该故障发生的第一时间就完成对故障的识别和修复,提高数据库过载相关的故障处理效率。
在上述任一实施例的基础上,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,还包括:
在确定所述集群状态为WARN,且存在两个或两个以下数据库运行状态为正常的监控节点的情况下,将所述第一目标场景识别码设置为第四场景识别码。
与所述第四场景识别码对应的第一修复策略为:
对数据库运行状态为异常状态的监控节点的监控服务进行重新部署。
具体地,在步骤102中,基于监控服务的数据库故障处理装置在确定集群中并非所有监控节点均发生损坏时,若确定quorum所反馈的集群状态为WARN,且能够正常提供监控服务的监控节点的数量小于或者等于2,即说明集群虽然能正常读写,但是由于无法决策集群会处在WARN状态,则将此种数据库损坏场景的第一目标场景识别码设置并体现为第四场景识别码。
利用第四场景识别码在修复策略库所查询到的第一修复策略为需要将故障监控节点的monitor服务先缩容掉再重新扩容的方法,恢复故障节点的monitor DB,相当于对该节点的monitor服务重新进行部署。
示例性地,图2是本发明提供的基于监控服务的数据库故障处理方法中的故障修复流程示意图之一。如图2所示,本发明实施例给出一种修复monitor DB所发生的DB损坏场景时的具体实施过程:
(1)可以将第一场景识别码定义为编码14,需要通过OSD DB中保存的信息来对所有节点的monitor DB进行重建,其具体实施步骤如下:
a、结合OSD DB中保存的信息修复monitor DB中的OSDMap、AuthMap数据。
b、通过OSD上报的消息修复monitor DB中的PGMap数据。
c、修复PGMap_meta信息,使得通过修复后的DB可以实现monitor的正常启动。
d、完成monitor DB的修复,重新启动monitor进程。
(2)可以将第二场景识别码定义为编码12,则通过将当前正常monitor节点的monitor DB拷贝替换故障节点的DB进行恢复。
(3)可以将第三场景识别码定义为编码11,则通过将当前正常monitor节点的monitor DB拷贝替换故障节点的DB进行恢复。
(4)可以将第四场景识别码定义为编码13,则通过将故障monitor节点的monitor服务先缩容掉再重新扩容的方法,恢复故障节点的monitor DB,相当于对该节点的monitor服务重新进行部署。
可以理解的是,以上步骤的代码实现最后都将封装成维护命令的形式,以方便管理软件在收到monitor上报的告警后根据策略进行调用,达到实现自动对monitor DB进行修复的目的。
本发明实施例在确定当前集群状态为WARN,且存在两个或两个以下监控节点的数据库运行状态为正常状态时,决策将第一目标场景识别码设置为第四场景识别码,并控制监控节点执行与之对应的第一修复策略,利用monitor缩扩容的方法重新恢复监控服务,实现自动化的DB故障检测、识别和修复的完整流程。能够对关于集群状态为WARN但没有条件进行quorum决策的故障及处理实现自动化,可以在该故障发生的第一时间就完成对故障的识别和修复,提高数据库过载相关的故障处理效率。
在上述任一实施例的基础上,所述基于目标监控节点的磁盘空间状态,确定数据库过载场景,包括:在确定所述目标监控节点的磁盘空间状态为部署在为监控服务数据库预先划分的独立分区的情况下,将所述第二目标场景识别码设置为第五场景识别码。
与所述第五场景识别码对应的第二修复策略为:
对所述目标监控节点的监控服务数据库进行压缩。
具体地,基于监控服务的数据库故障处理装置在确定触发告警的目标监控节点的磁盘空间状态指示其monitor DB已经部署在预先划分出的独立分区时,即说明monitor DB部署位置正确,只需在原有部署位置的基础上进行压缩,则将此种数据库损坏场景的第二目标场景识别码设置并体现为第五场景识别码。
利用第五场景识别码在修复策略库所查询到的第二修复策略为需要直接将故障监控节点的monitor DB在其所部署的独立分区内进行压缩。
本发明实施例在确定目标监控节点的磁盘空间状态为部署在为监控服务数据库预先划分的独立分区时,决策将第二目标场景识别码设置为第五场景识别码,并控制监控节点执行与之对应的第二修复策略,利用在原有部署空间中进行压缩的方法对空间进行压缩,实现自动化的DB故障检测、识别和修复的完整流程。能够对关于monitor DB部署位置正确但存储内容过载的故障及处理实现自动化,可以在该故障发生的第一时间就完成对故障的识别和修复,提高数据库过载相关的故障处理效率。
在上述任一实施例的基础上,所述基于目标监控节点的磁盘空间状态,确定数据库过载场景,还包括:在确定所述目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间满足迁移条件的情况下,将所述第二目标场景识别码设置为第六场景识别码。
与所述第六场景识别码对应的第二修复策略为:
先将所述目标监控节点的监控服务数据库从系统盘上迁移至指定的快速盘分区上,再对迁移后的监控服务数据库进行压缩。
其中,所述迁移条件为所述目标监控节点的磁盘空间存在快速盘分区,且所述目标监控节点的磁盘空间容量大于监控服务数据库容量。
具体地,基于监控服务的数据库故障处理装置在确定触发告警的目标监控节点的磁盘空间状态指示其monitor DB未部署在预先划分出的独立分区时,即说明monitor DB部署位置错误,需要进一步判断当前节点是否满足monitor DB迁移条件,则将此种数据库损坏场景的第二目标场景识别码设置并体现为第六场景识别码。
其中,迁移条件是针对当前节点的物理磁盘空间是否具备单独为monitor DB划分独立分区所设置的条件。
示例性地,迁移条件可以为是否配置有nvme或ssd盘,并且盘上是否还有足够的空间来给monitor划分分区。
利用第六场景识别码在修复策略库所查询到的第二修复策略为需要先对该节点的monitor DB从系统盘上迁移至指定的快速盘分区上,在对DB进行压缩。
本发明实施例在确定目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间满足迁移条件时,决策将第二目标场景识别码设置为第六场景识别码,并控制监控节点执行与之对应的第二修复策略,利用将monitor DB迁移至正确的部署位置后进行压缩的方法对空间进行压缩和利用,实现自动化的DB故障检测、识别和修复的完整流程。能够对关于monitor DB部署位置错误且具备迁移条件的过载故障及处理实现自动化,可以在该故障发生的第一时间就完成对故障的识别和修复,提高数据库过载相关的故障处理效率。
在上述任一实施例的基础上,所述基于目标监控节点的磁盘空间状态,确定数据库过载场景,还包括:在确定所述目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间满足迁移条件的情况下,将所述第二目标场景识别码设置为第七场景识别码。
与所述第七场景识别码对应的第二修复策略为:
对所述目标监控节点的监控服务数据库进行压缩。
具体地,基于监控服务的数据库故障处理装置在确定触发告警的目标监控节点的磁盘空间状态指示其monitor DB未部署在预先划分出的独立分区时,即说明monitor DB部署位置错误,需要进一步判断当前节点是否满足monitor DB迁移条件,则将此种数据库损坏场景的第二目标场景识别码设置并体现为第七场景识别码。
利用第七场景识别码在修复策略库所查询到的第二修复策略为由于该节点的磁盘空间不具备迁移条件,所以只能将故障监控节点的monitor DB在当前的部署位置中进行压缩。
示例性地,图3是本发明提供的基于监控服务的数据库故障处理方法中的故障修复流程示意图之二。如图3所示,本发明实施例给出一种修复monitor DB所发生的DB过载场景时的具体实施过程:
(1)可以将第五场景识别码定义为编码21,则直接对该节点monitor DB进行压缩。
(2)可以将第六场景识别码定义为编码22,则先对该节点的monitor DB从系统盘上迁移至指定的快速盘分区上,在对DB进行压缩;否则直接对DB进行压缩。
(3)可以将第六场景识别码定义为编码23,则直接对该节点monitor DB进行压缩。
示例性地,图4是本发明提供的基于监控服务的数据库故障处理方法的部分流程示意图之一。图5是本发明提供的基于监控服务的数据库故障处理方法的部分流程示意图之二。如图4和图5所示,本发明实施例分别给出一种基于监控服务的数据库故障处理方法的具体实施过程:
如图4所示,首先在监控节点和管理节点中的软件侧增加对monitor DB的检测和相应的告警项,包括DB是否过大,DB是否损坏。两种故障场景为monitor自身的检查项:
(1)当根据数据库运行状态中记载的DB大于集群部署时分配空间的某个阈值时,管理节点的软件侧将携带有故障类型信息为数据库过载的告警消息下发至监控节点。
(2)当存在某监控节点monitor DB打开失败时,监控节点将该异常情况记录在数据库运行状态中,以使得管理节点的软件侧将携带有故障类型信息为数据库损坏的告警消息下发至监控节点
(3)软件侧根据监控节点触发的告警消息在界面平台上进行告警的前端显示和上报。
紧接着,如图5所示,根据管理节点触发的告警项,对故障场景和集群条件进行识别:
(1)若告警消息指示监控节点monitor DB过载,则判断当前节点monitor DB是否已经是在在单独划分的快速盘分区上。反之,则判断该节点是否有条件配置独立的磁盘分区:
a、若部署时已经划分了monitor DB的独立分区,并将DB部署在该分区上,则返回编号21。
b、若部署时默认monitor DB部署在了系统盘上,并未单独划分分区,则需要判断当前节点是否满足monitor DB迁移条件:当前节点是否配置有nvme或ssd盘,并且盘上是否还有足够的空间来给monitor划分分区。若满足条件,则返回编号22。否则返回编号23。
(2)若告警消息指示监控节点monitor DB损坏,则需要对当前集群quorum的损坏程度进行判断:
a、若集群存在部分节点的monitor DB发生损坏,但集群仍有可以正常提供服务的monitor进程存在,则需要对可以正常提供服务的monitor数量进行判断:
若集群状态为WARN且集群当前monitor服务正常的monitor节点数量>2,则返回编号11。
若集群状态已经为ERROR且还有可以正常提供服务的monitor节点存在,则返回编号12。
若集群状态为WARN且集群当前monitor服务正常的monitor节点数量<=2,则返回编号13。
b、若集群的所有monitor节点均发生损坏,则返回编号14。
本发明实施例在确定目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间不满足迁移条件时,决策将第二目标场景识别码设置为第七场景识别码,并控制监控节点执行与之对应的第二修复策略,利用将monitor DB在默认的部署位置中进行压缩的方法对空间进行压缩,实现自动化的DB故障检测、识别和修复的完整流程。能够对关于monitor DB部署位置错误且不具备迁移条件的过载故障及处理实现自动化,可以在该故障发生的第一时间就完成对故障的识别和修复,提高数据库过载相关的故障处理效率。
图6是本发明提供的基于监控服务的数据库故障处理装置的结构示意图。在上述任一实施例的基础上,如图6所示,本发明实施例提供的基于监控服务的数据库故障处理装置包括故障检测模块610、第一故障识别模块620和第一故障修复模块630,其中:
故障检测模块610,用于基于管理节点反馈的告警消息,确定数据库故障类型。
第一故障识别模块620,用于在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景。
第一故障修复模块630,用于利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复。
其中,所述告警消息是所述管理节点在确定监控节点对监控服务数据库所监控到的数据库运行状态与预设的数据库故障状态匹配的情况下,所生成的携带有与数据库故障状态对应故障类型信息的通知消息。所述集群状态是各所述监控节点之间通过投票决策的方式对分布式存储系统所部署的监控服务进行评估得到的。
具体地,故障检测模块610、第一故障识别模块620和第一故障修复模块630顺次电连接。
故障检测模块610在接收到管理节点在触发告警项时所反馈的告警消息,将告警消息中所携带的故障类型信息作为数据库故障类型输出。
第一故障识别模块620若确定故障检测模块610得到的数据库故障类型所对应的告警内容为监控服务数据库损坏,则利用分布式集群的集群状态,以及各监控节点的数据库运行状态对当前集群中由所有监控节点构成的决议委员会(quorum)的损坏程度进行判断,进一步识别出其故障隶属于该故障分类下哪一种具体的数据库损坏场景。
第一故障修复模块630根据第一故障识别模块620识别到的数据库损坏场景与修复策略库进行匹配,若匹配成功,即说明该修复策略库中预先部署好该数据库损坏场景所对应的解决策略,则采取与该场景对应的第一修复策略对当前所面临的数据库损坏场景进行故障修复,恢复集群的monitor服务。
可选地,所述数据库损坏场景与第一目标场景识别码相匹配。
其中,所述第一目标场景识别码为用于在所述修复策略库中区分第一修复策略的唯一标识信息。
可选地,第一故障识别模块620,具体用于在确定所有监控节点的数据库运行状态为异常状态的情况下,将所述第一目标场景识别码设置为第一场景识别码。
与所述第一场景识别码对应的第一修复策略为:
通过对象存储设备的数据库中所保存的集群信息来对所有监控节点的监控服务数据库进行重建。
可选地,第一故障识别模块620,还具体用于在确定所述集群状态为ERROR,且至少存在一个监控节点的数据库运行状态为正常状态的情况下,将所述第一目标场景识别码设置为第二场景识别码;
与所述第二场景识别码对应的第一修复策略为:
将数据库运行状态为正常状态的监控节点的监控服务数据库拷贝替换数据库运行状态为异常状态的监控节点。
可选地,第一故障识别模块620,还具体用于在确定所述集群状态为WARN,且至少存在三个数据库运行状态为正常的监控节点的情况下,将所述第一目标场景识别码设置为第三场景识别码;
与所述第三场景识别码对应的第一修复策略为:
将数据库运行状态为正常状态的监控节点的监控服务数据库拷贝替换数据库运行状态为异常状态的监控节点。
可选地,第一故障识别模块620,还具体用于在确定所述集群状态为WARN,且存在两个或两个以下数据库运行状态为正常的监控节点的情况下,将所述第一目标场景识别码设置为第四场景识别码;
与所述第四场景识别码对应的第一修复策略为:
对数据库运行状态为异常状态的监控节点的监控服务进行重新部署。
本发明实施例提供的基于监控服务的数据库故障处理装置,用于执行本发明上述基于监控服务的数据库故障处理方法,其实施方式与本发明提供的基于监控服务的数据库故障处理方法的实施方式一致,且可以达到相同的有益效果,此处不再赘述。
本发明实施例基于管理节点反馈的告警消息进行数据库故障类型的识别,在确定数据库故障类型为监控服务数据库损坏时,决策根据集群状态和各监控节点的数据库运行状态,确定集群各监控节点的监控服务数据库的损坏程度,并以此将故障定位至具体的数据库损坏场景,进而根据数据库损坏场景选择对应的第一修复策略来实现自动化的DB故障检测、识别和修复的完整流程。能够通过将monitor DB可能存在的损坏故障情况进行场景分离,再按照相应策略实现了当monitor DB 发生损坏时的自动识别和修复,解决了现有实现方式每次都需要对DB导致的相同故障重复投入大量人力和时间,提高数据库损坏相关的故障处理效率和完成度。
在上述任一实施例的基础上,该装置还包括第二故障识别模块和第二故障修复模块,其中:
第二故障识别模块,用于在确定所述数据库故障类型为监控服务数据库过载的情况下,基于目标监控节点的磁盘空间状态,确定数据库过载场景。
第二故障修复模块,用于利用修复策略库匹配到与所述数据库过载场景对应的第二修复策略,以供监控节点根据所述第二修复策略对所述数据库过载场景进行修复。
其中,所述目标监控节点为异常监控节点所部署的集群计算节点。
可选地,所述数据库过载场景与第二目标场景识别码相匹配。
其中,所述第二目标场景识别码为用于在所述修复策略库中区分第二修复策略的唯一标识信息。
可选地,第二故障识别模块,具体用于在确定所述目标监控节点的磁盘空间状态为部署在为监控服务数据库预先划分的独立分区的情况下,将所述第二目标场景识别码设置为第五场景识别码;
与所述第五场景识别码对应的第二修复策略为:
对所述目标监控节点的监控服务数据库进行压缩。
可选地,第二故障识别模块,还具体用于在确定所述目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间满足迁移条件的情况下,将所述第二目标场景识别码设置为第六场景识别码;
与所述第六场景识别码对应的第二修复策略为:
先将所述目标监控节点的监控服务数据库从系统盘上迁移至指定的快速盘分区上,再对迁移后的监控服务数据库进行压缩;
其中,所述迁移条件为所述目标监控节点的磁盘空间存在快速盘分区,且所述目标监控节点的磁盘空间容量大于监控服务数据库容量。
可选地,第二故障识别模块,还具体用于在确定所述目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间满足迁移条件的情况下,将所述第二目标场景识别码设置为第七场景识别码;
与所述第七场景识别码对应的第二修复策略为:
对所述目标监控节点的监控服务数据库进行压缩。
本发明实施例提供的基于监控服务的数据库故障处理装置,用于执行本发明上述基于监控服务的数据库故障处理方法,其实施方式与本发明提供的基于监控服务的数据库故障处理方法的实施方式一致,且可以达到相同的有益效果,此处不再赘述。
本发明实施例基于管理节点反馈的告警消息进行数据库故障类型的识别,在确定数据库故障类型为监控服务数据库过载时,决策根据触发告警的目标监控节点的磁盘空间状态,将故障定位至具体的数据库过载场景,进而根据数据库过载场景选择对应的第二修复策略来实现自动化的DB故障检测、识别和修复的完整流程。能够通过将monitor DB可能存在的过载故障情况进行场景分离,再按照相应策略实现了当monitor DB发生过载时的自动识别和修复,解决了现有实现方式每次都需要对DB导致的相同故障重复投入大量人力和时间,提高数据库损坏相关的故障处理效率和完成度。
图7是本发明提供的分布式集群的结构示意图。在上述任一实施例的基础上,如图7所示,本发明实施例提供的分布式集群包括至少n个在集群计算节点上部署监控服务的监控节点710,以及至少1个在集群计算节点上部署软件管理服务的管理节点720。每一所述监控节点710用于实现如上所述的基于监控服务的数据库故障处理方法。
所述监控节点710,用于对其自身部署的监控服务数据库进行监控,将获取到的数据库运行状态反馈至所述管理节点。
所述管理节点720,用于根据所述数据库运行状态与预设的数据库故障状态进行匹配,生成携带有与数据库故障状态对应的故障类型信息的告警消息,并将所述告警消息下发至数据库运行状态为异常状态的监控节点。
其中,所述n为大于1的奇数,所述集群计算节点的总数量大于所述监控节点710的总数量。
具体地,分布式集群由奇数个在集群计算节点上部署监控服务的监控节点710,以及至少1个在集群计算节点上部署软件管理服务的管理节点720构成。
首先,由监控节点710对其自身部署的monitor DB的运行情况进行监控,将所监控到的数据库运行状态反馈至管理节点720。紧接着,由管理节点720将接收到的数据库运行状态与针对数据库故障状态所配置的告警项进行匹配,在触发告警项时向监控节点710反馈携带有与该监控节点710所发生的数据库故障状态对应的故障类型信息的告警消息。最后,再由监控节点710接收管理节点720所反馈的告警消息,对产生告警的故障场景和集群条件进行识别,进而调用相关的命令实现对DB故障的修复。
本发明实施例基于管理节点反馈的告警消息进行数据库故障类型的识别,在确定数据库故障类型为监控服务数据库损坏时,决策根据集群状态和各监控节点的数据库运行状态,确定集群各监控节点的监控服务数据库的损坏程度,并以此将故障定位至具体的数据库损坏场景,进而根据数据库损坏场景选择对应的第一修复策略来实现自动化的DB故障检测、识别和修复的完整流程。能够通过将monitor DB可能存在的损坏故障情况进行场景分离,再按照相应策略实现了当monitor DB 发生损坏时的自动识别和修复,解决了现有实现方式每次都需要对DB导致的相同故障重复投入大量人力和时间,提高数据库损坏相关的故障处理效率和完成度。
图8示例了一种电子设备的实体结构示意图,如图8所示,该电子设备可以包括:处理器(processor)810、通信接口(Communications Interface)820、存储器(memory)830和通信总线840,其中,处理器810,通信接口820,存储器830通过通信总线840完成相互间的通信。处理器810可以调用存储器830中的逻辑指令,以执行基于监控服务的数据库故障处理方法,该方法包括:基于管理节点反馈的告警消息,确定数据库故障类型;在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景;利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复;其中,所述告警消息是所述管理节点在确定监控节点对监控服务数据库所监控到的数据库运行状态与预设的数据库故障状态匹配的情况下,所生成的携带有与数据库故障状态对应故障类型信息的通知消息;所述集群状态是各所述监控节点之间通过投票决策的方式对分布式集群所部署的监控服务进行评估得到的。
此外,上述的存储器830中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
另一方面,本发明还提供一种计算机程序产品,所述计算机程序产品包括计算机程序,计算机程序可存储在非暂态计算机可读存储介质上,所述计算机程序被处理器执行时,计算机能够执行上述各方法所提供的基于监控服务的数据库故障处理方法,该方法包括:基于管理节点反馈的告警消息,确定数据库故障类型;在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景;利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复;其中,所述告警消息是所述管理节点在确定监控节点对监控服务数据库所监控到的数据库运行状态与预设的数据库故障状态匹配的情况下,所生成的携带有与数据库故障状态对应故障类型信息的通知消息;所述集群状态是各所述监控节点之间通过投票决策的方式对分布式集群所部署的监控服务进行评估得到的。
又一方面,本发明还提供一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现以执行上述各方法提供的基于监控服务的数据库故障处理方法,该方法包括:基于管理节点反馈的告警消息,确定数据库故障类型;在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景;利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复;其中,所述告警消息是所述管理节点在确定监控节点对监控服务数据库所监控到的数据库运行状态与预设的数据库故障状态匹配的情况下,所生成的携带有与数据库故障状态对应故障类型信息的通知消息;所述集群状态是各所述监控节点之间通过投票决策的方式对分布式集群所部署的监控服务进行评估得到的。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (16)
1.一种基于监控服务的数据库故障处理方法,其特征在于,包括:
基于管理节点反馈的告警消息,确定数据库故障类型;
在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景;
利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复;
其中,所述告警消息是所述管理节点在确定监控节点对监控服务数据库所监控到的数据库运行状态与预设的数据库故障状态匹配的情况下,所生成的携带有与数据库故障状态对应故障类型信息的通知消息;所述集群状态是各所述监控节点之间通过投票决策的方式对分布式集群所部署的监控服务进行评估得到的。
2.根据权利要求1所述的基于监控服务的数据库故障处理方法,其特征在于,在所述确定数据库故障类型之后,还包括:
在确定所述数据库故障类型为监控服务数据库过载的情况下,基于目标监控节点的磁盘空间状态,确定数据库过载场景;
利用修复策略库匹配到与所述数据库过载场景对应的第二修复策略,以供监控节点根据所述第二修复策略对所述数据库过载场景进行修复;
其中,所述目标监控节点为所述数据库运行状态为异常状态的监控节点。
3.根据权利要求1所述的基于监控服务的数据库故障处理方法,其特征在于,所述数据库损坏场景与第一目标场景识别码相匹配;
其中,所述第一目标场景识别码为用于在所述修复策略库中区分第一修复策略的唯一标识信息。
4.根据权利要求2所述的基于监控服务的数据库故障处理方法,其特征在于,所述数据库过载场景与第二目标场景识别码相匹配;
其中,所述第二目标场景识别码为用于在所述修复策略库中区分第二修复策略的唯一标识信息。
5.根据权利要求3所述的基于监控服务的数据库故障处理方法,其特征在于,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,包括:
在确定所有监控节点的数据库运行状态为异常状态的情况下,将所述第一目标场景识别码设置为第一场景识别码;
与所述第一场景识别码对应的第一修复策略为:
通过对象存储设备的数据库中所保存的集群信息来对所有监控节点的监控服务数据库进行重建。
6.根据权利要求5所述的基于监控服务的数据库故障处理方法,其特征在于,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,还包括:
在确定所述集群状态为ERROR,且至少存在一个监控节点的数据库运行状态为正常状态的情况下,将所述第一目标场景识别码设置为第二场景识别码;
与所述第二场景识别码对应的第一修复策略为:
将数据库运行状态为正常状态的监控节点的监控服务数据库拷贝替换数据库运行状态为异常状态的监控节点。
7.根据权利要求6所述的基于监控服务的数据库故障处理方法,其特征在于,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,还包括:
在确定所述集群状态为WARN,且至少存在三个数据库运行状态为正常的监控节点的情况下,将所述第一目标场景识别码设置为第三场景识别码;
与所述第三场景识别码对应的第一修复策略为:
将数据库运行状态为正常状态的监控节点的监控服务数据库拷贝替换数据库运行状态为异常状态的监控节点。
8.根据权利要求7所述的基于监控服务的数据库故障处理方法,其特征在于,所述基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景,还包括:
在确定所述集群状态为WARN,且存在两个或两个以下数据库运行状态为正常的监控节点的情况下,将所述第一目标场景识别码设置为第四场景识别码;
与所述第四场景识别码对应的第一修复策略为:
对数据库运行状态为异常状态的监控节点的监控服务进行重新部署。
9.根据权利要求4所述的基于监控服务的数据库故障处理方法,其特征在于,所述基于目标监控节点的磁盘空间状态,确定数据库过载场景,包括:
在确定所述目标监控节点的磁盘空间状态为部署在为监控服务数据库预先划分的独立分区的情况下,将所述第二目标场景识别码设置为第五场景识别码;
与所述第五场景识别码对应的第二修复策略为:
对所述目标监控节点的监控服务数据库进行压缩。
10.根据权利要求9所述的基于监控服务的数据库故障处理方法,其特征在于,所述基于目标监控节点的磁盘空间状态,确定数据库过载场景,还包括:
在确定所述目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间满足迁移条件的情况下,将所述第二目标场景识别码设置为第六场景识别码;
与所述第六场景识别码对应的第二修复策略为:
先将所述目标监控节点的监控服务数据库从系统盘上迁移至指定的快速盘分区上,在对迁移后的监控服务数据库进行压缩;
其中,所述迁移条件为所述目标监控节点的磁盘空间存在快速盘分区,且所述目标监控节点的磁盘空间容量大于监控服务数据库容量。
11.根据权利要求10所述的基于监控服务的数据库故障处理方法,其特征在于,所述基于目标监控节点的磁盘空间状态,确定数据库过载场景,还包括:
在确定所述目标监控节点的磁盘空间状态为未部署在为监控服务数据库预先划分的独立分区,且目标监控节点的磁盘空间满足迁移条件的情况下,将所述第二目标场景识别码设置为第七场景识别码;
与所述第七场景识别码对应的第二修复策略为:
对所述目标监控节点的监控服务数据库进行压缩。
12.一种基于监控服务的数据库故障处理装置,其特征在于,包括:
故障检测模块,用于基于管理节点反馈的告警消息,确定数据库故障类型;
第一故障识别模块,用于在确定所述数据库故障类型为监控服务数据库损坏的情况下,基于集群状态和各监控节点的数据库运行状态,确定数据库损坏场景;
第一故障修复模块,用于利用修复策略库匹配到与所述数据库损坏场景对应的第一修复策略,以供监控节点根据所述第一修复策略对所述数据库损坏场景进行修复;
其中,所述告警消息是所述管理节点在确定监控节点对监控服务数据库所监控到的数据库运行状态与预设的数据库故障状态匹配的情况下,所生成的携带有与数据库故障状态对应故障类型信息的通知消息;所述集群状态是各所述监控节点之间通过投票决策的方式对分布式存储系统所部署的监控服务进行评估得到的。
13.根据权利要求12所述的基于监控服务的数据库故障处理装置,其特征在于,还包括:
第二故障识别模块,用于在确定所述数据库故障类型为监控服务数据库过载的情况下,基于目标监控节点的磁盘空间状态,确定数据库过载场景;
第二故障修复模块,用于利用修复策略库匹配到与所述数据库过载场景对应的第二修复策略,以供监控节点根据所述第二修复策略对所述数据库过载场景进行修复;
其中,所述目标监控节点为异常监控节点所部署的集群计算节点。
14.一种分布式集群,包括至少n个在集群计算节点上部署监控服务的监控节点,以及至少1个在集群计算节点上部署软件管理服务的管理节点,其特征在于,每一所述监控节点用于实现如权利要求1-11任一所述的基于监控服务的数据库故障处理方法;
所述监控节点,用于对其自身部署的监控服务数据库进行监控,将获取到的数据库运行状态反馈至所述管理节点;
所述管理节点,用于根据所述数据库运行状态与预设的数据库故障状态进行匹配,生成携带有与数据库故障状态对应的故障类型信息的告警消息,并将所述告警消息下发至数据库运行状态为异常状态的监控节点;
其中,所述n为大于1的奇数,所述集群计算节点的总数量大于所述监控节点的总数量。
15.一种电子设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时实现如权利要求1至11任一项所述基于监控服务的数据库故障处理方法。
16.一种非暂态计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1至11任一项所述基于监控服务的数据库故障处理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310027120.XA CN115994044B (zh) | 2023-01-09 | 2023-01-09 | 基于监控服务的数据库故障处理方法、装置及分布式集群 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310027120.XA CN115994044B (zh) | 2023-01-09 | 2023-01-09 | 基于监控服务的数据库故障处理方法、装置及分布式集群 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115994044A true CN115994044A (zh) | 2023-04-21 |
CN115994044B CN115994044B (zh) | 2023-06-13 |
Family
ID=85989996
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310027120.XA Active CN115994044B (zh) | 2023-01-09 | 2023-01-09 | 基于监控服务的数据库故障处理方法、装置及分布式集群 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115994044B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116662059A (zh) * | 2023-07-24 | 2023-08-29 | 上海爱可生信息技术股份有限公司 | MySQL数据库CPU故障诊断及自愈方法及可读存储介质 |
CN117170985A (zh) * | 2023-11-02 | 2023-12-05 | 武汉大学 | 面向开放式地理信息网络服务的分布式监测方法及系统 |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102739435A (zh) * | 2011-03-31 | 2012-10-17 | 微软公司 | 作为服务的故障检测与恢复 |
CN103559108A (zh) * | 2013-11-11 | 2014-02-05 | 中国科学院信息工程研究所 | 一种基于虚拟化实现主备故障自动恢复的方法及系统 |
CN103684817A (zh) * | 2012-09-06 | 2014-03-26 | 百度在线网络技术(北京)有限公司 | 数据中心的监控方法及系统 |
CN104052634A (zh) * | 2014-05-30 | 2014-09-17 | 国家电网公司 | 信息安全监控系统及方法 |
US20150186206A1 (en) * | 2013-12-31 | 2015-07-02 | Ciena Corporation | Method and system for intelligent distributed health monitoring in switching system equipment |
CN105337765A (zh) * | 2015-10-10 | 2016-02-17 | 上海新炬网络信息技术有限公司 | 一种分布式hadoop集群故障自动诊断修复系统 |
CN106933693A (zh) * | 2017-03-15 | 2017-07-07 | 郑州云海信息技术有限公司 | 一种数据库集群节点故障自动修复方法及系统 |
CN109343987A (zh) * | 2018-08-20 | 2019-02-15 | 科大国创软件股份有限公司 | It系统故障诊断及修复方法、装置、设备、存储介质 |
CN109522287A (zh) * | 2018-09-18 | 2019-03-26 | 平安科技(深圳)有限公司 | 分布式文件存储集群的监控方法、系统、设备及介质 |
CN109783307A (zh) * | 2018-12-03 | 2019-05-21 | 日照钢铁控股集团有限公司 | 一种数据库集中监管方法及终端 |
CN111444032A (zh) * | 2020-03-04 | 2020-07-24 | 无锡华云数据技术服务有限公司 | 一种计算机系统故障修复方法、系统及设备 |
CN115422010A (zh) * | 2022-09-19 | 2022-12-02 | Oppo广东移动通信有限公司 | 数据集群中的节点管理方法、装置及存储介质 |
-
2023
- 2023-01-09 CN CN202310027120.XA patent/CN115994044B/zh active Active
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102739435A (zh) * | 2011-03-31 | 2012-10-17 | 微软公司 | 作为服务的故障检测与恢复 |
CN103684817A (zh) * | 2012-09-06 | 2014-03-26 | 百度在线网络技术(北京)有限公司 | 数据中心的监控方法及系统 |
CN103559108A (zh) * | 2013-11-11 | 2014-02-05 | 中国科学院信息工程研究所 | 一种基于虚拟化实现主备故障自动恢复的方法及系统 |
US20150186206A1 (en) * | 2013-12-31 | 2015-07-02 | Ciena Corporation | Method and system for intelligent distributed health monitoring in switching system equipment |
CN104052634A (zh) * | 2014-05-30 | 2014-09-17 | 国家电网公司 | 信息安全监控系统及方法 |
CN105337765A (zh) * | 2015-10-10 | 2016-02-17 | 上海新炬网络信息技术有限公司 | 一种分布式hadoop集群故障自动诊断修复系统 |
CN106933693A (zh) * | 2017-03-15 | 2017-07-07 | 郑州云海信息技术有限公司 | 一种数据库集群节点故障自动修复方法及系统 |
CN109343987A (zh) * | 2018-08-20 | 2019-02-15 | 科大国创软件股份有限公司 | It系统故障诊断及修复方法、装置、设备、存储介质 |
CN109522287A (zh) * | 2018-09-18 | 2019-03-26 | 平安科技(深圳)有限公司 | 分布式文件存储集群的监控方法、系统、设备及介质 |
CN109783307A (zh) * | 2018-12-03 | 2019-05-21 | 日照钢铁控股集团有限公司 | 一种数据库集中监管方法及终端 |
CN111444032A (zh) * | 2020-03-04 | 2020-07-24 | 无锡华云数据技术服务有限公司 | 一种计算机系统故障修复方法、系统及设备 |
CN115422010A (zh) * | 2022-09-19 | 2022-12-02 | Oppo广东移动通信有限公司 | 数据集群中的节点管理方法、装置及存储介质 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116662059A (zh) * | 2023-07-24 | 2023-08-29 | 上海爱可生信息技术股份有限公司 | MySQL数据库CPU故障诊断及自愈方法及可读存储介质 |
CN116662059B (zh) * | 2023-07-24 | 2023-10-24 | 上海爱可生信息技术股份有限公司 | MySQL数据库CPU故障诊断及自愈方法及可读存储介质 |
CN117170985A (zh) * | 2023-11-02 | 2023-12-05 | 武汉大学 | 面向开放式地理信息网络服务的分布式监测方法及系统 |
CN117170985B (zh) * | 2023-11-02 | 2024-01-12 | 武汉大学 | 面向开放式地理信息网络服务的分布式监测方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN115994044B (zh) | 2023-06-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN115994044B (zh) | 基于监控服务的数据库故障处理方法、装置及分布式集群 | |
CN110798375B (zh) | 一种增强容器集群高可用性的监控方法、系统及终端设备 | |
CN109495312B (zh) | 基于仲裁盘和双链路的高可用集群的实现方法和系统 | |
US9785521B2 (en) | Fault tolerant architecture for distributed computing systems | |
CN108710673B (zh) | 实现数据库高可用方法、系统、计算机设备和存储介质 | |
CN111522501B (zh) | 磁盘阵列空间划分方法、装置、电子设备及存储介质 | |
US9170888B2 (en) | Methods and apparatus for virtual machine recovery | |
CN110532278B (zh) | 声明式的MySQL数据库系统高可用方法 | |
CN107832164A (zh) | 一种基于Ceph的故障硬盘处理的方法及装置 | |
CN107480014A (zh) | 一种高可用设备切换方法及装置 | |
WO2017220013A1 (zh) | 业务处理方法及装置、存储介质 | |
US7373542B2 (en) | Automatic startup of a cluster system after occurrence of a recoverable error | |
CN111198921A (zh) | 数据库的切换方法、装置、计算机设备和存储介质 | |
CN110502496A (zh) | 一种分布式文件系统修复方法、系统、终端及存储介质 | |
CN115686368A (zh) | 区块链网络的节点的存储扩容的方法、系统、装置和介质 | |
CN113986618B (zh) | 集群脑裂自动修复方法、系统、装置及存储介质 | |
CN114328033A (zh) | 保持高可用设备组业务配置一致性的方法及装置 | |
CN111199701B (zh) | 一种led点阵显示屏同步控制系统及其自检方法 | |
CN108897645B (zh) | 一种基于备用心跳磁盘的数据库集群容灾方法和系统 | |
CN113282334A (zh) | 软件缺陷的恢复方法、装置、计算机设备和存储介质 | |
CN115686951A (zh) | 一种数据库服务器的故障处理方法和装置 | |
CN113242147A (zh) | 多云环境的自动化运维部署方法、装置、设备和存储介质 | |
CN111444032A (zh) | 一种计算机系统故障修复方法、系统及设备 | |
CN107707402B (zh) | 一种分布式系统中服务仲裁的管理系统及其管理方法 | |
CN115048244B (zh) | 一种服务器的硬件修复方法、系统、计算机设备及介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |