一种数据库集群的管理方法及装置与流程

文档序号:11707787阅读:229来源:国知局
一种数据库集群的管理方法及装置与流程

本公开涉及数据库技术领域,特别涉及一种数据库集群的管理方法及装置。



背景技术:

galeracluster是一套基于同步复制的多主mysql(一种关系型数据库)集群,使用简单,没有单点故障,可用性高,能很好保证业务不断增长时我们数据的安全和随时的扩展,号称是世界上最先进的开源数据库集群。其主要特点如下:同步复制、多主服务器的拓扑结构、可以在任意节点上进行读写、自动剔除故障节点、自动加入新节点、真正行级别的并发复制、客户端连接与操作单台mysql数据库的体验一致。

galeracluster的架构图如图1所示,客户端可以和集群中任何一个节点连接,每个节点都可以进行读写,写的话要不所有服务器都执行成功,要不就所有都回滚,保证所有服务器的数据一致性,而且所有服务器同步实时更新。galeracluster集群启动的时候必须有一个节点以新节点的方式启动,然后再将其他节点加入集群,新加入的节点从集群中选择一个节点进行同步数据。galeracluster维护了一个自增的seqno(序列号),每个节点都有着相同的seqno。当集群中节点停止后会把seqno持久化到grastate.dat文件中,集群中最后停掉的节点也会在grastate.dat文件置一个标志,下次集群启动的时候必须以最后停掉的这个节点为新节点启动,然后再将其他节点加入集群。

需要说明的是,galeracluster集群本身其实不是自动的,也不是高可用的,比如说:刚开始创建集群的时候必须手动配置一个节点以集群首节点的方式启动,然后其他节点再加入集群;当集群中有节点脱离集群后用户无法感知;脱离集群后的节点想要再加入集群必须手动加入;当整个集群死掉后必须手动找到seqno最大的节点以集群首节点启动,然后再将其他节点加入。由此可知,galeracluster集群管理需要人工参与,无法实现自动化。



技术实现要素:

为了解决相关技术中存在的galeracluster集群管理需要人工参与,无法实现自动化的问题,本公开提供了一种数据库集群的管理方法。

本公开提供了一种数据库集群的管理方法,所述数据库集群的每个节点内设有一个代理实体,每个代理实体分别控制各自所在的节点,所述数据库集群的管理方法应用于所述代理实体;所述方法包括:

在本节点未启动时,获取第二节点的节点信息;其中,所述第二节点为所述数据库集群内除本节点以外的所有其他节点;

若根据所述第二节点的节点信息,判断获知不存在满足预设条件的第二节点,则将所述本节点以所述数据库集群的首节点启动。

本公开还提供了一种数据库集群的管理装置,所述数据库集群的每个节点内设有一个代理实体,每个代理实体分别控制各自所在的节点,所述数据库集群的管理装置应用于所述代理实体;所述装置包括:

信息获取模块,用于在本节点未启动时,获取第二节点的节点信息;其中,所述第二节点为所述数据库集群内除本节点以外的所有其他节点;

节点启动模块,用于根据所述第二节点的节点信息,当判断获知不存在满足预设条件的第二节点时,将所述本节点以所述数据库集群的首节点启动。

本公开的实施例提供的技术方案可以包括以下有益效果:

通过在每个节点内设有一个代理实体,每个代理实体分别控制各自所在的节点,代理实体根据各个节点的信息可以自动确定集群首节点并启动,无需人工参与,大大提高了集群启动效率。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性的,并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并于说明书一起用于解释本发明的原理。

图1是现有技术提供的galeracluster集群的架构图;

图2是根据一示例性实施例示出的一种数据库集群的管理方法的流程图;

图3是根据一示例性实施例示出的数据库集群的部署图;

图4是根据另一示例性实施例示出的一种数据库集群的管理方法的流程图;

图5是根据又一示例性实施例示出的一种数据库集群的管理方法的详细流程图;

图6是根据一示例性实施例示出的一种服务器的结构图;

图7是根据一示例性实施例示出的一种数据库集群的管理装置的框图。

具体实施方式

这里将详细地对示例性实施例执行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

图2是根据一示例性实施例示出的一种数据库集群的管理方法的流程图。数据库集群是指利用至少两台或者多台数据库服务器,构成一个虚拟单一数据库逻辑映像,像单数据库系统那样,向客户端提供透明的数据服务。数据库集群的每一台服务器称为一个节点,每个节点(即数据库集群的每台服务器)设置一个代理实体(agent),每个代理实体分别控制各自所在的节点。其中,agent是指能自主活动的软件或硬件实体,agent可以执行本公开实施例提供的数据库集群的管理方法。

