CN111367998A - 基于Galera的数据库集群恢复方法及终端设备 - Google Patents

Abstract

本发明提供了一种基于Galera的数据库集群恢复方法，数据库集群包含两个或者两个以上的数据库节点，在全部数据库节点不可用时通过该方法进行同步恢复，方法包括：重启各数据库节点，将各数据库节点目录中所包含的grastate.dat文件中seqno值为‑1的数据库节点作为异常关机的数据库节点；当数据库集群中的数据库节点均为异常关机时，遍历查找出数据库节点的gvwstate.dat文件中所包含的my_uuid等于view_id的数据库节点，以作为启动节点，并以bootstrap模式启动同步操作。通过本申请所揭示的技术方案，有效地避免了数据库集群中残留文件的问题，提高了基于Galera的数据库集群运行时的可靠性与稳定性；并保证了基于Galera的数据库集群的强一致性。

Description

基于Galera的数据库集群恢复方法及终端设备

技术领域

本发明涉及数据库技术领域，尤其涉及一种基于Galera的数据库集群恢复方法及终端设备。

背景技术

传统的MVC单系统架构(Model View Controller)或者是早期的基于PHP、MYSQL及NGINX的架构中，业务与功能都耦合在一起并部署在一个服务器节点上。随着业务量以及QPS迅速增长，现有的传统业务架构已经无法满足海量业务以及QPS的迅速增长。因此，分布式的服务架构应运而生。

MySQL数据库是目前云平台中常用的一种数据库架构，其内建的复制功能是构建大型，高性能应用程序的基础。MySQL数据库所具有的主从架构实现了数据库的主从复制和读写分离功能，一方面保证了系统的高可用性，另一方面提升了数据库的并发负载能力及数据分片能力，以保证数据的一致性以及对用户的透明要求。但是，当主服务器数据量很大时，创建从服务器耗时与主服务器的数据量成正比，需要花费大量的时间拷贝数据到从服务器；另外，由于主服务器和各个从服务器所留存的数据是相同的，从而造成磁盘空间的浪费。

基于Galera的数据库集群是一种集成了Galera插件的MySQL集群，是一种数据不共享且高度冗余的高可用数据库。Galera数据库是一种在分布式场景中仍然能够保证数据一致性，能够完整实现ACID(数据库事务正确执行)。然而，现有技术中的分布式数据库只能实现最终一致性，而无法实时一致性。这种缺陷导致基于Galera插件的分布式数据库在实时性要求苛刻的行业，例如金融、电商、云计算服务等场景中就会产生非常大的影响，并导致支付失败、重复支付、服务无法响应等问题。基于Galera数据库的集群中的节点因为硬盘故障、电源故障或者掉电时，会导致该节点脱离数据库集群，由此需要运维人员以人工登录后台的方式执行故障排除，并重启数据库集群，但是运维人员实际上不太可能准确知悉那个节点中的数据是最新数据，从而导致重启数据库集群后的数据无法保证强一致性。

公开号为CN105471622A的中国发明专利公开了一种基于Galera的控制节点主备切换的高可用方法及系统。该现有技术虽然揭示了Galera MySQL数据库，为了保持控制节点A与控制节点B之间的数据同步，其指出通过心跳检测的手段予以实现，但是心跳检测只能检测到数据库第三层的二维数据表(Table)，而无法检测到第四层的字段(Filed)，由于只有字段才能表征数据的唯一性。因此，该现有技术存在检测程度不高而导致的主从节点中的数据无法有效同步且存在数据一致性不高的缺陷；同时，该现有技术所揭示的技术方案无法满足三个或者节点数量更多的使用场景。

有鉴于此，有必要对现有技术中的基于Galera插件的数据库集群相关技术予以改进，以解决上述存在的诸多问题。

发明内容

本发明的目的在于揭示一种基于Galera的数据库集群恢复方法及应用该基于Galera的数据库集群恢复方法的一种终端设备，用以克服现有技术所存在的上述缺陷，尤其是为了确保Galera数据库集群在节点出现故障时进行恢复时具有强一致性，简化后期维护难度，提高整个基于Galera的数据库集群运行时的稳定性及可靠性，避免使用多余组件，以挺高基于Galera的数据库集群的可靠性及强一致性。

