数据库集群的节点管理方法、装置及电子设备

技术领域

本申请涉及数据库集群领域，具体而言，涉及一种数据库集群的节点管理方法、装置及电子设备。

背景技术

随着云技术的发展，服务上云已经成为大趋势。其中，部署在kuberneters(简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用)上的服务可以依赖kuberneters提供的能力来实现高可用。例如：使用Deployment或StatefulSet部署的服务，kuberneters会始终在数据库集群中维持固定数量的pod(kuberneters应用程序中的最小计算单元，一个pod对应数据库集群中的一个节点),在一个pod出现故障时，需要及时对故障pod进行重新创建，从而实现服务的高可用。而服务在运行过程中，数据常常会存储在etcd、mongo、clickhouse等数据库中，一旦这些数据库出现故障，运行在kuberneters上的服务便会异常。这就要求数据库如etcd、mongo、clickhouse等也要能部署到kuberneters环境上并且具备高可用能力。

但是，在现有技术中，当数据库集群的主节点出现异常时，往往需要手动重新创建，然后才能恢复使用，并且，节点在重新创建之后，其对应的IP地址很大可能会发生变化。在此基础上，如果无法及时获取重新创建的节点所对应的最新IP地址，即便节点创建成功之后也无法正常完成节点之间的通讯。由此可见，现有技术采用人工方式修复故障主节点的方法会导致主节点的故障修复效率较低的问题。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种数据库集群的节点管理方法、装置及电子设备，以至少解决现有技术中数据库集群的主节点出现故障时存在的故障修复效率低的技术问题。

根据本申请实施例的一个方面，提供了一种数据库集群的节点管理方法，包括：在数据库集群中创建多个节点，其中，多个节点包括一个主节点和至少一个从节点，每个节点与一个网络地址相对应，主节点用于提供数据写服务，从节点用于提供数据读服务；通过主节点中的目标容器监控主节点在运行过程中是否出现异常；在主节点出现异常时，确定主节点为待处理节点，并从至少一个从节点中选取一个从节点作为新的主节点；重新创建待处理节点，并删除待处理节点对应的网络地址；在待处理节点重建成功之后，获取目标网络地址，并根据目标网络地址确定重建成功后的待处理节点为一个新的从节点，其中，目标网络地址为重建成功后的待处理节点重新分配到的网络地址。

进一步地，数据库集群的节点管理方法还包括：在数据库集群中创建多个计算单元，其中，每个计算单元被分配一个网络地址；从多个计算单元中随机选取一个计算单元作为主节点，并确定其他计算单元为从节点，其中，其他计算单元为多个计算单元中除主节点之外的所有计算单元。

进一步地，数据库集群的节点管理方法还包括：在从多个计算单元中随机选取一个计算单元作为主节点之后，检测数据库集群中是否存在新增的计算单元；在检测到数据库集群中存在新增的计算单元的情况下，获取新增的计算单元对应的网络地址；根据新增的计算单元对应的网络地址将新增的计算单元确定为数据库集群中新的从节点。

进一步地，数据库集群的节点管理方法还包括：在从多个计算单元中随机选取一个计算单元作为主节点之后，通过每个从节点上的目标容器监控每个从节点上的数据库进程是否出现异常；在任意一个从节点上的数据库进程出现异常时，更新该从节点对应的进程标识为第一标识；将携带有第一标识的从节点确定为第一从节点，并对第一从节点进行重新创建。

进一步地，数据库集群的节点管理方法还包括：删除第一从节点对应的网络地址；在第一从节点重建成功之后，获取第一网络地址，其中，第一网络地址为重建成功后的第一从节点重新分配到的网络地址；根据第一网络地址将重建成功后的第一从节点加入至数据库集群中。

进一步地，数据库集群的节点管理方法还包括：在从多个计算单元中随机选取一个计算单元作为主节点之后，通过每个从节点上的目标容器监控每个从节点与主节点之间的通讯是否出现异常；在任意一个从节点与主节点之间的通讯出现异常时，更新该从节点对应的通讯状态标识为第二标识；将携带有第二标识的从节点确定为第二从节点，并禁止第二从节点继续提供数据读服务；从数据库集群中移除第二从节点。

进一步地，数据库集群的节点管理方法还包括：主节点和每个从节点中都存储有全量的数据，通过新的主节点上的目标容器获取目标网络地址；根据目标网络地址将重建成功后的待处理节点确定为数据库集群中新增的目标从节点；将新的主节点中存储的所有数据同步至目标从节点中。

根据本申请实施例的另一方面，还提供了一种数据库集群的节点管理装置，包括：节点创建模块，用于在数据库集群中创建多个节点，其中，多个节点包括一个主节点和至少一个从节点，每个节点与一个网络地址相对应，主节点用于提供数据写服务，从节点用于提供数据读服务；监控模块，用于通过主节点中的目标容器监控主节点在运行过程中是否出现异常；第一确定模块，用于在主节点出现异常时，确定主节点为待处理节点，并从至少一个从节点中选取一个从节点作为新的主节点；节点重建模块，用于重新创建待处理节点，并删除待处理节点对应的网络地址；第二确定模块，用于在待处理节点重建成功之后，获取目标网络地址，并根据目标网络地址确定重建成功后的待处理节点为一个新的从节点，其中，目标网络地址为重建成功后的待处理节点重新分配到的网络地址。

根据本申请实施例的另一方面，还提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述的数据库集群的节点管理方法。