该数据库集群的管理方法的适用范围和执行主体,例如,该方法可以用于图6所示结构的服务器500,数据库集群可以包括多个图6所示结构的服务器500,并在每台服务器500上分别部署一个agent。由每台服务器500上的agent管理各自所属的服务器500。具体的,该数据库集群可以是指galeracluster集群。如图3所示,为数据库集群的部署图,每个数据库节点上部署一个agent。另外,在数据库集群的上层可以部署一个lvs(linux虚拟服务器),用于实现负载均衡。

如图2所示,该数据库集群的管理方法,可以由服务器的代理实体执行,该方法可以包括以下步骤:

步骤s210:在本节点未启动时,获取第二节点的节点信息;其中,所述第二节点为所述数据库集群内除本节点以外的所有其他节点;

具体的,由每个节点上部署的agent控制每台服务器的启动和停止。以图3所示的5个数据库节点举例来说,为便于区分,暂且分别称为节点1、节点2……节点5。假设本节点为图3中的节点1,第二节点为除节点1以外的节点2、3、4、5。在本节点(节点1)未启动时,节点1上部署的agent获取第二节点(节点2、3、4、5)的节点信息。其中,节点信息包括:第二节点的运行状态(包括已启动、正在启动、未启动)、序列号、优先级等。

步骤s230:若根据所述第二节点的节点信息,判断获知不存在满足预设条件的第二节点,则将所述本节点以所述数据库集群的首节点启动。

具体的,在本节点(节点1)未启动时,节点1上部署的agent根据第二节点(节点2、3、4、5)的节点信息,判断是否存在满足预设条件的第二节点。例如,当没有已经启动或者正在启动的第二节点时,将本节点(节点1)作为数据库集群的首节点启动。

可选的,满足预设条件第二节点可以包括:处于已启动状态的第二节点、处于正在启动阶段的第二节点、序列号大于本节点的第二节点以及优先级比本节点高的第二节点。当不存在上述满足预设条件的第二节点时,则可以认为本节点是优先级最高的、序列号最大的节点,从而可以确定本节点为集群的首节点,可以将本节点以该数据库集群的首节点启动。然后,除本节点以外的其他节点再加入该集群中。新加入的节点从集群中选择一个节点同步数据。

需要说明的是,galeracluster集群本身并不是自动的,在创建集群时需人工手动配置一个节点,将其作为首节点启动,然后其他节点再加入集群;当整个集群宕机时,也需手动寻找集群首节点进行启动,然后其他节点再加入,因此集群启动效率低。本公开实施例提供的数据库集群的管理方法,通过在每一个节点中部署一个agent,由agent根据各个节点的信息自动确定集群首节点并启动,无需人工参与,大大提高了集群启动效率。

图4是根据另一示例性实施例示出的一种数据库集群的管理方法的流程图。如图4所示,所述方法除了包括图3对应实施例的步骤s210和步骤s230以外,所述方法还可以包括以下步骤:

步骤s250:若根据所述第二节点的节点信息,判断获知存在处于已启动状态的第二节点,则将所述第二节点的数据同步至所述本节点,并将所述本节点的状态置为已启动状态。

具体的,可以从各个节点的配置文件中获取各个节点的地址,然后根据各个节点的地址,遍历除本节点以外的所有数据库节点(即第二节点),获取这些节点的节点信息。当根据第二节点的节点信息,判断出存在处于已启动状态的第二节点,如存在一个第二节点的状态为“running”(运转),则可以认为本节点并非集群首节点。之后将本节点加入集群,将第二节点的数据同步至本节点,并将本节点的状态置为已启动状态,如将节点状态置为running”。根据需要,若前节点加入集群失败,则发出告警信号。

需要说明的是,当存在某一个节点宕机时,通过上述步骤s210和s250,可以及时根据其他节点的节点信息,将该宕机的节点加入集群,将其他节点的数据同步至该宕机的节点,从而无需人工手动来启动宕机的节点,提高了节点启动效率。

进一步的,在上述实施例的基础上,所述方法还可以包括以下步骤:

在本节点已经启动后,定时监控本节点的状态信息;

当所述状态信息出现异常时,发出告警信号。

其中,本节点的agent定时监控本节点的状态信息,监控的状态如下:

wsrep_ready(值为on时,节点才可以接受其他节点的数据)==on

wsrep_connected(值为on时,表示节点至少可以连接集群中一个节点)==on

srep_local_state_comment(正常的稳定状态为:joining、waitingonsst、joined、syncedordonor。其他状态为临时状态或者不正常的状态)等于joined、synced或者donor

wsrep_cluster_status(节点正常的状态值为:primary)==primary

节点的wsrep_cluster_state_uuid(每个节点都应该相同的状态变量)至少与集群中半数wsrep_cluster_state_uuid值相同。