为实现上述第一个发明目的，本发明提供了一种基于Galera的数据库集群恢复方法，所述数据库集群包含两个或者两个以上的数据库节点，在全部数据库节点不可用时通过所述方法进行同步恢复，所述方法包括：

重启各数据库节点，将各数据库节点目录中所包含的grastate.dat文件中seqno值为-1的数据库节点作为异常关机的数据库节点；

当数据库集群中的数据库节点均为异常关机时，遍历查找出数据库节点的gvwstate.dat文件中所包含的my_uuid等于view_id的数据库节点，以作为启动节点，并以bootstrap模式启动同步操作。

作为本发明的进一步改进，在重启各数据库节点之前还包括：

在各数据库节点中部署控制服务组件，并通过独立于数据库节点的监控系统确定控制服务组件是否处于开启状态。

作为本发明的进一步改进，所述监控系统选自Prometheus组件和/或zabbix组件。

作为本发明的进一步改进，在重启各数据库节点之后还包括：获取并保存数据库节点的IP列表，所述IP列表保存至数据库集群的hosts文件中。

作为本发明的进一步改进，所述方法还包括：

使用Systemd服务或者SQL查询语句对数据库节点是否处于健康状态进行判断，以提取健康数据库节点；

当存在唯一的健康数据库节点时，以所述健康数据库节点作为启动节点，以作为基于Galera的数据库集群的主节点，以执行Galera同步操作；

当存在两个或者两个以上健康数据库节点时，根据所述hosts文件中任意一个IP列表所对应的数据库节点作为基于Galera的数据库集群的主节点，并以bootstrap模式启动同步操作。

作为本发明的进一步改进，设定使用Systemd服务或者SQL查询语句对数据库节点进行健康状态进行判断的循环检测周期，所述循环检测周期为30秒至60秒。

作为本发明的进一步改进，所述方法还包括：

统计异常关机的数据库节点的数量，并判断异常关机的数据库节点数量是否小于或者等于1；

若是，以异常关机的数据库节点或者将数据库集群的hosts文件中的第一个数据库节点作为启动节点，并以bootstrap模式启动同步操作；

若否，遍历查找出数据库节点的gvwstate.dat文件中所包含的my_uuid等于view_id的数据库节点，以作为启动节点，并以bootstrap模式启动同步操作。

作为本发明的进一步改进，所述控制服务组件使用SSHD服务下发控制服务至各数据库节点。

基于相同发明思想，本申请还公开了一种终端设备，包括：处理器，存储装置，以及在处理器与存储装置之间建立通信连接的通信总线；

所述处理器用于执行存储装置中存储的一个或者多个程序，以实现上述任一项发明创造所揭示的基于Galera的数据库集群恢复方法。

与现有技术相比，本发明的有益效果是：

首先，由于不需要为数据库集群单独配置ETCD、Zookeeper等组件，有效地避免了数据库集群中残留文件的问题，并降低了对数据库集群资源的消耗，并使得整个数据库集群的拓扑结构更为简化，且整个同步操作的配置过程及同步过程均可Linux系统所通用的SSHD服务予以实现，因此显著地提高了基于Galera的数据库集群运行时的可靠性与稳定性；

其次，本发明能够在所有数据库节点均为异常关闭时快速地确定最新的数据库节点，并基于Galera故障恢复策略执行同步操作，以保证各数据库节点中的数据均为最新数据，从而保证了基于Galera的数据库集群的强一致性，有效地解决了数据库节点因断电、设备故障所导致的各个数据库节点中的数据在上电恢复后留存数据不一致的问题。

附图说明

图1为本发明基于Galera的数据库集群恢复方法的整体流程图；

图2为基于图1所示出的基于Galera的数据库集群恢复方法对含有三个数据库节点的数据库集群的实例环境中，通过Galera集群恢复策略执行同步操作的示意图；