根据本申请实施例的另一方面，还提供了一种电子设备，电子设备包括一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现用于运行程序，其中，程序被设置为运行时执行上述的数据库集群的节点管理方法。

在本申请中，采用自动重建出现异常的主节点，并从至少一个从节点中选择一个从节点作为新的主节点的方式，首先在数据库集群中创建多个节点，然后通过主节点中的目标容器监控主节点在运行过程中是否出现异常，在主节点出现异常时，确定主节点为待处理节点，并从至少一个从节点中选取一个从节点作为新的主节点，随后重新创建待处理节点，并删除待处理节点对应的网络地址，在待处理节点重建成功之后，获取目标网络地址，并根据目标网络地址确定重建成功后的待处理节点为一个新的从节点，其中，目标网络地址为重建成功后的待处理节点重新分配到的网络地址，多个节点包括一个主节点和至少一个从节点，每个节点与一个网络地址相对应，主节点用于提供数据写服务，从节点用于提供数据读服务。

由上述内容可知，本申请通过主节点中的目标容器自动监控主节点在运行过程中是否出现异常，并对出现异常的主节点进行自动重新创建，从而提高了主节点的重新创建效率。同时，本申请在主节点出现异常时，还会从至少一个从节点中选取一个从节点作为新的主节点，从而可最大程度地避免业务数据的中断处理，提高了数据库集群处理数据时的稳定性。此外，本申请在发生故障的主节点重建成功之后，获取目标网络地址，并根据目标网络地址将重建成功后的节点作为一个新的从节点，从而实现了自动故障转移的目的，不仅避免了由于主节点异常导致的业务中断，还提高了异常节点的故障修复效率。

由此可见，本申请的技术方案达到了在主节点出现故障时实现自动故障转移的目的，从而实现了提高数据库业务运行稳定性的技术效果，进而解决了现有技术中数据库集群的主节点出现故障时存在的故障修复效率低的技术问题。

附图说明

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

图1是根据现有技术的一种可选的数据库高可用集群的部署方法的示意图；

图2是根据现有技术的另一种可选的数据库高可用集群的部署方法的示意图；

图3是根据本申请实施例的一种可选的数据库集群的节点管理方法的流程图；

图4是根据本申请实施例一种etcd数据库集群的搭建方法的示意图；

图5是根据本申请实施例的一种可选的数据库集群的结构图；

图6是根据本申请实施例的一种可选的数据库集群的节点管理装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

随着云技术的发展，服务上云已经成为大趋势。部署在kuberneters上的服务可以依赖kuberneters提供的能力来实现高可用。例如：使用Deployment或StatefulSet部署的服务，kuberneters会始终在集群中维持固定数量的pod,在该pod出现故障时及时杀死故障pod并重新创建，从而实现服务的高可用。而服务在运行过程中，数据常常会存储在etcd、mongo、clickhouse等数据库中，一旦这些数据库出现故障，运行在kuberneters上的服务便会异常。这就要求数据库如etcd、mongo、clickhouse等也要能部署到kuberneters环境上并且具备高可用能力。

其中，图1是根据现有技术的一种可选的数据库高可用集群的部署方法的示意图。如图1所示，该数据库高可用集群为一个etcd集群，部署有三个节点，这三个节点都是部署在物理主机上，操作系统为CentOS7。在现有技术中，需要在配置文件中提前配置好数据库集群中各个节点的IP地址等信息，这种方式可以依赖集群本身的能力实现高可用。具体的结构如下：

(1)etcd集群部署在三台物理主机上。

(2)物理主机1作为master节点，物理主机2作为node1节点，物理主机3作为node2节点。

(3)每个物理主机上运行一个etcd进程，共同组成etcd集群。

(4)当某台物理主机宕机时，其他两个节点仍然能够正常运行，etcd集群仍然能够对外提供服务。

现有技术在部署图1中的etcd集群时至少需要以下过程：

1、安装etcd服务：在三台物理主机上通过“yum-y install etcd”命令分别安装etcd。

2、修改master节点配置文件：安装好etcd服务之后，在/etc/etcd目录下会有一个etcd.conf的配置文件，在master节点上修改配置文件，将集群各个节点的IP等信息配置在master节点的配置文件中,由于master节点最先启动，还需要把ETCD_INITIAL_CLUSTER_STATE属性设置为new。

3、修改node1和node2节点配置文件：node1和node2上的配置文件需要把ETCD_INITIAL_CLUSTER_STATE属性设置为existing。

4、启动master节点上的etcd服务：启动命令如下：

systemctl daemon-reload

systemctl start etcd

systemctl enable etcd

5、启动node1和node2的etcd服务：分别在node1和node2上执行启动命令，启动etcd服务。

常见的各种类型数据库自身往往都会提供基于物理主机的集群部署方式，依赖集群自身实现高可用。然而，通过上述部署过程可以知晓的是，这种基于物理主机部署的数据库部署存在以下缺点：

(1)部署过程十分繁琐：必须要事先知晓所有节点的IP，并且要事先把所有的IP等配置信息事先配置到各个节点上，然后按照先启动主节点，再启动从节点的顺序依次手动启动数据库服务(例如，etcd服务)。

(2)无法自动转移故障：当节点出现故障时，无法自动恢复。必须手动修复相关故障，并重启数据库服务，该节点才能继续正常对外提供服务。

(3)扩展节点比较繁琐：当需要增加节点时，由于集群中的各个节点IP是事先配置好的，需要修改配置文件后重启数据库服务才能生效，比较繁琐。

