CN105138441A - 高可用集群***及基于该***的告警方法、告警*** - Google Patents
高可用集群***及基于该***的告警方法、告警*** Download PDFInfo
- Publication number
- CN105138441A CN105138441A CN201510387184.6A CN201510387184A CN105138441A CN 105138441 A CN105138441 A CN 105138441A CN 201510387184 A CN201510387184 A CN 201510387184A CN 105138441 A CN105138441 A CN 105138441A
- Authority
- CN
- China
- Prior art keywords
- warning information
- data base
- class
- write
- node
- 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
- Debugging And Monitoring (AREA)
Abstract
本发明提供了一种高可用集群***及基于该***的告警方法、告警***。应用本发明,告警信息同时存储在主节点的第一主数据库和第一辅助数据库中以及各个从节点的第二辅助数据库中。在未发生数据库连接故障的情况下,上述各个数据库中存储的告警信息是一致的。无论用户当前访问的是主节点还是从节点,都可以从当前访问的节点的数据库中获取告警信息。即便是在主节点或者主节点的数据库出现故障时,用户也可以从任意一个从节点的第二辅助数据库中获取到告警信息,从而能够及时依据获取的告警信息采取相应的应对措施,保证了高可用集群***的正常运行,有效避免了由于未及时采取应对措施而造成的损失,大大提高了高可用集群***的***性能。
Description
技术领域
本发明涉及计算机集群技术领域,尤其涉及一种高可用集群***,还涉及一种基于该高可用集群***的告警方法、告警***。
背景技术
随着通信网络技术的飞速发展,电信、金融、电子政务等关键领域对服务器可用性的要求越来越高,由服务器故障导致的停止提供服务将造成巨大的损失,采用高可用集群(HighAvailabilityCluster,HAC)***可以大幅提高***的可用性,把因软件、硬件、人为造成的故障对业务的影响降到最小程度。
高可用集群***是由集群软件监控、具有多台服务器互相冗余的***。此***通过集群软件提供的故障监测和故障处理能力,可提供业务连续性的能力。
现有技术中的高可用集群***包括一个主节点(也称为主控节点)以及至少一个从节点。一般来说,高可用集群***的高可用集群类告警信息存储在主节点的数据库中。当用户欲查阅高可用集群类告警信息时,需要首先登录主节点,然后从主节点的数据库中调出该类告警信息。
可以看出,针对现有技术中的高可用集群***,用户只能通过主节点查阅高可用集群类告警信息,而无法通过从节点查阅该类告警信息,灵活性差,可操作性差。另外,重要地,当主节点或者主节点的数据库出现故障时,用户则彻底无法查阅高可用集群***的高可用集群类告警信息,由此用户不能及时依据高可用集群类告警信息采取相应的应对措施,有可能造成重大损失。
发明内容
本发明所要解决的技术问题是:针对现有技术中的高可用集群***,用户只能通过主节点查阅高可用集群类告警信息,而无法通过从节点查阅该类告警信息,灵活性差,可操作差;另外,在主节点或者主节点的数据库出现故障时,用户则彻底无法查阅高可用集群***的高可用集群类告警信息,从而不能及时依据高可用集群类告警信息采取相应的应对措施,有可能造成重大损失。
为了解决上述技术问题,本发明提供了一种高可用集群***及基于该***的告警方法、告警***。
根据本发明的第一个方面,提供了一种高可用集群***,其包括:
主节点,所述主节点包括均用于存储告警信息的第一主数据库和第一辅助数据库;以及
至少一个从节点,每个所述从节点分别与所述主节点连接,每个所述从节点分别包括用于存储所述告警信息的第二辅助数据库。
根据本发明的第二个方面,提供了一种基于上述高可用集群***的告警方法,其包括:
监测所述高可用集群***的运行状态;
监测到所述高可用集群***出现高可用集群类故障时,生成高可用集群类告警信息;
将所述高可用集群类告警信息分别写入所述第一主数据库和所述第一辅助数据库;
将所述第一辅助数据库中的高可用集群类告警信息同步到各个所述第二辅助数据库中。
优选的是,所述高可用集群类告警信息包括均与所述高可用集群类故障相对应的故障标识和严重级别标识;
所述方法还包括:将所述高可用集群类告警信息呈现在所述高可用集群***的集群软件的页面上。
优选的是,上述告警方法还包括:
监测到所述高可用集群***出现操作***负载类故障时,生成操作***负载类告警信息;
将所述操作***负载类告警信息分别写入所述第一主数据库和所述第一辅助数据库中;
将所述第一辅助数据库中的操作***负载类告警信息同步到各个所述第二辅助数据库中。
优选的是,生成操作***负载类告警信息,包括:
根据预设的负载阈值和所述操作***类故障涉及的第一故障节点的操作***负载,确定与所述操作***负载类故障相对应的严重级别标识;
生成操作***负载类告警信息,并使所述操作***负载类告警信息包括均与所述操作***负载类故障相对应的故障标识和严重级别标识。
优选的是,上述告警方法还包括:
监测到所述高可用集群***出现第一主数据库类故障时,生成第一主数据库类告警信息;
根据所述第一主数据库类告警信息、以及均在所述第一主数据库类故障期间生成的所述高可用集群类告警信息和所述操作***负载类告警信息,得到待回写告警信息;
将所述待回写告警信息写入所述第一主数据库类故障涉及的第二故障节点的本地待回写告警信息日志中。
优选的是,所述第一主数据库类告警信息包括均与所述第一主数据库类故障相对应的故障标识和严重级别标识;
所述方法还包括:将所述待回写告警信息和所述第二故障节点的第二辅助数据库中的历史告警信息呈现在所述高可用集群***的集群软件的页面上。
优选的是,上述告警方法还包括:
监测到所述第一主数据库类故障消除时,将所述待回写告警信息日志中的所述待回写告警信息写入所述第一主数据库、所述第一辅助数据库和各个所述第二数据库中。
优选的是,将所述待回写告警信息日志中的所述待回写告警信息写入所述第一主数据库、所述第一辅助数据库和各个所述第二数据库中,包括:
依次对所述待回写告警信息中的每条待回写信息,判断所述待回写信息是否合法;
判断出所述待回写信息合法时,将所述待回写信息分别写入所述第一主数据库和所述第一辅助数据库中,并将所述第一辅助数据库中的所述待回写信息同步到各个第二辅助数据库中;
将所述待回写信息从所述待回写告警信息日志中删除。
优选的是,上述告警方法还包括:
累计未处理的告警信息的数目;
将所述数目呈现在所述高可用集群***的集群软件的各个页面上。
根据本发明的第三个方面,提供了一种基于上述高可用集群***的告警***,其利用上述告警方法进行告警。
与现有技术相比,上述方案中的一个或多个实施例可以具有如下优点或有益效果:
应用本发明实施例提供的高可用集群***,告警信息同时存储在第一主数据库、第一辅助数据库和各个第二辅助数据库中。在未发生数据库连接故障的情况下,上述各个数据库中存储的告警信息是一致的。因此,无论用户当前访问(登录)的是主节点还是任意一个从节点,都可以从当前访问的节点的数据库中获取告警信息。即便是在主节点或者主节点的数据库出现故障时,用户也可以从任意一个从节点的第二辅助数据库中获取到告警信息,从而能够及时依据获取的告警信息采取相应的应对措施,保证了高可用集群***的正常运行,有效避免了由于未及时采取采取应对措施而造成的损失,大大提高了高可用集群***的***性能。
本发明的其它特征和优点将在随后的说明书中阐述,并且部分地从说明书中变得显而易见,或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本发明的进一步理解,并且构成说明书的一部分,与本发明的实施例共同用于解释本发明,并不构成对本发明的限制。在附图中:
图1示出了本发明实施例高可用集群***的结构示意图;
图2示出了本发明实施例基于图1中所示的高可用集群***的告警方法的流程示意图;
图3示出了本发明实施例中监测到高可用集群***出现操作***负载类故障时的告警方法的流程示意图;
图4示出了本发明实施例中生成操作***负载类告警信息的方法的流程示意图;
图5示出了本发明实施例中监测到高可用集群***出现第一主数据库类故障时的告警方法的流程示意图;
图6示出了本发明实施例中监测到第一主数据库类故障消除时将第一主数据库类告警信息写入主从节点的各个数据库的方法的流程示意图;以及
图7示出了本发明实施例基于图1所示的高可用集群***的告警***的告警***的结构示意图。
具体实施方式
以下将结合附图及实施例来详细说明本发明的实施方式,借此对本发明如何应用技术手段来解决技术问题,并达成技术效果的实现过程能充分理解并据以实施。需要说明的是,只要不构成冲突,本发明中的各个实施例以及各实施例中的各个特征可以相互结合,所形成的技术方案均在本发明的保护范围之内。
本发明所要解决的技术问题是:针对现有技术中的高可用集群***,用户只能通过主节点查阅高可用集群类告警信息,而无法通过从节点查阅该类告警信息,灵活性差,可操作差;另外,在主节点或者主节点的数据库出现故障时,用户则彻底无法查阅高可用集群***的高可用集群类告警信息,从而不能及时依据高可用集群类告警信息采取相应的应对措施,有可能造成重大损失。为解决上述技术问题,本发明实施例提供了一种高可用集群***。
如图1所示,是本发明实施例高可用集群***的结构示意图。本实施例的高可用集群***包括主节点(也称为主控节点)和至少一个从节点,主节点与每个从节点连接。其中,主节点包括第一主数据库和第一辅助数据库,每个从节点分别包括一个第二辅助数据库。第一主数据库、第一辅助数据库和各个第二辅助数据库都用于存储各类告警信息。
具体地,第一主数据库采用Postgresql数据库,第一辅助数据库及第二辅助数据库均选用轻量级的SQLite数据库。高可用集群***的各个节点(主节点或者从节点)通过web接口将告警信息发送至主节点的第一主数据库和第一辅助数据库,同时开启辅助数据库存储线程,并利用SQLiteDBSync实现各个第二辅助数据库之间的数据同步分发。此外,高可用集群内的主节点和从节点均提供相关web服务,用户可登录各节点的web页面(即安装在各节点上的集群软件的页面),对集群进行有效管理。
可以看出,应用本实施例的高可用集群***,告警信息同时存储在第一主数据库、第一辅助数据库和各个第二辅助数据库中。在未发生数据库连接故障的情况下,上述各个数据库中存储的告警信息是一致的。因此,无论用户当前访问(登录)的是主节点还是任意一个从节点,都可以从当前访问的节点的数据库中获取告警信息。即便是在主节点或者主节点的数据库出现故障时,用户也可以从任意一个从节点的第二辅助数据库中获取到告警信息,从而能够及时依据获取的告警信息采取相应的应对措施,保证了高可用集群***的正常运行,有效避免了由于未及时采取采取应对措施而造成的损失,大大提高了高可用集群***的***性能。
相应地,本发明实施例还提供了一种基于上述高可用集群***的告警方法。
如图2所示,是本发明实施例基于高可用集群***的告警方法的流程示意图。本实施例所述的告警方法,主要包括以下步骤:
步骤101:监测高可用集群***的运行状态。
具体地,监测高可用集群***的运行状态具体涉及监测高可用集群***是否出现高可用集群类故障或者普通监控类故障。这里,高可用集群类故障包括心跳类故障、资源类故障和节点类故障。普通监控类故障包括操作***负载类故障和数据库类故障。在具体实施例过程中,针对不同种类的故障,需要编写相应的监测脚本,例如心跳监测脚本、资源监测脚本、节点监测脚本、操作***负载监测脚本和数据库监测脚本。
步骤102:监测到高可用集群***出现高可用集群类故障时,生成高可用集群类告警信息。
具体地,针对心跳监测告警部分,首先利用corosync-cfgtool-s命令获取故障心跳信息,并与历史数据相比较,如果故障心跳与历史数据不同,立即组装其相应的告警信息(即生成心跳类告警信息,其包括告警时间、告警类别、告警级别、告警详情等),并把该心跳类告警信息输出到高可用集群内所有节点的本地告警信息日志文件中。
针对资源监测告警部分,编写crm_mon_alarm.sh脚本,启动高可用集群服务后,后台执行crm_mon-d-E/usr/bin/crm_mon_alarm.sh,利用crm_mon获取的高可用集群运行资源状态,并将资源运行状态参数传递给crm_mon_alarm.sh脚本,该脚本负责分析相关参数,如果发现异常数据,则立即组装资源失败的告警信息(即生成资源类告警信息),并把该资源类告警信息输出到高可用集群内所有节点的本地告警信息日志文件中。
针对节点类告警信息,***首先利用crm_node-l命令获取节点丢失信息,并与历史数据相比较,如果丢失节点与历史数据不同,则立即组装其相应的告警信息(即生成节点类告警信息,其包括告警时间、告警类别、告警级别、告警详情等,并把该节点类告警信息输出到高可用集群内所有节点的本地告警信息日志文件中。
上述心跳类告警信息、资源类告警信息和节点类告警信息均属于高可用集群类告警信息。
步骤103:将高可用集群类告警信息分别写入第一主数据库和第一辅助数据库。
步骤104:将第一辅助数据库中的高可用集群类告警信息同步到各个第二辅助数据库中。
具体地,如果未监测到高可用集群***出现第一主数据库类故障(即高可用集群***的主节点或者从节点与第一主数据库的连接异常),则通过web接口将高可用集群类告警信息发送到主节点的第一主数据库和第一辅助数据库中。然后通过同步机制将第一辅助数据库中的高可用集群告警信息同步到高可用集群***的所有从节点的第二辅助数据库中。
应用本实施例所述的告警方法,监测到高可用集群***出现高可用集群类故障时,将生成的高可用集群类告警信息分别写入主节点的两个数据库中,然后通过同步机制将该信息同步到各个节点的数据库中。在未发生数据库连接故障的情况下,上述各个数据库中存储的告警信息是一致的。因此,无论用户当前访问(登录)的是主节点还是任意一个从节点,都可以从当前访问的节点的数据库中获取告警信息。即便是在主节点或者主节点的数据库出现故障时,用户也可以从任意一个从节点的第二辅助数据库中获取到告警信息,从而能够及时依据获取的告警信息采取相应的应对措施,保证了高可用集群***的正常运行,有效避免了由于未及时采取采取应对措施而造成的损失,大大提高了高可用集群***的***性能。
在现有技术中,高可用集群***的集群软件采用邮件告警的方式将告警信息发送给预设的告警联系人。当集群软件探测到***出现高可用集群类故障时,首先利用预先配置的告警模板生成告警信息,然后将告警信息发送到告警联系人的邮件中。可以看出,现有技术中的高可用集群***的集群软件采用的邮件告警方式将告警信息呈现给用户的缺陷在于:(1)当用户欲查阅告警信息时,用户无法通过集群软件的管理界面直接查阅告警信息,而是需要先登录告警联系人的邮件***,然后再通过邮件查阅,过程相对繁琐,不具有及时性。(2)由于告警信息的不可预知性,用户可能由于没有及时登录邮件***,导致无法及时查阅最新告警信息,从而没有及时采取相应的应对措施,有可能造成较大损失。
为了解决现有技术中的高可用集群***的集群软件采用邮件告警方式的将高可用集群类告警信息呈现给用户导致的技术缺陷,在本发明一优选的实施例中,上述告警方法还包括:将高可用集群类告警信息呈现在高可用集群***的集群软件的页面上,其中高可用集群类告警信息包括均与高可用集群类故障相对应的故障标识和严重级别标识。
具体地,心跳类故障对应的心跳类告警信息包括故障标识H(H为Heartbeat的简写)和严重级别标识。资源类故障对应的资源类告警信息包括故障标识R(R为Resorce的简写)和严重级别标识。节点类故障对应的节点类告警信息包括故障标识N(N为Node的简写)和严重级别标识。
本实施例根据告警信息的安全级别,将其分为严重级和普通级两类。为了使前端界面获得较好的显示效果,其告警图标结合故障标识、后缀数字和颜色的设计模式。告警图标采用红色来表示严重级,用黄色表示普通级。由后缀数字“0”表示的严重级别标识代表严重级告警信息,由后缀数字“1”表示的严重级别标识代表普通级告警信息。以节点类告警信息为例,故障标识为“N”,然后根据节点类告警信息形成的原因,自定义其严重级别标识。比如当前节点类故障的严重级别为严重级,则该故障对应的严重级别标识为0,则最终呈现在用户界面上的图标为红色字体的“N0”。其它类告警信息类似,不再做详细说明。
应用本实施例,采用简单明了的图标将高可用集群类告警信息直观地呈现在用户界面上,使得用户能够在第一时间了解***的运行状态。并且,用户能够及时根据快速获知的告警信息采用相应的应对措施,最大程度地减少或避免了可能造成的损失。
进一步地,被存储在高可用集群***的各个数据库的高可用集群类告警信息除了上述均与高可用集群类故障相对应的故障标识和严重级别标识外,还包括故障来源标识。具体地,针对数据库存储的告警信息level字段,高可用集群***采用统一格式编码,即采用三个有效字符的字符串来表示。其第一位表示故障来源标识,“1”表示高可用集群类告警信息,而“0”表示诸如操作***负载类告警信息或者数据库类告警信息的普通监控类告警信息。其第二位表示故障标识。其第三位表示严重级别标识,“0”表示严重级告警信息,“1”表示普通级告警信息。当高可用集群部署完毕,其周期性的执行相对应的脚本,监测集群资源、集群心跳、集群节点的信息,如果发现异常,立即创建相对应的高可用集群类告警信息。例如,如发现高可用集群资源启动失败的信息,规定其严重级别为严重级,故高可用集群类告警信息的level标示为“1R0”,然后结合其它信息字段,将该高可用集群类告警信息写入各节点的数据库中。
此外,在高可用集群类***的各个节点的本地告警信息日志文件中,告警信息level标示却用四个有效字符的字符串来表示,前三位与数据库中存储的告警信息level内容相同,第四位表示当前节点与主节点的第一主数据库的连接状态,“0”表示连接正常,“1”表示连接异常。
在本发明一优选的实施例中,高可用集群***除了实时监测常规的高可用集群类故障外,还实时监测操作***负载类故障。这里,操作***负载例如为CPU负载等。
如图3所示,是本发明实施例中监测到高可用集群***出现操作***负载类故障时的告警方法的流程示意图。本实施例监测到高可用集群***出现操作***负载类故障时的告警方法,主要包括以下步骤:
步骤201:监测到高可用集群***出现操作***负载类故障时,生成操作***负载类告警信息。
具体地,本步骤中生成操作***负载类告警信息的方法将在下文中进行详细地阐述。
步骤202:将操作***负载类告警信息分别写入第一主数据库和第一辅助数据库中。
步骤203:将第一辅助数据库中的操作***负载类告警信息同步到各个第二辅助数据库中。
如图4所示,是本发明实施例中生成操作***负载类告警信息的方法的流程示意图。本实施例所述的生成操作***负载类告警信息的方法,主要包括以下步骤:
步骤301:根据预设的负载阈值和操作***类故障涉及的第一故障节点的操作***负载,确定与操作***负载类故障相对应的严重级别标识。
步骤302:生成操作***负载类告警信息,并使操作***负载类告警信息包括均与操作***负载类故障相对应的故障标识和严重级别标识。
具体地,对于操作***负载类故障的判断,需要事先在***中预设的负载阈值。具体地,通过比较监测到***中某个节点的操作***负载与预设的负载阈值的大小关系,确定高可用集群***是否出现了操作***负载类故障。需要在***中保存预设的第一负载阈值和第二负载阈值,第一负载阈值大于第二负载阈值。当***中的某个节点的操作***负载大于第二负载阈值且小于第一负载阈值时,则立即生成严重级别较低的操作***负载类告警信息(其严重级别标识为1),优选地发出黄灯信号,以警示用户该节点发生严重级别较低的操作***负载类故障。类似地,当***中的某个节点的操作***负载大于第一负载阈值时,则立即生成严重级别较高的操作***负载类告警信息(其严重级别标识为0),优选地发生红灯信号,以警示用户该节点发生严重级别较高的操作***负载类故障。
需要指出的是,上述操作***负载也可以指代空闲内存或者磁盘使用量,当然,当判断是否出现操作***负载类故障时,需要判断此类负载是否低于相应的负载阈值。具体地,对于空闲内存来说,其相应的负载阈值为第三负载阈值和第四负载阈值,第三负载阈值大于第四负载阈值。当***中的某个节点的空闲内存大于第四负载阈值且小于第三负载阈值时,则立即生成严重级别较低的操作***负载类告警信息(其严重级别标识为1),优选地发出黄灯信号,以警示用户该节点发生严重级别较低的操作***负载类故障。类似地,当***中的某个节点的空闲内存小于第四负载阈值时,则立即生成严重级别较高的操作***负载类告警信息(其严重级别标识为0),优选地发生红灯信号,以警示用户该节点发生严重级别较高的操作***负载类故障。
另外,操作***负载类告警信息包括故障标识OS(OS为OperationSystem的简写)和严重级别标识。类似于高可用集群类告警信息的显示,本实施例所述的方法还包括:将操作***负载类告警信息呈现在高可用集群***的集群软件的页面上。例如,经比较确定当前操作***负载类故障的严重级别为严重级,则该故障对应的严重级别标识为0,则最终呈现在用户界面上的图标为红色字体的“OS0”。这样,采用简单明了的图标将操作***负载类告警信息直观地呈现在用户界面上,使得用户能够在第一时间了解***的运行状态。并且,用户能够及时根据快速获知的告警信息采用相应的应对措施,最大程度地减少或避免了可能造成的损失。
进一步地,被存储在高可用集群***的各个数据库的操作***负载类告警信息除了上述均与操作***负载类故障相对应的故障标识和严重级别标识外,还包括故障来源标识。例如,严重级别较高的操作***负载类告警信息的level标示为“0OS0”。
应用本实施例所述的告警方法,告警信息除了涉及高可用集群类告警信息,还涉及操作***负载类告警信息。当发生操作***负载类故障时,***能够及时地将此类故障反映给用户,从而用户能够及时采取相应的应对措施,有效减少或避免有可能造成的损失。
在本发明一优选的实施例中,高可用集群***除了实时监测操作***负载类故障和常规的高可用集群类故障外,还实时监测数据库类故障,尤其是第一主数据库类故障。这里,第一主数据库类故障表示高可用集群***中的节点(主节点或者从节点)与主节点的第一主数据库的连接异常的故障。节点与第一主数据库的连接异常通常涉及两方面原因,一是节点与第一主数据库之间的通讯线路断开,二是第一主数据库本身关闭或者出现故障。
如图5所示,是本发明实施例中监测到高可用集群***出现第一主数据库类故障时的告警方法的流程示意图。本实施例监测到高可用集群***出现第一主数据库类故障时的告警方法,主要包括以下步骤:
步骤401:监测到高可用集群***出现第一主数据库类故障时,生成第一主数据库类告警信息。
步骤402:根据第一主数据库类告警信息、以及均在第一主数据库类故障期间生成的高可用集群类告警信息和操作***负载类告警信息,得到待回写告警信息。
步骤403:将待回写告警信息写入第一主数据库类故障涉及的第二故障节点的本地待回写告警信息日志中。
具体地,当高可用集群***中的某个节点无法连接第一主数据库时,即出现第一主数据库类故障时,首先生成第一主数据库类告警信息。然后结合在第一主数据库类故障未消除期间(即节点无法连接第一主数据库期间)生成的所有告警信息(高可用集群类告警信息和/或操作***负载类告警信息),得到待回写告警信息。最后将得到的待回写告警信息分别写入出现该第一主数据库类故障的第二故障节点的本地告警信息日志文件和本地待回写告警信息日志文件中。
应用本实施例所述的告警方法,当监测到高可用集群***中的某个节点与第一主数据库连接异常时,即当监测到出现第一主数据库类故障时,将故障期间生成的所有告警信息暂存在与第一主数据库连接异常的那个节点(即第一主数据库类故障涉及的第二故障节点)的待回写告警信息日志文件中。在第一主数据库类故障尚未解除之前,用户登录上述第二故障节点,可以查阅到完整的告警信息。这里,完整的告警信息包括待回写告警信息日志文件中的告警信息以及存储于第二故障节点的第二辅助库中存储的历史告警信息。总而言之,本实施例所述的告警方法,有效保证了告警信息的完整性,进一步提高了高可用集群***的***性能。
另外,第一主数据库类告警信息包括故障标识D(D为DataBase的简写)和严重级别标识。类似于高可用集群类告警信息的显示,本实施例所述的方法还包括:将待回写告警信息和第二故障节点的第二辅助数据库中的历史告警信息呈现在高可用集群***的集群软件的页面上。例如,对于严重级别较高的第一主数据库类故障,该故障对应的严重级别标识为0,则最终呈现在用户界面上的图标为红色字体的“D0”。这样,采用简单明了的图标将第一主数据库类告警信息直观地呈现在用户界面上,使得用户能够在第一时间了解***的运行状态。并且,用户能够及时根据快速获知的告警信息采用相应的应对措施,最大程度地减少或避免了可能造成的损失。
进一步地,被存储在高可用集群***的各个数据库的第一主数据库类告警信息除了上述均与第一主数据库类故障相对应的故障标识和严重级别标识外,还包括故障来源标识。例如,严重级别较高的第一主数据库类告警信息的level标示为“0D0”。
在本发明一优选的实施例中,仍参照图5,上述监测到高可用集群***出现第一主数据库类故障时的告警方法还包括:
步骤404:监测到第一主数据库类故障消除时,将待回写告警信息日志中的待回写告警信息写入第一主数据库、第一辅助数据库和各个第二数据库中。
下面将结合图6详细阐述将待回写告警信息日志文件中的所有待回写信息写入高可用集群***的所有节点的所有数据库中的方法。该方法主要包括以下步骤:
步骤501:获取待回写告警信息中的第一条待回写信息。
步骤502:判断该条待回写信息是否合法。
步骤503:判断出待回写信息合法时,将待回写信息分别写入第一主数据库和第一辅助数据库中,并将第一辅助数据库中的待回写信息同步到各个第二辅助数据库中。判断出待回写信息非法时,执行步骤504。
步骤504:将待回写信息从待回写告警信息日志中删除。
步骤505:判断待回写告警信息日志是否为空。
步骤506:判断出待回写告警信息日志为空时退出。判断出待回写告警信息日志非空时,顺序执行步骤501至步骤506。
具体地,当第二故障节点与第一主数据库连接正常后,需要将第一主数据库类故障期间暂存于第二故障节点的本地待回写告警信息日志文件中的所有待回写信息回写到各个数据库中。针对此回写脚本:首先打开待回写告警信息日志文件(其文件属性为隐藏文件),然后逐条读出文件中的待回写信息。待获取该条待回写信息后,用正则表达式获取该条待回写信息是否合法(即检测产生该待回写信息时第二故障节点与第一主数据库的连接状态,如果连接状态为异常,则该条待回写信息合法,否则非法)。如果判断出该条待回写信息合法,则采用正则表达式获取此待回写信息的各个字段,然后重新组合,并将该条待回写信息写入高可用集群***的各个节点的各个数据库中。之后在写入成功后,在待回写告警信息日志中删除此条待回写信息,然后在本地告警信息日志文件中修改此条待回写信息的level标示。利用上述方法逐条地将待回写告警信息日志文件中的所有待回写信息都写入各数据库中,直到待回写告警信息日志文件为空为止。
应用本实施例所述的告警方法,一旦监测到第二故障节点与第一主数据库的连接恢复正常时,即一旦监测到上述第一主数据库类故障解除时,立即将暂存于第二故障节点的本地待回写告警信息日志文件中的所有待回写信息写入高可用集群***的所有节点的所有数据库中。因此,在第一主数据库类故障解除后,用户可以登录高可用集群***的任意一个节点查阅完整的告警信息,在保证告警信息的完整性的基础上,保证了各个节点保存的告警信息的一致性,进一步提高了高可用集群***的***性能。
另外,应用本实施例所述的告警方法,告警信息除了涉及高可用集群类告警信息,还涉及第一主数据库类告警信息。当发生第一主数据库类故障时,***能够及时地将此类故障反映给用户,从而用户能够及时采取相应的应对措施,有效减少或避免有可能造成的损失。
为了进一步提高告警信息呈现的及时性,在本发明一优选的实施例中,上面各个实施例所述的告警方法还包括:累计未处理的各类告警信息的数目,然后将数目呈现在高可用集群***的集群软件的各个页面上。
在本实施例中,将未处理的各类告警信息(高可用集群类告警信息、操作***负载类告警信息或者第一主数据库类告警信息)的累计数目镶嵌在高可用集群服务***的框架上,保证用户在高可用集群***的集群软件的各个页面上均可以看到未处理告警信息的数目。这样,用户一旦观察到当前页面上显示的未处理告警信息的数目发生变化,就可以及时发现当前高可用集群***运行异常,然后进入告警中心查看详细告警信息,根据信息内容采取相对应的解决措施,避免造成重大损失。
相对应地,本发明实施例还提供了一种基于图1所示的高可用集群***的告警***,该告警***利用上面各实施例所述的告警方法进行告警。
如图7所示,是本发明实施例基于图1所示的高可用集群***的告警***的告警***的结构示意图。本实施例所述的告警***包括顺次连接的监测模块601、高可用集群类告警信息生成模块602、第一写入模块603和第一同步模块604。
具体地,监测模块601,设置为监测高可用集群***的运行状态。
高可用集群类告警信息生成模块602,设置为在监测模块601监测到高可用集群***出现高可用集群类故障时,生成高可用集群类告警信息。
第一写入模块603,设置为将高可用集群类告警信息分别写入第一主数据库和第一辅助数据库。
第一同步模块604,设置为将第一辅助数据库中的高可用集群类告警信息同步到各个第二辅助数据库中。
在本实施例中,高可用集群类告警信息包括均与高可用集群类故障相对应的故障标识和严重级别标识。上述告警***还包括:第一呈现模块,将高可用集群类告警信息呈现在高可用集群***的集群软件的页面上。
在本实施例中,上述告警***还包括顺次连接的操作***负载类告警信息生成模块、第二写入模块和第二同步模块。
具体地,操作***负载类告警信息生成模块,设置为在监测模块601监测到高可用集群***出现操作***负载类故障时,生成操作***负载类告警信息。
第二写入模块,设置为将操作***负载类告警信息分别写入第一主数据库和第一辅助数据库中。
第二同步模块,设置为将第一辅助数据库中的操作***负载类告警信息同步到各个第二辅助数据库中。
在本实施例中,操作***负载类告警信息生成模块包括彼此连接的严重级别标识确定单元和操作***负载类告警信息生成单元。
具体地,严重级别标识确定单元,设置为根据预设的负载阈值和操作***类故障涉及的第一故障节点的操作***负载,确定与操作***负载类故障相对应的严重级别标识。
操作***负载类告警信息生成单元,设置为生成操作***负载类告警信息,并使操作***负载类告警信息包括均与操作***负载类故障相对应的故障标识和严重级别标识。
在本实施例中,上述告警***还包括顺次连接的第一主数据库类告警信息生成模块、待回写告警信息确定模块和第三写入模块。
具体地,第一主数据库类告警信息生成模块,设置为在监测模块601监测到高可用集群***出现第一主数据库类故障时,生成第一主数据库类告警信息。
待回写告警信息确定模块,设置为根据第一主数据库类告警信息、以及均在第一主数据库类故障期间生成的高可用集群类告警信息和操作***负载类告警信息,得到待回写告警信息。
第三写入模块,设置为将待回写告警信息写入第一主数据库类故障涉及的第二故障节点的本地待回写告警信息日志中。
在本实施例中,第一主数据库类告警信息包括均与第一主数据库类故障相对应的故障标识和严重级别标识。上述告警***还包括:第二呈现模块,将待回写告警信息和第二故障节点的第二辅助数据库中的历史告警信息呈现在高可用集群***的集群软件的页面上。
在本实施例中,上述告警***还包括:第四写入模块,在监测模块601监测到第一主数据库类故障消除时,将待回写告警信息日志中的待回写告警信息写入第一主数据库、第一辅助数据库和各个第二数据库中。
在本实施例中,上述第四写入模块包括顺次连接的判断单元、写入单元和删除单元。
具体地,判断单元,设置为依次对待回写告警信息中的每条待回写信息,判断待回写信息是否合法。
写入单元,设置为在判断单元判断出待回写信息合法时,将待回写信息分别写入第一主数据库和第一辅助数据库中,并将第一辅助数据库中的待回写信息同步到各个第二辅助数据库中。
删除单元,设置为在写入单元将待回写信息分别写入第一主数据库和第一辅助数据库中,并将第一辅助数据库中的待回写信息同步到各个第二辅助数据库中后,将待回写信息从待回写告警信息日志中删除。删除单元还设置为:在判断单元判断出待回写信息非法时,将待回写信息从待回写告警信息日志中删除。
在本实施例中,上述告警***还包括连接的累计模块和第三呈现模块。
具体地,累计模块,设置为累计未处理的告警信息的数目。
第三呈现模块,设置为将数目呈现在高可用集群***的集群软件的各个页面上。
上述各模块中的操作的具体细化,可参见上面结合图1对高可用集群***的结构说明以及结合图2至图6对告警方法的说明,在此不再详细赘述。
应用本实施例所述的告警***,监测到高可用集群***出现高可用集群类故障时,将生成的高可用集群类告警信息分别写入主节点的两个数据库中,然后通过同步机制将该信息同步到各个节点的数据库中。在未发生数据库连接故障的情况下,上述各个数据库中存储的告警信息是一致的。因此,无论用户当前访问(登录)的是主节点还是任意一个从节点,都可以从当前访问的节点的数据库中获取告警信息。即便是在主节点或者主节点的数据库出现故障时,用户也可以从任意一个从节点的第二辅助数据库中获取到告警信息,从而能够及时依据获取的告警信息采取相应的应对措施,保证了高可用集群***的正常运行,有效避免了由于未及时采取采取应对措施而造成的损失,大大提高了高可用集群***的***性能。
为了进一步地阐述本发明,下面详细说明高可用集群***的配置过程以及基于该***的告警方法的验证过程。
本实施例采用高可用集群双机主备模式,并选择其中一个节点为主节点,即高可用集群***包括一个主节点和一个从节点。主节点和从节点之间选用双心跳直连模式,有效避免了脑裂现象的发生。
在安装完毕高可用集群***的集群软件后,需要在主节点初始化数据库等操作,并做辅助数据库的同步设置。然后,启动集群web相关服务后,用户登录高可用集群***的集群软件的管理页面。用户首先添加高可用集群,然后将主节点和从节点添加到刚创建的高可用集群中。然后配置该集群和心跳等信息。然后启动集群,启动集群内的主节点和从节点。随后,高可用集群***中的主节点和从节点均处于运行状态,用户可选择性部署操作***负载类故障监测脚本,过程中用户需设置相应的负载阈值。同时,用户可添加其它相关资源,然后运行新添加的资源。
针对告警信息的不可预知性,为了验证告警***的功能,采用模拟集群各类故障的方法,从而产生各相对应的信息,并验证告警信息的完整性和一致性。
首先,在未出现第一主数据库类故障的情况下进行高可用集群类故障和操作***负载类故障的相关测试。具体地,用户可通过修改添加资源配置参数等方法,获取资源类告警信息。用户也通过断开心跳连接线的方法获取心跳类告警信息和节点类告警信息。同时,如果已部署操作***负载监测脚本,用户也可通过对节眯进行加压测试,使得当前节点负载高于(或低于)设定的负载阈值,从而产生操作***负载类告警信息。待***监测到上述各类故障后,用户可查阅相应告警信息是否正确。
其次,在出现第一主数据库类故障的情况下进行相关测试。用户可停止第一主数据库的服务,然后在高可用集群***上模拟资源类、心跳类、节点类和操作***负载类故障。用户登录出现故障的节点所提供的web服务页面中,可查看到第一主数据库类故障期间产生的告警信息。同时,查看故障节点的本地告警信息日志文件和待回写告警信息日志文件,均可以查阅相应告警信息是否正确。
然后解除第一主数据库类故障,此时暂存于上述故障节点的本地待回写告警信息日志文件中的信息应全部写入高可用集群***的所有节点的数据库中。用户可任意登录一个节点,通过查阅保存在该节点的数据库中的告警信息验证该告警信息的完整性和一致性(用户可以用数据库查询语句判断是否成功写入)。
本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
虽然本发明所公开的实施方式如上,但所述的内容只是为了便于理解本发明而采用的实施方式,并非用以限定本发明。任何本发明所属技术领域内的技术人员,在不脱离本发明所公开的精神和范围的前提下,可以在实施的形式上及细节上作任何的修改与变化,但本发明的保护范围,仍须以所附的权利要求书所界定的范围为准。
Claims (11)
1.一种高可用集群***,其特征在于,包括:
主节点,所述主节点包括均用于存储告警信息的第一主数据库和第一辅助数据库;以及
至少一个从节点,每个所述从节点分别与所述主节点连接,每个所述从节点分别包括用于存储所述告警信息的第二辅助数据库。
2.一种基于如权利要求1所述的高可用集群***的告警方法,其特征在于,包括:
监测所述高可用集群***的运行状态;
监测到所述高可用集群***出现高可用集群类故障时,生成高可用集群类告警信息;
将所述高可用集群类告警信息分别写入所述第一主数据库和所述第一辅助数据库;
将所述第一辅助数据库中的高可用集群类告警信息同步到各个所述第二辅助数据库中。
3.根据权利要求2所述的方法,其特征在于,所述高可用集群类告警信息包括均与所述高可用集群类故障相对应的故障标识和严重级别标识;
所述方法还包括:将所述高可用集群类告警信息呈现在所述高可用集群***的集群软件的页面上。
4.根据权利要求2所述的方法,其特征在于,还包括:
监测到所述高可用集群***出现操作***负载类故障时,生成操作***负载类告警信息;
将所述操作***负载类告警信息分别写入所述第一主数据库和所述第一辅助数据库中;
将所述第一辅助数据库中的操作***负载类告警信息同步到各个所述第二辅助数据库中。
5.根据权利要求4所述的方法,其特征在于,生成操作***负载类告警信息,包括:
根据预设的负载阈值和所述操作***类故障涉及的第一故障节点的操作***负载,确定与所述操作***负载类故障相对应的严重级别标识;
生成操作***负载类告警信息,并使所述操作***负载类告警信息包括均与所述操作***负载类故障相对应的故障标识和严重级别标识。
6.根据权利要求4所述的方法,其特征在于,还包括:
监测到所述高可用集群***出现第一主数据库类故障时,生成第一主数据库类告警信息;
根据所述第一主数据库类告警信息、以及均在所述第一主数据库类故障期间生成的所述高可用集群类告警信息和所述操作***负载类告警信息,得到待回写告警信息;
将所述待回写告警信息写入所述第一主数据库类故障涉及的第二故障节点的本地待回写告警信息日志中。
7.根据权利要求6所述的方法,其特征在于,所述第一主数据库类告警信息包括均与所述第一主数据库类故障相对应的故障标识和严重级别标识;
所述方法还包括:将所述待回写告警信息和所述第二故障节点的第二辅助数据库中的历史告警信息呈现在所述高可用集群***的集群软件的页面上。
8.根据权利要求6所述的方法,其特征在于,还包括:
监测到所述第一主数据库类故障消除时,将所述待回写告警信息日志中的所述待回写告警信息写入所述第一主数据库、所述第一辅助数据库和各个所述第二数据库中。
9.根据权利要求8所述的方法,其特征在于,将所述待回写告警信息日志中的所述待回写告警信息写入所述第一主数据库、所述第一辅助数据库和各个所述第二数据库中,包括:
依次对所述待回写告警信息中的每条待回写信息,判断所述待回写信息是否合法;
判断出所述待回写信息合法时,将所述待回写信息分别写入所述第一主数据库和所述第一辅助数据库中,并将所述第一辅助数据库中的所述待回写信息同步到各个第二辅助数据库中;
将所述待回写信息从所述待回写告警信息日志中删除。
10.根据权利要求2至9中任一项所述的方法,其特征在于,还包括:
累计未处理的告警信息的数目;
将所述数目呈现在所述高可用集群***的集群软件的各个页面上。
11.一种基于如权利要求1所述的高可用集群***的告警***,其特征在于,所述告警***利用权利要求2至10中任一项所述的告警方法进行告警。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510387184.6A CN105138441B (zh) | 2015-06-30 | 2015-06-30 | 高可用集群***及基于该***的告警方法、告警*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510387184.6A CN105138441B (zh) | 2015-06-30 | 2015-06-30 | 高可用集群***及基于该***的告警方法、告警*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105138441A true CN105138441A (zh) | 2015-12-09 |
CN105138441B CN105138441B (zh) | 2018-05-08 |
Family
ID=54723796
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510387184.6A Active CN105138441B (zh) | 2015-06-30 | 2015-06-30 | 高可用集群***及基于该***的告警方法、告警*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105138441B (zh) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106301938A (zh) * | 2016-08-25 | 2017-01-04 | 成都索贝数码科技股份有限公司 | 一种高可用性和强一致性的数据库集群***及其节点管理方法 |
CN106407264A (zh) * | 2016-08-25 | 2017-02-15 | 成都索贝数码科技股份有限公司 | 一种高可用性和强一致性的数据库集群***及其命令处理方法 |
CN106502835A (zh) * | 2016-10-26 | 2017-03-15 | ***股份有限公司 | 一种容灾备份方法及装置 |
CN106506255A (zh) * | 2016-09-21 | 2017-03-15 | 微梦创科网络科技(中国)有限公司 | 一种压力测试的方法、装置及*** |
CN107153660A (zh) * | 2016-03-04 | 2017-09-12 | 福建天晴数码有限公司 | 分布式数据库***的故障检测处理方法及其*** |
CN107229539A (zh) * | 2017-05-31 | 2017-10-03 | 郑州云海信息技术有限公司 | 一种用于磁盘镜像高可用集群diskless的处理方法和*** |
CN108900353A (zh) * | 2018-07-18 | 2018-11-27 | 平安科技(深圳)有限公司 | 故障告警方法及终端设备 |
CN110780134A (zh) * | 2019-10-30 | 2020-02-11 | 深圳市国电科技通信有限公司 | 一种提升工控类数据采集***可靠性的***优化方法 |
CN110806917A (zh) * | 2019-09-19 | 2020-02-18 | 烽火通信科技股份有限公司 | 一种防脑裂的虚拟机高可用的管理装置及方法 |
CN111158962A (zh) * | 2018-11-07 | 2020-05-15 | 中移信息技术有限公司 | 一种异地容灾方法、装置、***、电子设备及存储介质 |
CN112131077A (zh) * | 2020-09-21 | 2020-12-25 | 中国建设银行股份有限公司 | 故障节点的定位方法和定位装置、以及数据库集群*** |
CN112214377A (zh) * | 2020-10-21 | 2021-01-12 | 新华三信息安全技术有限公司 | 一种设备管理方法及*** |
CN115174356A (zh) * | 2022-07-27 | 2022-10-11 | 济南浪潮数据技术有限公司 | 一种集群告警上报方法、装置、设备及介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1489052A (zh) * | 2002-10-11 | 2004-04-14 | 鸿富锦精密工业(深圳)有限公司 | 多节点文件同步***及方法 |
CN102254031A (zh) * | 2011-08-03 | 2011-11-23 | 无锡浙潮科技有限公司 | 基于批处理请求的Microsoft SQL Server数据库集群 |
CN103294752A (zh) * | 2012-01-30 | 2013-09-11 | 国际商业机器公司 | 日志传送物理复制环境中备用数据库的在线验证方法和*** |
CN104504062A (zh) * | 2014-12-22 | 2015-04-08 | 浙江宇视科技有限公司 | 主备数据库数据同步方法及装置 |
-
2015
- 2015-06-30 CN CN201510387184.6A patent/CN105138441B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1489052A (zh) * | 2002-10-11 | 2004-04-14 | 鸿富锦精密工业(深圳)有限公司 | 多节点文件同步***及方法 |
CN102254031A (zh) * | 2011-08-03 | 2011-11-23 | 无锡浙潮科技有限公司 | 基于批处理请求的Microsoft SQL Server数据库集群 |
CN103294752A (zh) * | 2012-01-30 | 2013-09-11 | 国际商业机器公司 | 日志传送物理复制环境中备用数据库的在线验证方法和*** |
CN104504062A (zh) * | 2014-12-22 | 2015-04-08 | 浙江宇视科技有限公司 | 主备数据库数据同步方法及装置 |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107153660A (zh) * | 2016-03-04 | 2017-09-12 | 福建天晴数码有限公司 | 分布式数据库***的故障检测处理方法及其*** |
CN107153660B (zh) * | 2016-03-04 | 2020-03-17 | 福建天晴数码有限公司 | 分布式数据库***的故障检测处理方法及其*** |
CN106301938A (zh) * | 2016-08-25 | 2017-01-04 | 成都索贝数码科技股份有限公司 | 一种高可用性和强一致性的数据库集群***及其节点管理方法 |
CN106407264A (zh) * | 2016-08-25 | 2017-02-15 | 成都索贝数码科技股份有限公司 | 一种高可用性和强一致性的数据库集群***及其命令处理方法 |
CN106506255A (zh) * | 2016-09-21 | 2017-03-15 | 微梦创科网络科技(中国)有限公司 | 一种压力测试的方法、装置及*** |
CN106506255B (zh) * | 2016-09-21 | 2019-11-05 | 微梦创科网络科技(中国)有限公司 | 一种压力测试的方法、装置及*** |
CN106502835A (zh) * | 2016-10-26 | 2017-03-15 | ***股份有限公司 | 一种容灾备份方法及装置 |
CN107229539A (zh) * | 2017-05-31 | 2017-10-03 | 郑州云海信息技术有限公司 | 一种用于磁盘镜像高可用集群diskless的处理方法和*** |
WO2020015115A1 (zh) * | 2018-07-18 | 2020-01-23 | 平安科技(深圳)有限公司 | 故障告警方法及终端设备 |
CN108900353A (zh) * | 2018-07-18 | 2018-11-27 | 平安科技(深圳)有限公司 | 故障告警方法及终端设备 |
CN111158962A (zh) * | 2018-11-07 | 2020-05-15 | 中移信息技术有限公司 | 一种异地容灾方法、装置、***、电子设备及存储介质 |
CN111158962B (zh) * | 2018-11-07 | 2023-10-13 | 中移信息技术有限公司 | 一种异地容灾方法、装置、***、电子设备及存储介质 |
CN110806917A (zh) * | 2019-09-19 | 2020-02-18 | 烽火通信科技股份有限公司 | 一种防脑裂的虚拟机高可用的管理装置及方法 |
CN110780134A (zh) * | 2019-10-30 | 2020-02-11 | 深圳市国电科技通信有限公司 | 一种提升工控类数据采集***可靠性的***优化方法 |
CN112131077A (zh) * | 2020-09-21 | 2020-12-25 | 中国建设银行股份有限公司 | 故障节点的定位方法和定位装置、以及数据库集群*** |
CN112214377A (zh) * | 2020-10-21 | 2021-01-12 | 新华三信息安全技术有限公司 | 一种设备管理方法及*** |
CN112214377B (zh) * | 2020-10-21 | 2022-09-27 | 新华三信息安全技术有限公司 | 一种设备管理方法及*** |
CN115174356A (zh) * | 2022-07-27 | 2022-10-11 | 济南浪潮数据技术有限公司 | 一种集群告警上报方法、装置、设备及介质 |
CN115174356B (zh) * | 2022-07-27 | 2024-06-14 | 郑州浪潮数据技术有限公司 | 一种集群告警上报方法、装置、设备及介质 |
Also Published As
Publication number | Publication date |
---|---|
CN105138441B (zh) | 2018-05-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105138441A (zh) | 高可用集群***及基于该***的告警方法、告警*** | |
CN106331098B (zh) | 一种服务器集群*** | |
CN107343034B (zh) | 基于QConf的Redis高可用***及方法 | |
US9842033B2 (en) | Storage cluster failure detection | |
US8667096B2 (en) | Automatically generating system restoration order for network recovery | |
US20050188283A1 (en) | Node management in high-availability cluster | |
CN100426751C (zh) | 保证集群***中配置信息一致的方法 | |
CN103812699A (zh) | 基于云计算的监控管理*** | |
US20100223609A1 (en) | Systems and methods for automatic discovery of network software relationships | |
CN112506702B (zh) | 数据中心容灾方法、装置、设备及存储介质 | |
CN102664747B (zh) | 一种云计算平台*** | |
US7464302B2 (en) | Method and apparatus for expressing high availability cluster demand based on probability of breach | |
CN108616574B (zh) | 管理数据的存储方法、设备及存储介质 | |
CN111949444A (zh) | 一种基于分布式服务集群的数据备份与恢复***及方法 | |
CN110545203B (zh) | 云平台创建初始资源备份池和云平台自愈修复的方法 | |
CN105389231A (zh) | 一种数据库双机备份方法及*** | |
CN107357800A (zh) | 一种数据库高可用零丢失解决方法 | |
CN113901047A (zh) | 一种基于内存数据库的简便集群主从选举方法 | |
WO2018076696A1 (zh) | 一种数据同步方法及带外管理设备 | |
CN109039723A (zh) | 基于数据库集群的网络维护方法及*** | |
CN111404737B (zh) | 一种容灾处理方法以及相关装置 | |
CN109104333B (zh) | 基于git的分布式集群的同步方法和装置 | |
CN104503871A (zh) | 一种基于小型机***全冗余模型的实现方法 | |
CN107590032A (zh) | 存储集群故障转移的方法及存储集群*** | |
CN112667440A (zh) | 一种高可用MySQL的异地灾备方法 |
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 |