CN110377487A - 一种处理高可用集群脑裂的方法及装置 - Google Patents

一种处理高可用集群脑裂的方法及装置 Download PDF

Info

Publication number
CN110377487A
CN110377487A CN201910622641.3A CN201910622641A CN110377487A CN 110377487 A CN110377487 A CN 110377487A CN 201910622641 A CN201910622641 A CN 201910622641A CN 110377487 A CN110377487 A CN 110377487A
Authority
CN
China
Prior art keywords
node
house dog
dog component
availability cluster
data
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.)
Pending
Application number
CN201910622641.3A
Other languages
English (en)
Inventor
吴业亮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wuxi Huayun Data Technology Service Co Ltd
Original Assignee
Wuxi Huayun Data Technology Service Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Wuxi Huayun Data Technology Service Co Ltd filed Critical Wuxi Huayun Data Technology Service Co Ltd
Priority to CN201910622641.3A priority Critical patent/CN110377487A/zh
Publication of CN110377487A publication Critical patent/CN110377487A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提供了一种处理高可用集群脑裂的方法及装置，该方法包括：在高可用集群所配置的节点中部署看门狗组件，通过所述看门狗组件侦测对应节点中业务单元的状态数据，并将高可用集群中各个节点所部署的看门狗组件建立同步连接，当看门狗组件侦测到对应节点中业务单元的状态数据发生异常时，看门狗组件触发对对应节点的冻结事件。通过本发明所揭示的一种处理高可用集群脑裂的方法及装置，实现了及时发现高可用集群所配置的节点失效所导致的脑裂现象的技术效果，并能够在失效节点恢复后对各个节点之间数据执行同步处理，从而保证了高可用集群中各个节点中数据的强一致性，避免了对权限及资源的无序争夺。

Description