图2是根据现有技术中的另一种可选的数据库高可用集群的部署方法的示意图。如图2所示，该方法首先在kubernetes上部署一个pod，然后将数据库服务(例如etcd服务)作为pod里面的一个容器进行部署和启动。其中，pod为kubernetes应用程序中最小计算单元。

现有技术在部署图2中的etcd集群时至少需要以下过程：

1、在一个kubernetes集群中，部署有三台物理主机，其中，etcd服务部署在物理主机2上。

2、在kubernetes集群上部署一个服务Service，背后是一个部署文件Deployment，副本数是1，也就是说kubernetes会在集群环境上始终维持一个etcd的pod，当该pod出现故障时，会自动重建该pod。另外，该pod里面有一个容器，容器里面有etcd的启动进程，当pod创建后，会自动拉起etcd的启动进程，从而对外提供etcd服务。

需要注意到的是，依据图2中的方法，将etcd服务部署在kubernetes的pod中，虽然简化了配置，可以利用kubernetes的能力对pod进行管理，但是依然存在以下问题：

(1)难以组建集群：当pod在运行过程中出现故障，kubernetes重建pod后，pod的IP就会发生变化，这样事先配置的IP信息就会出错，基于此问题，很难组建集群，只能部署单节点的etcd服务。而单节点部署etcd，在pod进行重建的过程中，etcd服务便不可用，无法实现真正的高可用。

(2)无法自动扩容：随着存储的数据量越来越大，需要更多节点来存储数据时，而这种部署方无法实现自动扩容。

结合上述两种现有技术的数据库高可用集群的部署方法可知，在现有技术中，数据库集群部署在kuberneters上的时候往往面临以下问题：

(1)pod的IP地址频繁变化：由于kuberneters上的pod在重建时，IP会发生变化，而数据库集群节点成员的IP需要在数据库集群部署时配置好，这就会造成pod重建后集群节点间通信出现异常。

(2)缺少健康检查机制：当某个节点出现故障时，无法及时监测到该故障并实现自动故障转移与节点恢复。

(3)无法自动扩容：随着存储的数据量越来越大，就需要更多的节点来存储数据，数据库部署到kuberneters上之后，不能根据需求及时地扩展节点。

为了解决上述的问题，本申请实施例，提供了一种数据库集群的节点管理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图3是根据本申请实施例的一种可选的数据库集群的节点管理方法的流程图，如图3所示，该方法包括如下步骤：

步骤S301，在数据库集群中创建多个节点。

在步骤S301中，多个节点包括一个主节点和至少一个从节点，每个节点与一个网络地址相对应，主节点用于提供数据写服务，从节点用于提供数据读服务。

具体的，上述的数据库集群可以是各种类型的数据库集群，例如，etcd数据库集群，mongo数据库集群、clickhouse数据库集群等，具体根据所提供的数据库类型来确定。为了方便描述，本申请以etcd数据库集群为例进行以下说明。

在本申请中，使用kuberneters应用程序作为本申请实施例的数据库集群的节点管理方法的执行主体。首先，通过kuberneters应用程序在etcd数据库集群中创建多个计算单元pod，其中，每个pod位于一台物理主机上，并且每个pod为一个节点，每个pod被分配一个独立的ip地址。另外，还需要注意到的是，每个pod内部由两个容器组成，一个是etcd容器，用于管理etcd服务进程，例如，用于启动节点上的etcd服务。另一个容器为sidecar容器，用于负责整个etcd数据库集群的动态配置管理、健康状态监测、节点扩展以及故障转移。

步骤S302，通过主节点中的目标容器监控主节点在运行过程中是否出现异常。

在步骤S302中，kuberneters应用程序会通过pod上的sidecar容器按照一定的选主规则从创建的多个pod中选取一个pod作为主节点，并将其他剩余的pod作为从节点。需要注意到的是，目标容器为节点中的sidecar容器。kuberneters应用程序通过主节点中的sidecar容器监控主节点在运行过程中是否出现异常，例如，主节点上的etcd服务出现异常。

步骤S303,在主节点出现异常时，确定主节点为待处理节点，并从至少一个从节点中选取一个从节点作为新的主节点。

在步骤S303中，当主节点中的sidecar容器监控到主节点在运行过程中出现异常时，主节点中的sidecar容器会将主节点的异常信息上报给kuberneters应用程序，然后kuberneters应用程序将发生异常的主节点确定为待处理节点，并对其进行杀死重建。同时，为了保证不影响数据库集群继续正常处理业务，kuberneters应用程序会依赖数据库集群本身的选主规则从至少一个从节点中选取一个从节点作为新的主节点，从而实现了自动转移故障的目的。

步骤S304，重新创建待处理节点，并删除待处理节点对应的网络地址。

在步骤S304中，kuberneters应用程序会对待处理节点进行杀死重建，同时在apiserver组件中将待处理节点对应的网络地址进行删除，其中，apiserver组件用于存储每个节点对应的网络地址。本申请中的网络地址为ip地址。

步骤S305，在待处理节点重建成功之后，获取目标网络地址，并根据目标网络地址确定重建成功后的待处理节点为一个新的从节点。

在步骤S305中，目标网络地址为重建成功后的待处理节点重新分配到的网络地址。