图3为本发明基于Galera的数据库集群恢复方法所包含的主流程的详细流程图；

图4为本发明基于Galera的数据库集群恢复方法所包含的子流程的详细流程图；

图5为本发明一种终端设备的拓扑图，该终端设备运行图1所揭示的基于Galera的数据库集群恢复方法。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

术语“逻辑”包括用于执行任务的任何物理和有形功能。例如，流程图中所示的每个操作对应于用于执行该操作的逻辑组件。可以使用例如在计算机设备上运行的软件、硬件(例如，芯片实现的逻辑功能)等、和/或其任何组合来执行操作。当由计算设备实现时，逻辑组件表示作为无论以何种方式实现的计算机系统的物理部分的电组件。

短语“配置为”或者短语“被配置为”包括可以构造任何种类的物理和有形的功能以执行标识的操作的任何方式。功能可以被配置为使用例如在计算机设备上运行的软件、硬件(例如，芯片实现的逻辑功能)等、和/或其任何组合来执行操作。

实施例一：

参图1至图4所揭示的本发明基于Galera的数据库集群恢复方法的一种具体实施方式。

在本实施例中，基于Galera集群恢复策略执行同步操作。参图2所示，该基于Galera的数据库集群恢复方法(以下简称“恢复方法”或者“方法”)对含有三个数据库节点的数据库集群的实例环境中，通过Galera集群恢复策略执行同步操作。数据库集群包含两个或者两个以上的数据库节点；具体的，在本实施例中，该数据库集群包含三个节点，即数据库节点10、数据库节点20及数据库节点30，数据库节点10部署于主机1中，数据库节点20部署于主机2中，数据库节点30部署于主机3中，且主机1～主机3可被理解为云主机、物理机、虚拟机或者嵌入运行操作系统程序的各种计算机装置。当然，在实际运行环境中，还可被配置为节点数量更多的数据库集群。Galera复制是一种基于验证的复制。基于验证的复制使用组通信和事务排序技术实现同步复制。它通过广播并发事务之间建立的全局总序来协调事务提交。简单说就是事务必须以相同的顺序应用于所有实例。Seqno字段的值是节点的状态ID的值，即状态ID的值为grastate.dat文件的配置中seqno字段的值。状态ID的值通过全局事务ID获取。本实施例所揭示的恢复方法旨在当数据库节点10～数据库节点30不可用时通过本实施例所揭示的方法对各个数据库节点之间对最新数据进行同步恢复，斌旨在确定最新的数据库节点。

数据库节点10～数据库节点30的不可用通常是由于主机1～主机3因为硬盘故障、意外断电或者系统故障等原因所导致的。在本实施例中，若主机1～主机3在正常运行状态下，可基于Galera(即Galera Cluster)是集成了Galera插件的MySQL集群，是一种新型数据不共享且高度冗余的高可用方案所具有的多主复制原理保持各个数据库节点之间的数据强一致性。Galera配置文件被部署至数据库节点10～数据库节点30中。在三节点实例中，只有有一个处于健康状态的数据库节点，即使其他两个数据库节点所属的主机被正常关机或者因为断电所导致的异常关机，则上述两个数据库节点所属的主机再重新上电后，也能够基于Galera插件执行事务数据库同步写集(wsrepset)复制，从而完成各数据库节点的同步恢复操作，以避免数据库集群发生脑裂。

参图1、图3及图4所示，该基于Galera的数据库集群恢复方法，在全部数据库节点不可用时通过所述方法进行同步恢复，所述方法包括：

步骤S1、重启各数据库节点，将各数据库节点目录中所包含的grastate.dat文件中seqno值为-1的数据库节点作为异常关机的数据库节点。