一种处理高可用集群脑裂的方法及装置
技术领域
本发明涉及云计算技术领域，尤其涉及一种处理高可用集群脑裂的方法以及一种处理高可用集群脑裂的装置。
背景技术
脑裂(split-brain)是指在一个高可用(High Availability，HA)***中，当联系着的两个节点断开联系时，本来为一个整体的***，***为两个独立节点，这时两个节点开始争抢共享资源，从而导致***混乱、数据损坏的现象。随着互联网及云计算的快速发展及基于用户所产生的业务量不断增加，对业务的可靠性和性能要求越来越高。在实际的生产环境中，绝大多数集群都是高可用的，一旦发生脑裂，集群或者高可用集群中的多个节点的角色均变成了主节点，此时用户均可与多个原本不是主节点的节点(即从节点)执行写操作等节点上可执行的各项操作，从而导致各个节点之间的数据存在不一致的情况。
在现有技术中，处理集群或者高可用集群出现脑裂的普遍做法是，直接对断开的节点执行关闭操作并重启计算机***，然后恢复断开节点上计算机的初始环境，在恢复后再将该节点重新加入集群或者高可用集群中，以重新提供服务。当高可用集群恢复时，会发生各个节点之间的数据不一致的情况，此时只能采用人工合并数据的方式对各个节点之间的数据进行纠错，以判断最新节点，并将最新节点中的数据复制到其他节点中，以保证各个节点之间的数据呈现强一致性。
然而上述现有技术是基于人工干预的方式实现主、从节点之间数据的一致性，因此导致一旦发生脑裂后需要花费大量的人力去干预，而且无法实现在集群出现脑裂的第一时间提前介入对脑裂所产生的各个节点之间数据不一致的问题，并无法对控制各个节点之间因为脑裂所导致的各个节点之间的数据差异性扩大的问题。
发明内容
本发明的目的在于揭示一种处理高可用集群脑裂的方法，以实现即时发现脑裂并提前予以干预，并在脑裂发生后对各个节点之间数据执行同步处理，以保证高可用集群中各个节点中数据的强一致性；同时，基于相同发明思想，本发明还公开了一种处理高可用集群脑裂的装置。
为实现上述第一个发明目的，本发明提供了一种处理高可用集群脑裂的方法，包括：
在高可用集群所配置的节点中部署看门狗组件；
通过所述看门狗组件侦测对应节点中业务单元的状态数据，并将高可用集群中各个节点所部署的看门狗组件建立同步连接；
当看门狗组件侦测到对应节点中业务单元的状态数据发生异常时，看门狗组件触发对对应节点的冻结事件。
作为本发明的进一步改进，看门狗组件触发对对应节点的冻结事件的操作后还包括：
删除状态数据发生异常的节点中的数据，至少由看门狗组件读取对应节点中业务单元的标志位字段，通过比较标志位字段中最新的时间戳，以确定高可用集群中的当前主节点，并将所述主节点中的当前数据同步至高可用集群中的其他节点。
作为本发明的进一步改进，看门狗组件触发对对应节点的冻结事件的操作后还包括：
删除状态数据发生异常的节点中的数据，通知对应节点中所部署的高可用组件，并由高可用组件读取对应节点中业务单元的标志位字段，通过比较标志位字段中最新的时间戳，以确定高可用集群中的当前主节点，并将所述主节点中的当前数据同步至高可用集群中的其他节点。
作为本发明的进一步改进，所述业务单元为数据库、服务器或者负载均衡组件；
所述看门狗组件为内核级看门狗组件；
所述负载均衡组件为Apache、Ngnix、lvs或者HAProxy。
作为本发明的进一步改进，所述业务单元为据库、服务器或者负载均衡组件；
所述看门狗组件为用户空间级看门狗组件；
所述负载均衡组件为Apache、Ngnix、lvs或者HAProxy。
作为本发明的进一步改进，所述高可用集群中各个节点之中所部署的看门狗组件之间至少通过心跳机制建立同步连接。
作为本发明的进一步改进，所述心跳机制依赖heartbeat、corosync、keepalive或者cman实现。
作为本发明的进一步改进，所述高可用集群以主从方式、对称方法或者多机方式相通讯。
作为本发明的进一步改进，所述看门狗组件由监控模块与重置模块组成；
所述监控模块侦测对应节点中的业务单元的状态数据，当所述监控模块侦测到对应节点中业务单元的状态数据发生异常时，由监控模块调用重置模块，通过所述重置模块对状态数据发生异常的节点执行重置操作。
作为本发明的进一步改进，所述监控模块调用重置模块后，还包括：
向当前主节点发起修改节点数据请求，将请求所对应的数据同步至高可用集群中未发生状态数据发生异常的从节点。
作为本发明的进一步改进，所述重置模块对状态数据发生异常的节点执行重置操作后，还包括：
删除监控模块调用重置模块后向当前主节点发起修改节点数据请求所对应的数据。
基于相同发明思想，为实现上述第二个发明目的，本发明提供了一种处理高可用集群脑裂的装置，包括：
看门狗组件，部署在高可用集群所配置的各节点中；
所述看门狗组件侦测对应节点中的业务单元的状态数据，并将高可用集群中各个节点之中所部署的看门狗组件之间建立同步连接，当看门狗组件侦测到对应节点中业务单元的状态数据发生异常时，看门狗组件触发对对应节点的冻结事件。
与现有技术相比，本发明的有益效果是：通过本发明所揭示的一种处理高可用集群脑裂的方法及装置，实现了及时发现高可用集群所配置的节点失效所导致的脑裂现象的技术效果，并能够在失效节点恢复后对各个节点之间数据执行同步处理，从而保证了高可用集群中各个节点中数据的强一致性，避免了对权限及资源的无序争夺。
附图说明
图1为运行本发明一种处理高可用集群脑裂的方法并配置HA组件的集群的拓扑图；
图2为运行本发明一种处理高可用集群脑裂的方法并未配置HA组件的集群的拓扑图；
图3为基于图2所示出的场景中看门狗组件触发对对应节点的冻结事件及在发生故障的节点恢复后将主节点中的当前数据同步至高可用集群中的其他节点的示意图；
图4为本发明一种处理高可用集群脑裂的方法的流程图。
具体实施方式
下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。
详细阐述本发明所揭示的一种处理高可用集群脑裂的方法及装置的具体实现过程之前，对脑裂发生的原因及其他相关技术术语予以必要说明。
脑裂是因为集群或者高可用集群***导致的，集群或者高可用集群中有节点因为处理器忙或者其他原因暂时停止响应时(并可被理解为发生故障)，与其他节点间的心跳出现故障，但这些节点还处于active状态，其他节点可能误认为该节点“已死”，从而争夺共享资源(如共享存储)的访问权，***为两部分独立节点。集群是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端(Client)看来，一个集群就是一个服务实体，但事实上集群由一组服务实体组成。因此，在本实施例中，“高可用集 群”与“集群”可作为等同技术特征予以理解。
实施例一：
参图4所示出的一种处理高可用集群脑裂的方法的一种具体实施方式。该方法包括以下步骤：
步骤S1、在高可用集群所配置的节点中部署看门狗组件。
结合图1所示高可用集群或者集群100，该高可用集群100中配置有节点1、节点2及节点3。当然三个节点进行是对高可用集群100所部署的节点的范例性说明。在高可用集群100向上提供服务或者响应用户的过程中，节点1、节点2及节点3中的一个节点被定义为一个主节点(Master)，并将另外两个节点定义为从节点(Slave)。
其中，节点1中部署作为业务单元一种表现形式的数据库31，节点2中部署作为业务单元一种表现形式的数据库32，节点3中部署作为业务单元一种表现形式的数据库33。同时，在本申请所揭示的多个实施例中均以节点1在发生脑裂现象前作为主节点(Master)，并将节点2与节点3作为从节点(Slave)。同时，业务单元还可被配置为其他高可用集群中的组件，例如：服务器或者负载均衡组件；其中，服务器包括但不限于虚拟机服务器、web服务器、应用服务器、容器等。
更为具体的，在本实施例中，负载均衡组件为Apache、Ngnix、lvs或者HAProxy。高可用集群100或者高可用集群100a通过向上配置的Restful API与客户端(Client)交互，以建立客户端与业务单元之间的单向或者双向访问操作。具体的，访问操作可以是读操作、写操作、修改操作、迁移操作、镜像文件备份等操作，并依赖业务单元所特定的功能予以实现。由于业务单元并非本发明的创新点，故在本申请中不予过多展开介绍。
进一步的，该业务单元还可被配置为数据中心、缓存、MQ、基础服务或者第三方服务。结合图1与图2所示，当业务单元配置为数据库(DB)时，既可以如图1所示，在各个节点中分别配置HA组件11、HA组件12及HA组件13，也可以如图2所示，可省略配置HA组件11、HA组件12及HA组件13。若业务单元被配置为服务器时，则必须采用图1所示出的技术方案，在各个节点中配置HA组件11～13。
范例性的，该HA组件11～13可为vSphere或者YARN HA，并可根据高可用集群100或者高可用集群100a的架构选用适配的HA组件。
本实施例以图2所示出的场景予以详细阐述。节点1中配置看门狗组件21并通过该看门组件21侦测数据库31的状态数据，节点2中配置看门狗组件22并通过该看门组件22侦测数据库32的状态数据，节点3中配置看门狗组件23并通过该看门组件23侦测数据库33的状态数据。高可用集群100a以主从方式、对称方法或者多机方式相通讯，在本实施例中选用主从方式相通讯。由此，节点1与节点2、节点3形成主从节点关系。高可用集群100a主要实现自动侦测(Auto-Detect)故障、自动切换/故障转移(Fail Over)和自动恢复(Fail Back)。
高可用集群100a未发生脑裂时可借助每个节点中部署的看门狗组件对节点1、节点2及节点3中的数据库的状态数据予以监视，并在作为主节点的节点1中的数据库31发生数据修改或者配置修改时，将因数据修改或者配置修改所对应的数据同步至节点2中的数据库32与节点3中的数据库33。
步骤S2、通过所述看门狗组件侦测对应节点中业务单元的状态数据，并将高可用集群中各个节点所部署的看门狗组件建立同步连接。
看门狗组件21与看门狗组件22及看门狗组件23之间建立同步连接。优选的，高可用集群100a中各个节点之中所部署的看门狗组件之间至少通过心跳机制建立同步连接。具体的，该心跳机制依赖heartbeat、corosync、keepalive或者cman实现。以通过看门狗组件21～23分别对节点1～3中所部署的数据库31～33中的状态数据进行侦测，以确定数据库31～33中的状态数据是否一致。看门狗组件21～23可定时地监控本节点中数据库的状态数据，并与其他节点所配置的看门狗组件进行同步，避免发生高可用集群100a中不同节点中配置作为业务单元的数据库之间所的数据不一致的问题，避免发生脑裂现象。
步骤S3、当看门狗组件侦测到对应节点中业务单元的状态数据发生异常时，看门狗组件触发对对应节点的冻结事件。
业务单元的状态数据发生异常可由网络断开连接、宕机等原因所导致。假设看门狗组件22侦测到节点2中的数据库32的状态数据发生异常，则由看门狗组件22触发对节点2的冻结事件，以断开节点2与节点1之间的数据同步操作。通过看门狗组件22触发对节点2的冻结事件，可在及时发现节点2因发生故障所导致的整个高可用集群100a发生脑裂。基于冻结事件，节点2断开与高可用集群100a中其他节点之间的数据同步，从而防止作为主节点的节点1中的数据库21中的数据持续的同步更新至数据库32及数据库33，从而防止脑裂现象在高可用集群100a中进一步发生扩散与恶化。
同时，在本实施例中，在看门狗组件22触发对节点2的冻结事件后，执行删除状态数据发生异常的节点21中的数据，并在节点2恢复后将作为主节点的节点1的数据库21中的当前数据执行数据同步操作，以写入节点2的数据库32中。数据库31向数据库32的同步操作后完成之后，分别被看门狗组件21与看门狗组件22所侦测到，并在看门狗组件21与看门狗组件22执行同步操作。
同时，在本实施例中，看门狗组件21～23为内核级看门狗组件。内核级看门狗组件可以实现多个用户级多路复用，可以创建、撤销和调度这些用户级线程的技术效果。内核级看门狗组件在实现上可以是硬件电路也可以是软件定时器。看门狗组件21～23能够在***出现故障时自动重新启动***。在Linux内核下，watchdog的基本工作原理是：当watchdog(即看门狗组件)启动后(即/dev/watchdog设备被打开后)，如果在某一设定的时间间隔内/dev/watchdog没有被执行写操作，硬件watchdog电路或软件定时器就会重新启动***。由此，通过本实施例所揭示的一种处理高可用集群脑裂的方法，实现了对高可用集群100a中的各个节点在出现脑裂的提前预判，并确保了出现故障的节点恢复后高可用集群100a中各个节点数据的强一致性。
实施例二：
本实施例揭示了一种处理高可用集群脑裂的方法(以下简称方法)的一种变形例。
本实施例所揭示的方法与实施例一相比，其主要区别在于，在本实施例中，如果在图2所示出的场景中，看门狗组件22触发对对应节点的冻结事件的操作后还包括：删除状态数据发生异常的节点2中的数据，至少由看门狗组件22读取对应节点(即节点2)中业务单元，即数据库32中的标志位字段，通过比较标志位字段中最新的时间戳，以确定高可用集群100a中的当前主节点，并将所述主节点中的当前数据同步至高可用集群100a中的其他节点。
如果在图1所示出的场景中，看门狗组件22触发对对应节点的冻结事件的操作后还包括：删除状态数据发生异常的节点2中的数据，通知对应节点2中所部署的高可用组件，即HA组件12，并由HA组件12读取对应节点(即节点2)中业务单元(即数据库32)的标志位字段，通过比较标志位字段中最新的时间戳，以确定高可用集群100a中的当前主节点，并将所述主节点(即节点1)中的当前数据同步至高可用集群100a中的其他节点(即节点2与节点3)。
无论是图1所示出的场景还是图2所示出的场景，在发生故障的节点2恢复后，在选举新的主节点(Master)采用如下机制实现。
看门狗组件21～23分别读取节点1～3中的标志位字段。如果节点1与节点3中的标志位字段均含有关键字“Master”，则将比较标志位字段中的时间戳，并删除最新的时间戳的标志位字段，仅将时间戳较早的标志位字段的节点(即节点1)选举为当前状态中高可用集群100或者100a中的主节点。
通过上述技术方案，有效地解决了发生故障的节点在恢复之后多个节点之间出现主节点争夺的问题，进一步确保了高可用集群100或者100a数据的强一致性。
参图3所示，所述看门狗组件由监控模块与重置模块组成。申请人以节点1中的看门狗组件21为范例做示范性说明。
看门狗组件21由监控模块211与重置模块212组成，且节点2、节点3中的看门狗组件22、23具相同逻辑结构。具体的，在本实施例中，监控模块211侦测对应节点中的业务单元的状态数据，当监控模块211侦测到对应节点(即节点2)中业务单元(即数据库32)的状态数据发生异常时，由监控模块211调用重置模块212，通过所述重置模块212对状态数据发生异常的节点执行重置操作。同时，监控模块211调用重置模块212后，还包括：向当前主节点(即节点1)发起修改节点数据请求，将请求所对应的数据同步至高可用集群100a中未发生状态数据发生异常的从节点(即节点3)。重置模块211对状态数据发生异常的节点(即节点2)执行重置操作后，还包括：删除监控模块212调用重置模块212后向当前主节点(即节点1)发起修改节点数据请求所对应的数据，从而可降低该高可用集群100a中冗余数据的产生，并进一步提高故障恢复后高可用集群100a的稳定性与数据的一致性。
同时，在本实施例中，该看门狗组件21～23为用户空间级看门狗组件。相对实施例一所揭示的内核级看门狗组件，如果采用用户空间级看门狗组件的话，其技术优势在于：线程切换比内核级看门狗组件的线程切换速度更快，并支持更多线程，且允许每个进程有自己定制的调度算法，因此具有更为细腻的控制粒度。
参图3所示，申请人基于图2所示出的场景中看门狗组件触发对对应节点的冻结事件及在发生故障的节点恢复后将主节点中的当前数据同步至高可用集群中的其他节点的整个过程进行详细阐述。该方法可通过图3中步骤①至步骤⑥予以更为清晰的描述。该高可用集群100a由三个节点组成，其中，节点1为主节点，节点2和节点3为从节点。每个节点上由监控模块211与重置模块212组成的看门狗组件21，以及配置在每个节点上的数据库31～33(或者其他形式的业务单元)。
节点1中的监控模块211实时读取数据库31，同时，节点2中的监控模块(简化描述未具体示出)实时读取数据库32，以确定数据库31与数据库32之间的同步信息。若节点2中的监控模块发现节点2发生故障，调用重置模块212去重置故障节点，并通知节点1中的监控模块211，并执行步骤①至步骤⑥。
需要说明的是，在本实施例中，每个节点只能重置高可用集群100a中的其他节点。由于发生故障导致对发生故障的节点进行重置操作时，本节点已经失能，因此不能调用本节点中看门狗组件中的重置模块重置本节点。同时，主节点不允许重置的，因为主节点通过提供数据写操作，以确保整个高可用集群100a中其他节点中的数据和主节点所保存的数据呈强一致性。
如图3所示，若节点2发生故障导致节点1中的数据无法同步至节点2，并历经如下步骤①至步骤⑥，以对通过本方法如何遏制脑裂的进一步扩展并在发生故障的节点恢复后的处理过程予以详述。
步骤①：节点1的监控模块211通过读取高可用集群100a的状态数据发现节点2发生故障。
步骤②：节点1中的监控模块211调用重置模块212。
步骤③：重置模块212先到数据库集群中向数据库31中写入一条数据，该数据用于表明节点1中看门狗组件21的重置模块212正在操作重置节点2。
步骤④：在节点1上写完数据之后会立刻同步到节点3上所配置的看门狗组件23中，节点3中的看门狗组件23所配置的监控模块(未示出，并参节点1中的看门狗组件21所示)读取该信息发现节点1中看门狗组件21的重置模块212正在操作重置节点2，在此过程中节点3保持静默状态，即节点3中的数据库33不发生数据操作。
步骤⑤：节点1中看门狗组件21的监控模块212通过对执行重置节点2中数据库32的数据的重置操作，重置操作可为删除节点2中数据库32的数据，并重新从节点1中的数据库31上同步更新后的数据。
步骤⑥：节点1上看门狗组件21中的重置模块212会在高可用集群100a中将步骤③所产生的数据进行删除，以防下次出现脑裂现象时的误判，提高了高可用集群100a的可靠性与各个节点之间数据的强一致性。
本实施例所揭示的方法与实施例一中相同部分的技术方案，请参实施例一所述，在此不再赘述。
实施例三：
结合图1至图3所示，本发明还揭示一种处理高可用集群脑裂的装置(以下简称装置)，该装置运行实施例一和/或实施例二所揭示一种处理高可用集群脑裂的方法。
在本实施例中，该装置包括：看门狗组件(即看门狗组件21～看门狗组件23)，部署在高可用集群所配置的各节点中(即节点1～节点3)。看门狗组件侦测对应节点中的业务单元的状态数据，并将高可用集群中各个节点之中所部署的看门狗组件之间建立同步连接，当看门狗组件侦测到对应节点中业务单元的状态数据发生异常时，看门狗组件触发对对应节点的冻结事件。
本装置运行实施例一和/或实施例二所揭示一种处理高可用集群脑裂的方法，以实现及时发现高可用集群所配置的节点失效所导致的脑裂现象的技术效果，并能够在失效节点恢复后对各个节点之间数据执行同步处理，从而保证了高可用集群中各个节点中数据的强一致性，避免了对权限及资源的无序争夺。该装置所依赖的技术方案与实施例一和/或实施例二所揭示一种处理高可用集群脑裂的方法相同部分的技术方案，请参上文所述，在此不再赘述。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (12)