需要注意到的是，待处理节点被重建成功之后，通常kuberneters应用程序会为其分配一个新的ip地址，为了确保重建成功的待处理节点能够与新的主节点之间进行通讯，kuberneters应用程序通过新的主节点的sidecar容器检测得到目标网络地址，然后根据目标网络地址将重建成功后的待处理节点作为数据库集群中的一个新的从节点，从而实现了从节点的数量恢复至和以前一样。

容易理解的是，在正常情况下，etcd集群主节点提供写服务，从节点提供读服务，如果主节点宕机，无法提供服务，那么数据库集群便不可用。在本申请中，当主节点出现故障时，数据库集群会重新选举出一个新的主节点，而原来的主节点所在的pod则会被杀死重建，此时，重新选举出来的主节点就会监测到该pod的ip地址的变化，移除出旧pod的ip地址，并添加新pod的ip地址，从而实现了主节点的自动故障转移。

基于上述步骤S301至步骤S305的内容可知，在本申请中，采用自动重建出现异常的主节点，并从至少一个从节点中选择一个从节点作为新的主节点的方式，首先在数据库集群中创建多个节点，然后通过主节点中的目标容器监控主节点在运行过程中是否出现异常，在主节点出现异常时，确定主节点为待处理节点，并从至少一个从节点中选取一个从节点作为新的主节点，随后重新创建待处理节点，并删除待处理节点对应的网络地址，在待处理节点重建成功之后，获取目标网络地址，并根据目标网络地址确定重建成功后的待处理节点为一个新的从节点，其中，目标网络地址为重建成功后的待处理节点重新分配到的网络地址，多个节点包括一个主节点和至少一个从节点，每个节点与一个网络地址相对应，主节点用于提供数据写服务，从节点用于提供数据读服务。

由上述内容可知，本申请通过主节点中的目标容器自动监控主节点在运行过程中是否出现异常，并对出现异常的主节点进行自动重新创建，从而提高了主节点的重新创建效率。同时，本申请在主节点出现异常时，还会从至少一个从节点中选取一个从节点作为新的主节点，从而可最大程度地避免业务数据的中断处理，提高了数据库集群处理数据时的稳定性。此外，本申请在发生故障的主节点重建成功之后，获取目标网络地址，并根据目标网络地址将重建成功后的节点作为一个新的从节点，从而实现了自动故障转移的目的，不仅避免了由于主节点异常导致的业务中断，还提高了异常节点的故障修复效率。

由此可见，本申请的技术方案达到了在主节点出现故障时实现自动故障转移的目的，从而实现了提高数据库业务运行稳定性的技术效果，进而解决了现有技术中数据库集群的主节点出现故障时存在的故障修复效率低的技术问题。

在一种可选的实施例中，为了在数据库集群中创建多个节点，kuberneters应用程序首先在数据库集群中创建多个计算单元，其中，每个计算单元被分配一个网络地址。然后kuberneters应用程序从多个计算单元中随机选取一个计算单元作为主节点，并确定其他计算单元为从节点，其中，其他计算单元为多个计算单元中除主节点之外的所有计算单元。

可选的，上述的计算单元即为pod。其中，图4是根据本申请实施例一种etcd数据库集群的搭建方法的示意图，如图4所示，在部署etcd数据库集群时，首先kuberneters应用程序会在集群环境中创建三个etcd的pod，其中，三个pod的ip地址都保存在apiserver组件内。

进一步的，每个pod内部的sidecar容器会从apiserver组件中查询出该pod对的ip地址，然后，kuberneters应用程序通过pod上的sidecar容器按照一定的选主规则从三个pod中选取一个pod作为主节点，主节点上的sidecar容器会拉起主节点中的etcd进程，从而实现了主节点的初始化。

随后，主节点会从剩余的两个pod中添加一个pod到数据库集群中作为从节点，被添加到数据库集群中的从节点会拉起自身pod中的etcd进程，从而实现该从节点的初始化。最后，主节点再把剩余的最后一个pod添加到数据库集群中来，该节点也会将自身pod的etcd进程拉起来，至此，所有的节点都完成了初始化，三个节点组成的etcd数据库集群也完成了初始化，业务进程可以正常通过etcd数据库集群进etcd服务访问了。

在一种可选的实施例中，为了实现数据库集群的自动扩容功能，在从多个计算单元中随机选取一个计算单元作为主节点之后，kuberneters应用程序会通过主节点中的sidecar容器检测数据库集群中是否存在新增的计算单元，在检测到数据库集群中存在新增的计算单元的情况下，主节点中的sidecar容器会获取新增的计算单元对应的网络地址，并根据新增的计算单元对应的网络地址将新增的计算单元确定为数据库集群中新的从节点。

如图4所示，从主节点被选取出来开始，主节点上的sidecar容器便会持续地监测集群中的pod变化。具体的，当有新增的etcd的pod时，主节点便会将其作为一个从节点添加进数据库集群当中。

具体的，当需要扩展数据库集群的节点数时，用户只需要修改kuberneters应用程序中的集群副本数参数(例如，在原有的集群副本数参数的基础上加1)，则kuberneters应用程序便会新创建一个pod，该pod会被主节点上的sidecar容器监测到并作为新的从节点加入到数据库集群当中来，从而实现了集群的自动扩容。需要注意到的是，集群副本数参数用于表征数据库集群中的节点数量，例如，当集群副本数参数为3时，说明数据库集群中包含有三个节点，当集群副本数参数为5时，说明数据库集群中包含有5个节点。