在重启各数据库节点之前还包括：在各数据库节点中部署控制服务组件，并通过独立于数据库节点的监控系统确定控制服务组件是否处于开启状态。具体的，监控系统选自Prometheus组件和/或zabbix组件。控制服务组件参图2独立部署于主机1～主机3中的控制服务组件，控制服务组件使用SSHD服务下发控制服务至各数据库节点。SSH是目前较可靠，专为远程登陆会话和其他网络服务提供安全性的协议。利用SSH协议可以有效防止远程管理过程中的信息泄露问题。进程控制命令，ssh-------->sshd(ssh用为客户端，主要进行服务器端的连接；sshd用为服务器端)。SSHD是SSH服务器的配置文件，且是针对服务端的配置文件。在本实施例中，由于基于该恢复方法所对应的整个同步操作的配置过程及同步过程均可Linux系统所通用的SSHD服务予以实现，因此无需为数据库集群或者配置该数据库集群的云平台配置额外的组件。由于不需要为数据库集群单独配置ETCD、Zookeeper等组件，有效地避免了数据库集群中残留文件的问题，并降低了对数据库集群资源的消耗，并使得整个数据库集群的拓扑结构更为简化。由此，显著地提高了基于Galera的数据库集群运行时的可靠性与稳定性。需要说明的是，本实施例中所指控制服务组件执行的下发控制服务所对应的指令涵盖对数据库节点是否处于健康状态的操作、启动同步操作、统计异常关机的数据库节点的数量等各种指令或者进程。另一方面，也能降低运行该方法的数据库集群对CPU、内存、磁盘等物理组件的开销，有利于降低配置数据库集群的云平台、计算机集群的部署成本与后期维护成本。

在重启各数据库节点之后，该方法还包括：获取并保存数据库节点的IP列表，所述IP列表保存至数据库集群的hosts文件中。在Linux系统中，hosts文件是Linux系统中一个负责IP地址与域名快速解析的文件，以ASCII格式保存在“/etc”目录下hosts文件包含了IP地址和主机名之间的映射，还包括主机名的别名。在没有域名服务器的情况下，系统上的所有网络程序都通过查询该文件来解析对应于某个主机名的IP地址，否则就需要使用DNS服务程序来解决。Linux主机名的相关配置文件就是/etc/hosts，并基于hosts文件记录主机域名所对应的IP，主机名所对应的IP。其中，主机名(Hostname)即图2中所示出的主机1～主机3的保存于hosts文件中的名称。在Windows系统中，hosts文件的保存路径是windows\system32\drivers\etc。

结合图3所示，本实施例所揭示的方法中包含一种主流程。该主流程并非必须予以全部执行，即直接执行如图4所示出的子流程。

该主流程或者称之为前置流程包括步骤11～步骤18。

步骤11、主流程开始。跳转执行步骤12、判断数据库节点是否处于健康状态进行，以提取健康数据库节点。步骤13、获取并保存数据库节点的IP列表。步骤14、判断数据库节点是否均为健康数据库节点；若是，则跳转执行步骤15，主流程结束；若否，则跳转执行下一个判断步骤，即步骤16、判断是否存在唯一的健康数据库节点(即上次数据库节点的不可用是由于正常关闭所导致的)。同时，申请人指出，所谓的正常关闭与部署数据库节点的主机正常关机形成，且正常。若存在唯一的健康数据库节点，则跳转执行步骤17、Mormal模式启动该唯一的健康数据库节点，若不存在唯一的健康数据库节点，则结束该主流程，并执行步骤18、跳转至子流程，以执行子流程中的步骤21～步骤30。

在实施例中，该方法还包括：

使用Systemd服务或者SQL查询语句对数据库节点是否处于健康状态进行判断，以提取健康数据库节点；具体的，设定使用Systemd服务或者SQL查询语句对数据库节点进行健康状态进行判断的循环检测周期，所述循环检测周期为30秒至60秒。本实施例所揭示的方法在对各数据库节点是否为健康节点(即上次数据库节点的不可用是由于异常关闭所导致的)并需要依赖数据库节点的各种进程，例如写入进程(database writer process，DBWn)等核心进程予以判断。由于数据库节点在运行过程中可能因为具体环境配置的复杂度出现进程中止、僵死，从而错误地将某个或者某些个数据库节点判定为异常节点(即上次不可用是由于异常关机所导致的)。因此，使用Systemd服务和/或SQL查询语句对数据库节点进行健康状态进行判断能够最为准确的对数据库节点是否为健康节点进行判断，从而有效避免了对数据库节点的误判操作。