需要说明的是,当监控的上述状态变量出现异常时,即不满足上述情况时,如wsrep_ready为off或wsrep_connected为off,均认为状态信息出现异常,需要发出告警信号。

若发现本节点的状态变量wsrep_cluster_size(集群中节点的数量)、wsrep_cluster_conf_id(集群变化次数)、wsrep_cluster_state_uuid(每个节点都应该相同的状态变量)与其他半数节点状态变量不一致,则可以认为出现异常,需要发出告警信号。

或者,wsrep_local_recv_queue_avg(上次状态查询至今的接受队列的平均长度),wsrep_flow_control_paused(上次本状态变量查询至今,本节点由于流量控制而导致暂停的时间百分比),wsrep_local_send_queue_avg(上次状态查询至今的发送队列的平均长度)是否超过配置文件中配置的阈值,超过则认为出现异常需要发出告警信号。其中,可以通过命令行查看集群中所有节点的状态信息,可以查看主要的状态信息。

根据需要,数据库集群上层的lvs节点的异常情况查询,也可以通过检查以下项目:wsrep_ready(值为on时,节点才可以接受其他节点的数据)==on

wsrep_connected(值为on时,表示节点至少可以连接集群中一个节点)==on

srep_local_state_comment(正常的稳定状态为:joining、waitingonsst、joined、syncedordonor。其他状态为临时状态或者不正常的状态)等于joined、synced或者donor

wsrep_cluster_status(节点正常的状态值为:primary)==primary

当上述四个条件同时满足时,则认为该lvs节点没有出现异常,否则可以进行告警。

进一步的,在上述任意一种实施例的基础上,所述方法还可以包括以下步骤:

在本节点已经启动后,定时检测本节点是否在线;

若不在线,则重复执行所述获取第二节点的节点信息的步骤。

需要说明的是,现有技术当集群中有节点脱离集群时,用户无法感知,并且脱离集群后的节点想要再加入集群必须人工手动加入。本公开实施例在每个节点部署的agent可以定时检测所在节点是否在线。如,agent每隔1秒检测本节点是否在线,如果不在线,则可以重复上述步骤s210和步骤s230或者重复步骤s210和步骤s250。当不存在满足预设条件的第二节点时,可以将离线的节点以集群首节点启动。当存在已经启动的第二节点时,可以将离线的节点重新加入集群,从第二节点中将数据同步至该离线的节点。

图5是根据另一示例性实施例示出的一种数据库集群的管理方法的详细流程图。其中,每个节点内部署一个agent,每个节点内部署的agent分别控制各自所在的节点。其中,当前agent所在的节点称为本节点,其他agent所在的节点称为其他节点。各个节点内的agent都启动完各自的节点后,才认为整个集群启动完成。以启动galeracluster集群举例来说,

具体流程如下:

1、若本节点已经启动,则退出。

2、将本节点置为‘init’状态。

3、从各个节点的配置文件中获取各个节点的地址。

4、遍历集群节点(除本节点以外的其他节点)的列表。

5、获取其他节点的状态,若获取不到,则循环检检测其他节点状态,直到其他节点状态可知。

(a)若一个节点状态已经启动,将本节点加入集群(若加入失败告警),加入成功将本节点状态置为‘running’,流程完毕。

(b)若发现一个节点正在启动一个新集群(状态为‘starting_cluster’),则继续,等下一次重新遍历。

(c)若发现一个节点正在初始化(状态为‘init’)或者‘stop’(停止)状态,且seqno(序列号)高于本节点(若获取不到seqno,则一直循环检测,直到获取到),则继续,等下一次重新遍历。

(d)若发现一个节点正在初始化(‘init’)或者‘stop’状态,且seqno等于本节点(若获取不到seqno,则一直循环检测,直到获取到),则判断节点的优先级(根据配置文件中配置的顺序,按顺序优先级降低);

若比本节点优先级高,则继续,等下一次重新遍历;

若没本节点优先级高,则统计计数加一。

(e)判断统计计数是否达到最大值(集群节点数减一),若达到则跳出循环。至此完成本节点与其他所有节点的比较。

6、将本节点状态置为'starting_cluster',然后将本节点以新集群的首节点方式启动(启动失败告警,一直重试启动直到成功),成功后将状态置为’running’,流程完毕。

本节点启动之后,其他agent控制各自所在的节点加入该集群,即可实现数据库集群的启动。

对于集群的停止,本公开实施例提供了两种停止的方式:停止代理实体或者先停止集群节点再停止代理实体。对于galeracluster集群而言,一是只停止集群的管理系统galera_agent;另一种是停止管理系统galera_agent前先把集群节点停止。