在一种可选的实施例中，在从多个计算单元中随机选取一个计算单元作为主节点之后，kuberneters应用程序还会通过每个从节点上的目标容器监控每个从节点上的数据库进程是否出现异常，在任意一个从节点上的数据库进程出现异常时，kuberneters应用程序更新该从节点对应的进程标识为第一标识，并将携带有第一标识的从节点确定为第一从节点，并对第一从节点进行重新创建。

可选的，如图4所示，从主节点被选取出来开始，每个从节点上的sidecar容器也会对自身对应的从节点上的数据库进程持续进行健康检查。具体的，如果一个从节点上的数据库进程出现了异常，则该从节点上的sidecar容器便会将该从节点对应的进程标识liveness设置为第一标识false，随后kuberneters应用程序便会根据第一标识将该从节点杀死重建。

需要注意到的是，在对第一从节点进行重新创建时，kuberneters应用程序会从apiserver组件中删除第一从节点对应的网络地址，并在第一从节点重建成功之后，通过主节点中的sidecar容器获取第一网络地址，其中，第一网络地址为重建成功后的第一从节点重新分配到的网络地址。最后，kuberneters应用程序通过主节点中的sidecar容器，根据第一网络地址将重建成功后的第一从节点加入至数据库集群中。

在一种可选的实施例中，为了对从节点和主节点之间的网络通讯进行健康状态监测，在从多个计算单元中随机选取一个计算单元作为主节点之后，kuberneters应用程序通过每个从节点上的目标容器监控每个从节点与主节点之间的通讯是否出现异常，在任意一个从节点与主节点之间的通讯出现异常时，kuberneters应用程序更新该从节点对应的通讯状态标识为第二标识，将携带有第二标识的从节点确定为第二从节点，并禁止第二从节点继续提供数据读服务。最后，kuberneters应用程序从数据库集群中移除第二从节点。

如图4所示，从主节点选举出来开始，每个从节点上的sidecar容器会持续监控该从节点与主节点之间的通讯是否出现异常。具体的，如果某一个从节点与主节点之间的通讯出现异常，则该从节点上的sidecar容器会将该从节点的通讯状态标识readyness更新为第二标识false。其中，被标记为第二标识的从节点将不会被分配数据读服务的请求，即携带有第二标识的从节点被禁止继续提供数据读服务。最后，被标记为第二标识的从节点还会被移除出数据库集群。

需要注意到的是，如果是主节点的通讯服务出现异常，则主节点的通讯状态标识readyness也会被更新为第二标识false，由于负责数据写服务的主节点只有一个，因此为了保证数据写服务不会被中断，kuberneters应用程序会依赖数据库集群本身的选主规则从至少一个从节点中选取一个从节点作为新的主节点，同时，被标记为第二标识的主节点将不会被分配数据写服务的请求，kuberneters应用程序也会从数据库集群中移除被标记为第二标识的主节点。

在一种可选的实施例中，为了实现完整的数据备份，主节点和每个从节点中都存储有全量的数据，当主节点出现异常，例如宕机时，kuberneters应用程序会从至少一个从节点中选取一个从节点作为新的主节点，由于每个从节点中也存储了全量的数据，因此新的主节点中的数据是完整无缺失的全量数据。另外，当原来的主节点重建后作为新的从节点加入数据库集群时，新的主节点上会将全量数据同步给新的从节点，从而实现集群的数据备份。

具体的，kuberneters应用程序通过新的主节点上的目标容器获取目标网络地址，并根据目标网络地址将重建成功后的待处理节点确定为数据库集群中新增的目标从节点，最后，kuberneters应用程序将新的主节点中存储的所有数据同步至目标从节点中。

在一种可选的实施例中，图5是根据本申请实施例的一种可选的数据库集群的结构图，如图5所示，kuberneters应用程序在三台物理主机上分别创建一个pod。其中，每个etcd的pod内部由两个容器组成，一个容器是etcd容器，另一个容器是sidecar容器，etcd容器负责etcd服务的启动，sidecar容器负责整个集群的动态配置管理、健康状态监测、节点扩展、故障转移等。

基于图5示出的数据库集群的结构图，该数据库集群可对外提供一个服务Service，背后是使用StatefulSet来部署的集群，一般部署3个pod。其中，每个pod中有两个容器，一个容器是etcd容器，另一个容器是sidecar容器。

具体的，sidecar容器中的业务逻辑都在一个循环体中进行，会实时监测整个kuberneters环境下的数据库pod，当3个pod完全启动后，kuberneters应用程序通过pod上的sidecar容器按照一定的选主规则在3个pod中选出一个主节点并拉起主节点的数据库进程。

kuberneters应用程序通过主节点上的sidecar容器监测kuberneters集群上的pod变化，将从Apiserver组件中查询到的pod的ip地址与数据库集群中的成员节点ip地址进行比对，对于pod中有但是尚未加入到数据库集群中的成员，要将其加入数据库集群中。对于数据库集群中非健康状态的节点(即通讯状态标识为第二标识的节点)，kuberneters应用程序会将其移除出集群。

另外，对于已经加入集群的节点，需要将其相应的数据库进程拉起。

最后，每个节点中的sidecar容器都会实时监测自身节点中的数据库进程的状态，一旦某个节点的数据库进程出现了异常，该节点的sidecar容器便会将该节点的进程标识liveness设置为第一标识false，然后由kuberneters应用程序杀死该节点并对该节点进行重建。与此同时，每个节点中的sidecar容器还会实时监测自身节点的通讯状态，对于通讯异常的节点，该节点中的sidecar容器会将该节点的通讯状态标识readyness设置为第二标识false,此时该节点对应的数据读/写请求便不会被分配到该节点中。