当存在唯一的健康数据库节点时，以所述健康数据库节点作为启动节点，以作为基于Galera的数据库集群的主节点，以执行Galera同步操作。参图2所示，若数据库节点10的目录中所包含的grastate.dat文件中seqno值为0，则将该数据库节点10认定为健康节点，其所保存的数据即最新、最完整的数据。于此场景中，只需要基于Galera插件执行同步操作102、同步恢复操作101及同步恢复操作103，即可实现多数据库节点之间的恢复操作，以将数据库节点10的最新、最完整的数据复制到数据库节点20与数据库节点30中。

当存在两个或者两个以上健康数据库节点时，根据所述hosts文件中任意一个IP列表所对应的数据库节点作为基于Galera的数据库集群的主节点，并以bootstrap模式启动同步操作。参图2所示，当数据库集群中的数据库节点10与数据库节点20均为健康节点时，则可将数据库节点10或者数据库节点20中的任意一个数据库节点作为主节点，并基于Galera的数据库集群的多主复制机制，进行恢复操作，以将数据库节点10或者数据库节点20的数据同步至数据库节点30中。

前述过程是数据库集群仍然存在正常关机的数据库节点的情况下，在数据库集群重新上电后进行各数据库节点间同步恢复的过程。但在实际情况中，如果存在两个异常关闭的数据库节点或者全部的数据库节点均为异常关闭时，则需要通过该方法确定哪个异常关闭的数据库节点中留存的数据为最新、最全的数据。由此，开始执行如图4所示出的子流程中所包含的步骤21～步骤30。

步骤S2、当数据库集群中的数据库节点均为异常关机时，遍历查找出数据库节点的gvwstate.dat文件中所包含的my_uuid等于view_id的数据库节点，以作为启动节点，并以bootstrap模式启动同步操作。

当数据库集群中的数据库节点均为异常关机时，各数据库节点目录中所包含的grastate.dat文件中seqno值为-1。此时需要执行如图4所示出的子流程所含步骤。数据库节点如果正常关闭的话，gvwstate.dat文件是不存在的，如果三个节点同时关闭(无数据变化)seqno值应该是相等的，且seqno值不为-1。如果这个时候无论先后顺利启动哪个数据库节点，都会导致所有数据库节点都在不断重启中，并且seqno值由原来的值变为-1。此时无法选举出来哪个作为主节点(即作为启动节点)，需要再第一个节点启动时手动指定该节点作为数据库集群的主节点启动。

步骤21、子流程开始。

步骤22、遍历所有数据库节点。

步骤23、判断数据库节点的grastate.dat文件中seqno值是否均为-1，若是，则跳转执行步骤24；若否，则跳转执行步骤24，以结束本子流程。

步骤24、统计grastate.dat文件所包含的seqno值为-1的数据库节点数量，从而统计异常关机的数据库节点的数量，

步骤25、判断grastate.dat文件所包含的seqno值为-1的数据库节点数量是否小于或者等于1，当grastate.dat文件所包含的seqno值为-1的数据库节点数量等于1表示该数据库集群中仅存在一个异常关机的数据库节点。当grastate.dat文件所包含的seqno值为-1的数据库节点数量等于0表示表示该数据库集群中的数据库节点均为正常关机。基于步骤25的判断，若是，则跳转执行步骤26、以异常关机的数据库节点或者将数据库集群的hosts文件中的第一个数据库节点作为启动节点，并以bootstrap模式启动同步操作，以执行恢复操作；若否，则跳转执行步骤27。所谓bootstrap模式是指启动节点以携带--wsrep-new-cluster参数启动。

步骤27、遍历查找出数据库节点的gvwstate.dat文件中所包含的my_uuid等于view_id的数据库节点，以作为启动节点，跳转执行步骤28、以bootstrap模式启动同步操作，并在同步操作完成之后跳转执行步骤30，以以结束子流程。若通过步骤27判断后认定不在存在my_uuid等于view_id的数据库节点，则跳转执行步骤29、判断遍历是否完成，若是则跳转执行步骤30，以结束子流程；若否，则重新执行遍历，然后跳转执行步骤22。