1.一种处理高可用集群脑裂的方法，其特征在于，包括：
在高可用集群所配置的节点中部署看门狗组件；
通过所述看门狗组件侦测对应节点中业务单元的状态数据，并将高可用集群中各个节点所部署的看门狗组件建立同步连接；
当看门狗组件侦测到对应节点中业务单元的状态数据发生异常时，看门狗组件触发对对应节点的冻结事件。
2.根据权利要求1所述的方法，其特征在于，看门狗组件触发对对应节点的冻结事件的操作后还包括：
删除状态数据发生异常的节点中的数据，至少由看门狗组件读取对应节点中业务单元的标志位字段，通过比较标志位字段中最新的时间戳，以确定高可用集群中的当前主节点，并将所述主节点中的当前数据同步至高可用集群中的其他节点。
3.根据权利要求1所述的方法，其特征在于，看门狗组件触发对对应节点的冻结事件的操作后还包括：
删除状态数据发生异常的节点中的数据，通知对应节点中所部署的高可用组件，并由高可用组件读取对应节点中业务单元的标志位字段，通过比较标志位字段中最新的时间戳，以确定高可用集群中的当前主节点，并将所述主节点中的当前数据同步至高可用集群中的其他节点。
4.根据权利要求1所述的方法，其特征在于，所述业务单元为数据库、服务器或者负载均衡组件；
所述看门狗组件为内核级看门狗组件；
所述负载均衡组件为Apache、Ngnix、lvs或者HAProxy。
5.根据权利要求1所述的方法，其特征在于，所述业务单元为据库、服务器或者负载均衡组件；
所述看门狗组件为用户空间级看门狗组件；
所述负载均衡组件为Apache、Ngnix、lvs或者HAProxy。
6.根据权利要求1所述的方法，其特征在于，所述高可用集群中各个节点之中所部署的看门狗组件之间至少通过心跳机制建立同步连接。
7.根据权利要求6所述的方法，其特征在于，所述心跳机制依赖heartbeat、corosync、keepalive或者cman实现。
8.根据权利要求1至7中任一项所述的方法，其特征在于，所述高可用集群以主从方式、对称方法或者多机方式相通讯。
9.根据权利要求8所述的方法，其特征在于，所述看门狗组件由监控模块与重置模块组成；
所述监控模块侦测对应节点中的业务单元的状态数据，当所述监控模块侦测到对应节点中业务单元的状态数据发生异常时，由监控模块调用重置模块，通过所述重置模块对状态数据发生异常的节点执行重置操作。
10.根据权利要求9所述的方法，其特征在于，所述监控模块调用重置模块后，还包括：
向当前主节点发起修改节点数据请求，将请求所对应的数据同步至高可用集群中未发生状态数据发生异常的从节点。
11.根据权利要求9所述的方法，其特征在于，所述重置模块对状态数据发生异常的节点执行重置操作后，还包括：
删除监控模块调用重置模块后向当前主节点发起修改节点数据请求所对应的数据。
12.一种处理高可用集群脑裂的装置，其特征在于，包括：
看门狗组件，部署在高可用集群所配置的各节点中；
所述看门狗组件侦测对应节点中的业务单元的状态数据，并将高可用集群中各个节点之中所部署的看门狗组件之间建立同步连接，当看门狗组件侦测到对应节点中业务单元的状态数据发生异常时，看门狗组件触发对对应节点的冻结事件。
CN201910622641.3A 2019-07-11 2019-07-11 一种处理高可用集群脑裂的方法及装置 Pending CN110377487A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910622641.3A CN110377487A (zh) 2019-07-11 2019-07-11 一种处理高可用集群脑裂的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910622641.3A CN110377487A (zh) 2019-07-11 2019-07-11 一种处理高可用集群脑裂的方法及装置