可选的，在一种应用场景下，为了提高部署效率，在部署etcd服务的高可用集群时，依据本申请的技术方案可以使用statefulSet进行部署，部署三个副本，在每个pod中部署两个容器，一个容器中包含etcd的启动进程，另一个容器中就是sidecar进程。可以将sidecar监控节点的业务逻辑通过golang代码实现并编译成可执行的二进制文件，然后将该二进制文件打包进sidecar容器镜像中，在pod创建成功时会自动执行sidecar的二进制文件，从而实现对于整个etcd集群的管理，可以实现etcd集群的自动故障转移、健康状态监测、自动扩容及数据备份等功能。

由上述内容可知，本申请的技术方案可至少带来以下技术效果：

(1)部署方式简单且可以复用：部署数据库集群时，只需要一份yaml文件即可完成，避免了繁琐的各种配置，且可以复用到其他的kuberneters集群上。

(2)集群自动扩容：通过sidecar容器对整个数据库集群进行管理，可以实现数据库集群的自动扩容。当需要增加节点以满足数据存储需求时，只需要修改集群副本数参数，sidecar程序会自动在集群中增加相应的节点。

(3)实时监测健康状态：sidecar容器会实时监测数据库集群中每个节点的健康状态。当节点因为网络等原因无法正常对外提供服务时，会将其readyness设置为false，此时kuberneters便不会将请求分配到该节点。当节点自身的etcd进程出现故障时，kuberneters会重建该节点。

(4)自动故障转移与节点恢复：当主节点发生故障，集群会通过自动重新选取主节点来转移故障，并重建发生故障的主节点作为新的从节点加入至数据库集群中，从而实现节点的自动恢复。

(5)资源使用效率高：由于数据库部署在kuberneters集群上，kuberneters对集群内的资源调度进行了优化，因此可以根据node节点上的cpu、内存使用情况进行扩缩容，资源使用效率高。

实施例2

根据本申请实施例，还提供了一种数据库集群的节点管理装置的实施例，如图6所示，该装置包括：节点创建模块601，用于在数据库集群中创建多个节点，其中，多个节点包括一个主节点和至少一个从节点，每个节点与一个网络地址相对应，主节点用于提供数据写服务，从节点用于提供数据读服务；监控模块602，用于通过主节点中的目标容器监控主节点在运行过程中是否出现异常；第一确定模块603，用于在主节点出现异常时，确定主节点为待处理节点，并从至少一个从节点中选取一个从节点作为新的主节点；节点重建模块604，用于重新创建待处理节点，并删除待处理节点对应的网络地址；第二确定模块605，用于在待处理节点重建成功之后，获取目标网络地址，并根据目标网络地址确定重建成功后的待处理节点为一个新的从节点，其中，目标网络地址为重建成功后的待处理节点重新分配到的网络地址。

具体的，上述的数据库集群可以是各种类型的数据库集群，例如，etcd数据库集群，mongo数据库集群、clickhouse数据库集群等，具体根据所提供的数据库类型来确定。为了方便描述，本申请以etcd数据库集群为例进行以下说明。

在本申请中，使用kuberneters应用程序作为本申请实施例的数据库集群的节点管理方法的执行主体。首先，通过kuberneters应用程序在etcd数据库集群中创建多个计算单元pod，其中，每个pod位于一台物理主机上，并且每个pod为一个节点，每个pod被分配一个独立的ip地址。另外，还需要注意到的是，每个pod内部由两个容器组成，一个是etcd容器，用于管理etcd服务进程，例如，用于启动节点上的etcd服务。另一个容器为sidecar容器，用于负责整个etcd数据库集群的动态配置管理、健康状态监测、节点扩展以及故障转移。

在一种可选的实施例中，kuberneters应用程序会通过pod上的sidecar容器按照一定的选主规则从创建的多个pod中选取一个pod作为主节点，并将其他剩余的pod作为从节点。需要注意到的是，目标容器为节点中的sidecar容器。kuberneters应用程序通过主节点中的sidecar容器监控主节点在运行过程中是否出现异常，例如，主节点上的etcd服务出现异常。

当主节点中的sidecar容器监控到主节点在运行过程中出现异常时，主节点中的sidecar容器会将主节点的异常信息上报给kuberneters应用程序，然后kuberneters应用程序将发生异常的主节点确定为待处理节点，并对其进行杀死重建。同时，为了保证不影响数据库集群继续正常处理业务，kuberneters应用程序会依赖数据库集群本身的选主规则从至少一个从节点中随机选取一个从节点作为新的主节点，从而实现了自动转移故障的目的。

需要注意到的是，kuberneters应用程序在对待处理节点进行杀死重建时，还会在apiserver组件中将待处理节点对应的网络地址进行删除，其中，apiserver组件用于存储每个节点对应的网络地址。本申请中的网络地址为ip地址。

待处理节点被重建成功之后，通常kuberneters应用程序会为其分配一个新的ip地址，为了确保重建成功的待处理节点能够与新的主节点之间进行通讯，kuberneters应用程序通过新的主节点的sidecar容器检测得到目标网络地址，然后根据目标网络地址将重建成功后的待处理节点作为数据库集群中的一个新的从节点，从而实现了从节点的数量恢复至和以前一样。