至此，本实施例所示出的方法执行完毕。

实施例二：

结合图5所示，本实施例揭示了一种终端设备100的一种具体实施方式。

在本实施例中，终端设备100，包括：处理器51，存储装置52，以及在处理器51与存储装置52之间建立通信连接的通信总线53。处理器51用于执行存储装置52中存储的一个或者多个程序，该程序为如实施例一所述的基于Galera的数据库集群恢复方法。存储装置52由存储单元521～存储单元52i组成，参数i取大于或者等1的正整数。该终端设备100可被理解为一种计算机，一种集群服务器，或者云平台。

本实施例所揭示的终端设备100所依赖/包含的基于Galera的数据库集群恢复方法的具体技术方案，请参实施例一所述，在此不再赘述。

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

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

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (9)

1.一种基于Galera的数据库集群恢复方法，所述数据库集群包含两个或者两个以上的数据库节点，在全部数据库节点不可用时通过所述方法进行同步恢复，其特征在于，所述方法包括：

重启各数据库节点，将各数据库节点目录中所包含的grastate.dat文件中seqno值为-1的数据库节点作为异常关机的数据库节点；

当数据库集群中的数据库节点均为异常关机时，遍历查找出数据库节点的gvwstate.dat文件中所包含的my_uuid等于view_id的数据库节点，以作为启动节点，并以bootstrap模式启动同步操作。

2.根据权利要求1所述的基于Galera的数据库集群恢复方法，其特征在于，在重启各数据库节点之前还包括：

在各数据库节点中部署控制服务组件，并通过独立于数据库节点的监控系统确定控制服务组件是否处于开启状态。

3.根据权利要求2所述的基于Galera的数据库集群恢复方法，其特征在于，所述监控系统选自Prometheus组件和/或zabbix组件。

4.根据权利要求2所述的基于Galera的数据库集群恢复方法，其特征在于，在重启各数据库节点之后还包括：获取并保存数据库节点的IP列表，所述IP列表保存至数据库集群的hosts文件中。

5.根据权利要求4所述的基于Galera的数据库集群恢复方法，其特征在于，所述方法还包括：

使用Systemd服务或者SQL查询语句对数据库节点是否处于健康状态进行判断，以提取健康数据库节点；

当存在唯一的健康数据库节点时，以所述健康数据库节点作为启动节点，以作为基于Galera的数据库集群的主节点，以执行Galera同步操作；

当存在两个或者两个以上健康数据库节点时，根据所述hosts文件中任意一个IP列表所对应的数据库节点作为基于Galera的数据库集群的主节点，并以bootstrap模式启动同步操作。

6.根据权利要求5所述的基于Galera的数据库集群恢复方法，其特征在于，设定使用Systemd服务或者SQL查询语句对数据库节点进行健康状态进行判断的循环检测周期，所述循环检测周期为30秒至60秒。

7.根据权利要求1中任一项所述基于Galera的数据库集群恢复方法，其特征在于，所述方法还包括：

统计异常关机的数据库节点的数量，并判断异常关机的数据库节点数量是否小于或者等于1；

若是，以异常关机的数据库节点或者将数据库集群的hosts文件中的第一个数据库节点作为启动节点，并以bootstrap模式启动同步操作；

若否，遍历查找出数据库节点的gvwstate.dat文件中所包含的my_uuid等于view_id的数据库节点，以作为启动节点，并以bootstrap模式启动同步操作。

8.根据权利要求2至7中任一项所述基于Galera的数据库集群恢复方法，其特征在于，所述控制服务组件使用SSHD服务下发控制服务至各数据库节点。

9.一种终端设备，其特征在于，包括：处理器，存储装置，以及在处理器与存储装置之间建立通信连接的通信总线；

所述处理器用于执行存储装置中存储的一个或者多个程序，以实现如权利要求1至8中任一项所述的基于Galera的数据库集群恢复方法。

Images