Publications (1)

Publication Number Publication Date
CN110377487A true CN110377487A (zh) 2019-10-25

Family

ID=68250876

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910622641.3A Pending CN110377487A (zh) 2019-07-11 2019-07-11 一种处理高可用集群脑裂的方法及装置

Country Status (1)

Country Link
CN (1) CN110377487A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112653734A (zh) * 2020-12-11 2021-04-13 邦彦技术股份有限公司 服务器集群实时主从控制和数据同步***及方法
CN114528350A (zh) * 2022-02-18 2022-05-24 苏州浪潮智能科技有限公司 集群脑裂的处理方法、装置、设备及可读存储介质
CN116094940A (zh) * 2023-02-15 2023-05-09 北京志凌海纳科技有限公司 一种vrrp脑裂抑制方法、***、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102394914A (zh) * 2011-09-22 2012-03-28 浪潮(北京)电子信息产业有限公司 集群脑裂处理方法和装置
CN102521060A (zh) * 2011-11-16 2012-06-27 广东新支点技术服务有限公司 基于看门狗本地检测技术的高可用集群***假死解决方法
CN105849702A (zh) * 2013-12-25 2016-08-10 日本电气方案创新株式会社 集群***，服务器设备，集群***管理方法和计算机可读记录介质
CN107147540A (zh) * 2017-07-19 2017-09-08 郑州云海信息技术有限公司 高可用性***中的故障处理方法和故障处理集群

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102394914A (zh) * 2011-09-22 2012-03-28 浪潮(北京)电子信息产业有限公司 集群脑裂处理方法和装置
CN102521060A (zh) * 2011-11-16 2012-06-27 广东新支点技术服务有限公司 基于看门狗本地检测技术的高可用集群***假死解决方法
CN105849702A (zh) * 2013-12-25 2016-08-10 日本电气方案创新株式会社 集群***，服务器设备，集群***管理方法和计算机可读记录介质
CN107147540A (zh) * 2017-07-19 2017-09-08 郑州云海信息技术有限公司 高可用性***中的故障处理方法和故障处理集群

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112653734A (zh) * 2020-12-11 2021-04-13 邦彦技术股份有限公司 服务器集群实时主从控制和数据同步***及方法
CN112653734B (zh) * 2020-12-11 2023-09-19 邦彦技术股份有限公司 服务器集群实时主从控制和数据同步***及方法
CN114528350A (zh) * 2022-02-18 2022-05-24 苏州浪潮智能科技有限公司 集群脑裂的处理方法、装置、设备及可读存储介质
CN114528350B (zh) * 2022-02-18 2024-01-16 苏州浪潮智能科技有限公司 集群脑裂的处理方法、装置、设备及可读存储介质
CN116094940A (zh) * 2023-02-15 2023-05-09 北京志凌海纳科技有限公司 一种vrrp脑裂抑制方法、***、设备及存储介质