容易理解的是，在正常情况下，etcd集群主节点提供写服务，从节点提供读服务，如果主节点宕机，无法提供服务，那么数据库集群便不可用。在本申请中，当主节点出现故障时，数据库集群会重新选举出一个新的主节点，而原来的主节点所在的pod则会被杀死重建，此时，重新选举出来的主节点就会监测到该pod的ip地址的变化，移除出旧pod的ip地址，并添加新pod的ip地址，从而实现了主节点的自动故障转移。

可选的，上述的节点创建模块还包括：第一创建单元以及第一确定单元。其中，第一创建单元，用于在数据库集群中创建多个计算单元，其中，每个计算单元被分配一个网络地址；第一确定单元，用于从多个计算单元中随机选取一个计算单元作为主节点，并确定其他计算单元为从节点，其中，其他计算单元为多个计算单元中除主节点之外的所有计算单元。

在一种可选的实施例中，上述的计算单元即为pod。其中，图4是根据本申请实施例一种etcd数据库集群的搭建方法的示意图，如图4所示，在部署etcd数据库集群时，首先kuberneters应用程序会在集群环境中创建三个etcd的pod，其中，三个pod的ip地址都保存在apiserver组件内。

进一步的，每个pod内部的sidecar容器会从apiserver组件中查询出该pod对的ip地址，然后，kuberneters应用程序通过pod上的sidecar容器按照一定的选主规则从三个pod中选取一个pod作为主节点，主节点上的sidecar容器会拉起主节点中的etcd进程，从而实现了主节点的初始化。

随后，主节点会从剩余的两个pod中添加一个pod到数据库集群中作为从节点，被添加到数据库集群中的从节点会拉起自身pod中的etcd进程，从而实现该从节点的初始化。最后，主节点再把剩余的最后一个pod添加到数据库集群中来，该节点也会将自身pod的etcd进程拉起来，至此，所有的节点都完成了初始化，三个节点组成的etcd数据库集群也完成了初始化，业务进程可以正常通过etcd数据库集群进etcd服务访问了。

可选的，数据库集群的节点管理装置还包括：检测模块、第一获取模块以及第三确定模块。其中，检测模块，用于检测数据库集群中是否存在新增的计算单元；第一获取模块，用于在检测到数据库集群中存在新增的计算单元的情况下，获取新增的计算单元对应的网络地址；第三确定模块，用于根据新增的计算单元对应的网络地址将新增的计算单元确定为数据库集群中新的从节点。

如图4所示，从主节点被选取出来开始，主节点上的sidecar容器便会持续地监测集群中的pod变化，当有新增的etcd的pod时，主节点便会将其作为一个从节点添加进数据库集群当中。

具体的，当需要扩展数据库集群的节点数时，用户只需要修改kuberneters应用程序中的集群副本数参数(例如，在原有的集群副本数参数的基础上加1)，则kuberneters应用程序便会新创建一个pod，该pod会被主节点上的sidecar容器监测到并作为新的从节点加入到数据库集群当中来，从而实现了集群的自动扩容。需要注意到的是，集群副本数参数用于表征数据库集群中的节点数量，例如，当集群副本数参数为3时，说明数据库集群中包含有三个节点，当集群副本数参数为5时，说明数据库集群中包含有5个节点。

可选的，数据库集群的节点管理装置还包括：第一监控模块、第一更新模块以及从节点重建模块。其中，第一监控模块，用于通过每个从节点上的目标容器监控每个从节点上的数据库进程是否出现异常；第一更新模块，用于在任意一个从节点上的数据库进程出现异常时，更新该从节点对应的进程标识为第一标识；从节点重建模块，用于将携带有第一标识的从节点确定为第一从节点，并对第一从节点进行重新创建。

如图4所示，从主节点被选取出来开始，每个从节点上的sidecar容器也会对自身对应的从节点上的数据库进程持续进行健康检查。具体的，如果一个从节点上的数据库进程出现了异常，则该从节点上的sidecar容器便会将该从节点对应的进程标识liveness设置为第一标识false，随后kuberneters应用程序便会根据第一标识将该从节点杀死重建。

可选的，从节点重建模块还包括：第一删除单元、第一获取单元以及添加单元。其中，第一删除单元，用于删除第一从节点对应的网络地址；第一获取单元，用于在第一从节点重建成功之后，获取第一网络地址，其中，第一网络地址为重建成功后的第一从节点重新分配到的网络地址；添加单元，用于根据第一网络地址将重建成功后的第一从节点加入至数据库集群中。

可选的，数据库集群的节点管理装置还包括：第二监控模块、第二更新模块、禁止模块以及移除模块。其中，第二监控模块，用于通过每个从节点上的目标容器监控每个从节点与主节点之间的通讯是否出现异常；第二更新模块，用于在任意一个从节点与主节点之间的通讯出现异常时，更新该从节点对应的通讯状态标识为第二标识；禁止模块，用于将携带有第二标识的从节点确定为第二从节点，并禁止第二从节点继续提供数据读服务；移除模块，用于从数据库集群中移除第二从节点。

如图4所示，从主节点选举出来开始，每个从节点上的sidecar容器会持续监控该从节点与主节点之间的通讯是否出现异常。具体的，如果某一个从节点与主节点之间的通讯出现异常，则该从节点上的sidecar容器会将该从节点的通讯状态标识readyness更新为第二标识false。其中，被标记为第二标识的从节点将不会被分配数据读服务的请求，即携带有第二标识的从节点被禁止继续提供数据读服务。最后，被标记为第二标识的从节点还会被移除出数据库集群。