本公开实施例提供的技术方案,agent会自动启动数据库集群,当集群中有节点离线后会告警,并且自动将节点拉起,当整个集群宕机时,也会自动找到seqno最大的节点然后将整个集群启动,提高了可靠性,使其更加自动化,提高启动效率。

参见图6,图6是本公开实施例提供的一种服务器结构示意图。该服务器500可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上中央处理器(centralprocessingunits,cpu)522(例如,一个或一个以上处理器)和存储器532,一个或一个以上存储应用程序542或数据544的存储介质530(例如一个或一个以上海量存储设备)。其中,存储器532和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块(图示未示出),每个模块可以包括对服务器中的一系列指令操作。更进一步地,中央处理器522可以设置为与存储介质530通信,在服务器500上执行存储介质530中的一系列指令操作。服务器500还可以包括一个或一个以上电源526,一个或一个以上有线或无线网络接口550,一个或一个以上输入输出接口558,和/或,一个或一个以上操作系统541,例如windowsservertm,macosxtm,unixtm,linuxtm,freebsdtm等等。上述实施例中数据库集群可以包括多个图6所示的服务器结构,agent可以设置在图6所示的服务器结构中,完成上述图2、4、5所示实施例中所述的由服务器中agent所执行的步骤。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。

下述为本公开装置实施例,可以用于执行本公开上述服务器500中代理实体所执行数据库集群的管理方法实施例。对于本公开装置实施例中未披露的细节,请参照本公开数据库集群的管理方法实施例。

图7是根据一示例性实施例示出的一种数据库集群的管理装置的框图,该数据库集群的管理装置可以用于图6所示实施环境的服务器500中,执行上述方法实施例中的全部或者部分步骤。如图7所示,该数据库集群的管理装置包括但不限于:信息获取模块710和节点启动模块730;

信息获取模块710,用于在本节点未启动时,获取第二节点的节点信息;其中,所述第二节点为所述数据库集群内除本节点以外的所有其他节点;

节点启动模块730,用于根据所述第二节点的节点信息,当判断获知不存在满足预设条件的第二节点时,将所述本节点以所述数据库集群的首节点启动。

上述装置中各个模块的功能和作用的实现过程具体详见上述数据库集群的管理方法中对应步骤的实现过程,在此不再赘述。

信息获取模块710比如可以是图6中的某一个物理结构有线或无线网络接口550。

节点启动模块730也可以是功能模块,用于执行上述数据库集群的管理方法中的对应步骤。可以理解,这些模块可以通过硬件、软件、或二者结合来实现。当以硬件方式实现时,这些模块可以实施为一个或多个硬件模块,例如一个或多个专用集成电路。当以软件方式实现时,这些模块可以实施为在一个或多个处理器上执行的一个或多个计算机程序,例如图6的中央处理器522所执行的存储在存储器532中的程序。

可选的,所述满足预设条件的第二节点包括但不限于:

处于已启动状态的第二节点、处于正在启动阶段的第二节点、序列号大于本节点的第二节点以及优先级比本节点高的第二节点。

在上述装置实施例的基础上,所述装置还可以包括但不限于:

节点加入模块,用于根据所述第二节点的节点信息,当判断获知存在处于已启动状态的第二节点时,将所述第二节点的数据同步至所述本节点,并将所述本节点的状态置为已启动状态。

在上述装置实施例的基础上,所述装置还可以包括但不限于:

信息监控模块,用于在本节点已经启动后,定时监控本节点的状态信息,并当所述状态信息出现异常时,发出告警信号。

在上述装置实施例的基础上,所述装置还可以包括但不限于:

在线检测模块,用于在本节点已经启动后,定时检测本节点是否在线;并当不在线时,由所述信息获取模块710继续获取第二节点的节点信息。

在示例性实施例中,本公开还提供另一种数据库集群的管理装置,该数据库集群的管理装置可以用于图6所示实施环境的服务器500中,执行方法实施例中的全部或者部分步骤。所述装置包括:

处理器;

用于存储处理器可执行指令的存储器;

其中,所述处理器被配置为执行:

在本节点未启动时,获取第二节点的节点信息;其中,所述第二节点为所述数据库集群内除本节点以外的所有其他节点;

若根据所述第二节点的节点信息,判断获知不存在满足预设条件的第二节点,则将所述本节点以所述数据库集群的首节点启动。

该实施例中的装置的处理器执行操作的具体方式已经在有关该数据库集群的管理方法的实施例中进行了详细描述,此处将不做详细阐述说明。

可选的,还提供了一种存储介质,该存储介质为计算机可读存储介质,例如可以为包括指令的临时性和非临时性计算机可读存储介质。该存储介指例如包括指令的存储器,上述指令可由装置的处理器执行以完成上述数据库集群的管理方法。

应当理解的是,本发明并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围执行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1