Similar Documents

Publication Publication Date Title
CN110071821B (zh) 确定事务日志的状态的方法，节点和存储介质
US11320991B2 (en) Identifying sub-health object storage devices in a data storage system
CN109729129B (zh) 存储集群***的配置修改方法、存储集群及计算机***
WO2019154394A1 (zh) 分布式数据库集群***、数据同步方法及存储介质
JP2008059583A (ja) クラスタ・システムならびにクラスタ・システム内でレプリカをバックアップする方法およびプログラム製品
CN105933407B (zh) 一种实现Redis集群高可用的方法及***
WO2021136422A1 (zh) 状态管理方法、主备应用服务器的切换方法及电子设备
CN110377487A (zh) 一种处理高可用集群脑裂的方法及装置
CN103763155A (zh) 分布式云存储***多服务心跳监测方法
JP2007279890A (ja) バックアップシステム及びバックアップ方法
CN102394914A (zh) 集群脑裂处理方法和装置
CN105471622A (zh) 一种基于Galera的控制节点主备切换的高可用方法及***
CN111460039A (zh) 关系型数据库处理***、客户端、服务器及方法
CN108173971A (zh) 一种基于主备切换的MooseFS高可用方法及***
JP2012173996A (ja) クラスタシステム、クラスタ管理方法、およびクラスタ管理プログラム
CN106919473A (zh) 一种数据灾备***及业务处理方法
CN112527567A (zh) ***容灾方法、装置、设备以及存储介质
CN107357800A (zh) 一种数据库高可用零丢失解决方法
CN114138732A (zh) 一种数据处理方法及装置
CN107071189B (zh) 一种通讯设备物理接口的连接方法
CN105824571A (zh) 一种实现数据无缝迁移的方法及装置
WO2021115043A1 (zh) 分布式数据库***和数据灾备演练方法
CN112783694B (zh) 一种高可用Redis的异地灾备方法
WO2015196692A1 (zh) 一种云计算***以及云计算***的处理方法和装置
CN114363356B (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