需要注意到的是，如果是主节点的通讯服务出现异常，则主节点的通讯状态标识readyness也会被更新为第二标识false，由于负责数据写服务的主节点只有一个，因此为了保证数据写服务不会被中断，kuberneters应用程序会依赖数据库集群本身的选主规则从至少一个从节点中选取一个从节点作为新的主节点，同时，被标记为第二标识的主节点将不会被分配数据写服务的请求，kuberneters应用程序也会从数据库集群中移除被标记为第二标识的主节点。

可选的，上述的第二确定模块还包括：第二获取单元、第二确定单元以及数据同步单元。其中，第二获取单元，用于通过新的主节点上的目标容器获取目标网络地址；第二确定单元，用于根据目标网络地址将重建成功后的待处理节点确定为数据库集群中新增的目标从节点；数据同步单元，用于将新的主节点中存储的所有数据同步至目标从节点中。

具体的，kuberneters应用程序通过新的主节点上的目标容器获取目标网络地址，并根据目标网络地址将重建成功后的待处理节点确定为数据库集群中新增的目标从节点，最后，kuberneters应用程序将新的主节点中存储的所有数据同步至目标从节点中。

在一种可选的实施例中，图5是根据本申请实施例的一种可选的数据库集群的结构图，如图5所示，kuberneters应用程序在三台物理主机上分别创建一个pod。其中，每个etcd的pod内部由两个容器组成，一个容器是etcd容器，另一个容器是sidecar容器，etcd容器负责etcd服务的启动，sidecar容器负责整个集群的动态配置管理、健康状态监测、节点扩展、故障转移等。

基于图5示出的数据库集群的结构图，该数据库集群可对外提供一个服务Service，背后是使用StatefulSet来部署的集群，一般部署3个pod。其中，每个pod中有两个容器，一个容器是etcd容器，另一个容器是sidecar容器。

具体的，sidecar容器中的业务逻辑都在一个循环体中进行，会实时监测整个kuberneters环境下的数据库pod,当3个pod完全启动后，kuberneters应用程序在3个pod中选出一个主节点并拉起主节点的数据库进程。

kuberneters应用程序通过主节点上的sidecar容器监测kuberneters集群上的pod变化，将从Apiserver组件中查询到的pod的ip地址与数据库集群中的成员节点ip地址进行比对，对于pod中有但是尚未加入到数据库集群中的成员，要将其加入数据库集群中。对于数据库集群中非健康状态的节点(即通讯状态标识为第二标识的节点)，kuberneters应用程序会将其移除出集群。

另外，对于已经加入集群的节点，需要将其相应的数据库进程拉起。

最后，每个节点中的sidecar容器都会实时监测自身节点中的数据库进程的状态，一旦某个节点的数据库进程出现了异常，该节点的sidecar容器便会将该节点的进程标识liveness设置为第一标识false，然后由kuberneters应用程序杀死该节点并对该节点进行重建。与此同时，每个节点中的sidecar容器还会实时监测自身节点的通讯状态，对于通讯异常的节点，该节点中的sidecar容器会将该节点的通讯状态标识readyness设置为第二标识false,此时该节点对应的数据读/写请求便不会被分配到该节点中。

可选的，在一种应用场景下，为了提高部署效率，在部署etcd服务的高可用集群时，依据本申请的技术方案可以使用statefulSet进行部署，部署三个副本，在每个pod中部署两个容器，一个容器中包含etcd的启动进程，另一个容器中就是sidecar进程。可以将sidecar监控节点的业务逻辑通过golang代码实现并编译成可执行的二进制文件，然后将该二进制文件打包进sidecar容器镜像中，在pod创建成功时会自动执行sidecar的二进制文件，从而实现对于整个etcd集群的管理，可以实现etcd集群的自动故障转移、健康状态监测、自动扩容及数据备份等功能。

由上述内容可知，本申请的技术方案可至少带来以下技术效果：

(1)部署方式简单且可以复用：部署数据库集群时，只需要一份yaml文件即可完成，避免了繁琐的各种配置，且可以复用到其他的kuberneters集群上。

(2)集群自动扩容：通过sidecar容器对整个数据库集群进行管理，可以实现数据库集群的自动扩容。当需要增加节点以满足数据存储需求时，只需要修改集群副本数参数，sidecar程序会自动在集群中增加相应的节点。

(3)实时监测健康状态：sidecar容器会实时监测数据库集群中每个节点的健康状态。当节点因为网络等原因无法正常对外提供服务时，会将其readyness设置为false，此时kuberneters便不会将请求分配到该节点。当节点自身的etcd进程出现故障时，kuberneters会重建该节点。

(4)自动故障转移与节点恢复：当主节点发生故障，集群会通过自动重新选取主节点来转移故障，并重建发生故障的主节点作为新的从节点加入至数据库集群中，从而实现节点的自动恢复。

(5)资源使用效率高：由于数据库部署在kuberneters集群上，kuberneters对集群内的资源调度进行了优化，因此可以根据node节点上的cpu、内存使用情况进行扩缩容，资源使用效率高。

实施例3

根据本申请实施例的另一方面，还提供了一种计算机可读存储介质。其中，计算机可读存储介质中存储有计算机程序，计算机程序被设置为运行时执行上述实施例1中的数据库集群的节点管理方法。

实施例4

根据本申请实施例的另一方面，还提供了一种电子设备，该电子设备包括一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现用于运行程序，其中，程序被设置为运行时执行上述实施例1中的数据库集群的节点管理方法。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。