一种有状态集群恢复方法、装置、设备及可读存储介质与流程

本发明涉及计算机应用技术领域，特别是涉及一种有状态集群恢复方法、装置、设备及可读存储介质。

背景技术：

在云计算、大数据、人工智能等it系统中，有很多关键的服务存储着业务的核心数据，它们的正常运行是系统稳定运行的前提，为了解决单点故障和数据丢失问题，一般使用多个节点冗余备份的方法组成一个集群，统一对外提供服务。这些存在可变数据的服务称为有状态服务。如作为数据库服务的galera技术的mariadb集群、ovn-db的主备集群、mongo主备集群，如作为消息转发服务的rabbitmq-server主备集群。当提供服务的节点异常(如断电、网络异常)之后，其他节点的服务可以继续工作。

多个节点形成有状态集群，每个节点都保存各自的数据，通过集群心跳和同步来保证各个节点的数据一致性。有些集群是多个节点同时提供读写能力，如galera-mariadb、rabbitmq-server；有些集群是分为master+slave角色，只有master节点提供读写能力，slave只能提供读能力。在集群恢复方面，上述每种集群都可以轻松解决单点故障和重加入的问题。但是如果集群多个节点异常(如断电、网络震荡)，甚至全部异常，又或者计划内整体关机(如处于维护的目的关闭集群)后，再将集群恢复正常，就是比较困难的事情。尤其是在要求全部上电自动恢复的场景时，问题更为突出。具体表现在：集群重启时，最后一个挂掉的节点应该第一个重启，以保证数据是最全最完整的。即，当整体集群重启时，就需要一个仲裁模块抉择哪个节点先启动，这往往取决于集群关闭时的顺序，仲裁模块会通过探测的方式抉择出哪个节点是最后关闭的，然后让该节点先启动，以保证数据完整性(因为最后关闭的节点才会有最完整的数据，提前关闭的节点的数据是有可能不完整的)。如图1所示(启动顺序同图示空心箭头的顺序，与关闭时间顺序相反)，常见的如pacemaker通过mariadb的agent启动mariadb集群的方式，就是如此。但是通过额外的pacemaker模块管理集群的启动和运行有如下缺点：

缺点一：pacemaker本身依赖corosync，而后者在网络震荡时稳定性较差，也增加了系统复杂度。

缺点二：pacemaker管理各个业务模块时需要配置agent，且每个agent的实现各不相同，在业务模块版本升级时，可能出现agent不兼容的情况。

缺点三：pacemaker适合业务模块的原生启动模式，但对于容器化后的业务模块，pacemaker无能为力。

缺点四：pacemaker状态机复杂，且agent的实现和业务模块耦合性很高，造成维护困难。

综上所述，如何有效地解决集群重启时，保障数据完整性等问题，是目前本领域技术人员急需解决的技术问题。

技术实现要素：

本发明的目的是提供一种有状态集群恢复方法、装置、设备及可读存储介质，以在集群重启时，保障数据完整性。

为解决上述技术问题，本发明提供如下技术方案：

一种有状态集群恢复方法，包括：

目标节点重启后，获取分布式协调服务记录的身份标识文件；

利用所述身份标识文件确定主节点身份标识，并判断所述主节点身份标识与本机标识是否相同；

如果是，则获取所述分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip；

如果否，则在主节点获取所述分布式锁后，以从节点身份加入所述有状态集群，并加入申请主身份队列。

优选地，所述在本机网卡中设置有状态集群对外提供访问服务的vip，包括：

将本机的主从服务状态设置为主状态，并在所述本机网卡中添加所述vip。

优选地，在所述以从节点身份加入所述有状态集群，并加入申请主身份队列之后，还包括：

循环监听所述分布式协调服务的分布式锁，以及所述主从服务的状态变更消息。

优选地，在所述循环监听所述分布式协调服务的分布式锁，以及所述主从服务的状态变更消息之后，还包括：

获取所述分布式锁，执行所述获取所述分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip的步骤；

将所述本机标识作为所述主节点身份标识写入所述身份标识文件。

优选地，所述获取所述分布式锁，包括：

以竞争方式，获取所述分布式锁。

优选地，所述目标节点重启后，获取分布式协调服务记录的身份标识文件，包括：

所述目标节点重启后，判断所述本机网卡中是否存在所述vip；

如果存在，则将所述vip从所述本机网卡中删除，并初始化本机状态为初始化状态，并设置到所述身份标识文件中；

通过所述分布式协调服务的接口，获取所述身份标识文件。

优选地，所述分布式协调服务持续维护所述身份标识文件，当主身份发生变化时更新所述身份标识文件；其中，所述身份标识文件中保存了所述目标节点的当前状态，所述当前状态为初始化状态、主准备状态、主状态、主等待状态、从准备状态和从状态中的任意一种。

一种有状态集群恢复装置，包括：

身份标识文件获取模块，用于目标节点重启后，获取分布式协调服务记录的身份标识文件；

标识判断模块，用于利用所述身份标识文件确定主节点身份标识，并判断所述主节点身份标识与本机标识是否相同；

主身份确定模块，用于如果是，则获取所述分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip；

从身份确定模块，用于如果否，则在主节点获取所述分布式锁后，以从节点身份加入所述有状态集群，并加入申请主身份队列。

一种有状态集群恢复设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现上述有状态集群恢复方法的步骤。

一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述有状态集群恢复方法的步骤。

应用本发明实施例所提供的方法，目标节点重启后，获取分布式协调服务记录的身份标识文件；利用身份标识文件确定主节点身份标识，并判断主节点身份标识与本机标识是否相同；如果是，则获取分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip；如果否，则在主节点获取分布式锁后，以从节点身份加入有状态集群，并加入申请主身份队列。

无论是仅有目标节点单点重启，还是整个集群均重启的情况下，目标节点在重启后，首先获得取身份标识文件，而后利用身份标识文件确定主节点身份。判断主节点身份标识是否与本机标识相同，若相同，则表明目标节点在重启前为主节点，则获取分布式锁，并在本机网卡中设置有状态集群对外提供访问访问的vip。其中，以分布式锁的方式锁定主节点，可在主节点故障时，其他节点通过竞争分布式锁的方式竞争主身份；若不同，则表明目标节点在重启前为从节点，则可在主节点获取到分布式锁后，以从节点身份加入有状态集群，并加入申请主身份的队列中。由于有状态集群对外提供服务的vip在重启后仍然布置在主节点上，因而即使是整个集群重启时，也无需要求重启顺序，可直接按照重启前各个节点在有状态服务中的主从身份重新加入集群即可。另外，若在业务运行过程中，主节点异常，可由申请主身份队列中其他节点通过竞争分布式锁的方式获得主节点身份。如此，便可在有状态集群运行时、集群重启时、或单节点重启时，保障有状态集群数据完整性。相较于通过额外的pacemaker模块管理集群的启动和运行，本发明实施例所提供的方法，架构简单，容易实现。

另外，本发明实施例中将有状态集群对外提供服务的vip设置在主节点上，服务与客户端之间可直接建立tcp连接，可绕开slb，实现更好的可维护性和高效通信。

相应地，本发明实施例还提供了与上述有状态集群恢复方法相对应的有状态集群恢复装置、设备和可读存储介质，具有上述技术效果，在此不再赘述。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有的一种有状态集群恢复方法的重启示意图；

图2为本发明实施例中一种有状态集群恢复方法的实施流程图；

图3为本发明实施例中有状态集群重启前的运行示意图；

图4为本发明实施例中有状态集群重启时的重启示意图；

图5为本发明实施例中选主模块的启动示意图；

图6为本发明实施例中当主节点故障时，从节点上的选主模块的运行示意图；

图7为本发明实施例中一种主节点重启的示意图；

图8为本发明实施例中一种从节点重启的示意图；

图9为本发明实施例中一种节点ip规划示意图；

图10为本发明实施例中一种有状态集群恢复装置的结构示意图；

图11为本发明实施例中一种有状态集群恢复设备的结构示意图；

图12为本发明实施例中一种有状态集群恢复设备的结构示意图。

具体实施方式

本发明的核心是提供一种有状态集群恢复方法，

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一：

请参考图2，图2为本发明实施例中一种有状态集群恢复方法的流程图，该方法可应用于有状态集群中的每一个节点，该方法包括以下步骤：

s101、目标节点重启后，获取分布式协调服务记录的身份标识文件。

需要说明的是，在本发明实施例中的目标节点可为有状态集群中的任意一个目标节点。目标节点重启的原因可为掉电重启、故障重启或其他有计划的重启，另外，目标节点重启可为单点重启，也可为整个有状态集群整体重启时的各个节点。即，当有状态集群重启时，每一个节点都可视为目标节点，并执行本发明实施例所提供的恢复方法。其中，有状态集群具体可为mariadb+galera，rabbitmq-server，ovn-db，mongodb。另外，本发明实施例所提供的有状态集群恢复方法还可适用于有状态集群软件的重启恢复中，具体的有状态集群软件恢复方式参见本文描述的有状态集群恢复方法。

目标节点重启后，首先获取分布协调服务记录的身份标识文件。具体的，分布式协调服务可为etcd、consul、zookeeper等常见的分布式协调服务，在此不在一一赘述。

其中，分布式协调服务持续维护身份标识文件，当主身份发生变化时更新身份标识文件；其中，身份标识文件中保存了目标节点的当前状态，当前状态为初始化状态、主准备状态、主状态、主等待状态、从准备状态和从状态中的任意一种。其中，可用init表示初始化状态，master表示主状态，to_master表示主准备状态，wait_master表示主等待状态，to_slave表示从准备状态(或称之备准备状态)，slave表示从状态(或称之为备状态)。当目标节点的状态发生改变时，可将自身的当前状态写入身份标识文件中。具体的，该身份标识文件可具体为/var/run/leader文件。

s102、利用身份标识文件确定主节点身份标识，并判断主节点身份标识与本机标识是否相同。

可从是否标识文件中读取主状态对应的节点id，判断该节点id与本机id相同。如果相同，则表明主节点身份标识与本即标识相同。当然，若目标节点此次重启是与整个集群一起重启，还可从标识文件中读取本机标识的当前状态(这里的当前状态特指重启前分布式协调服务最后保存的目标节点的当前状态)，若当前状态为主状态，也可视为主节身份标识是否标识与本机标识相同，若当前状态不是主状态，则视为主身份标识与本机标识不同。如此，便可通过判断结果，确定有状态集群重启前，目标节点在重启前是否为主节点，或确定目标节点在掉线之后，是否存在新的主节点。

如果判断结果为是，即表明目标节点仍为主节点；若判断结果为否，即表明目标节点为从节点。根据不同的判断结果，以不同的身份加入有状态集群，即如果是，则执行步骤s103的操作；如果否，则执行步骤s104的操作。

s103、获取分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip。

在本发明实施例中采用分布式锁的方式锁定主节点身份，即当确定目标节点为主节点时，则可获取分布式协调服务的分布式锁。而后，可在本机网卡中设置有状态集群对外提供访问访问的vip(virtualipaddress，虚拟ip地址)即虚拟的ip地址。vip与代理服务器的真实ip地址不同，是由代理服务器根据internet内部客户机的多少，给定虚拟ip地址的一个范围，并按某种规定分配给每个客户机一个虚拟ip地址，这样便可实现客户机与internet的间接相连。vip主要是用来进行不同主机之间的切换，主要用在服务器的主从切换。具体的，利用vip进行访问的具体实现过程，可参照目前常见的slb服务中的vip，即客户端访问有状态集群所提供的访问服务时，通过该vip进行访问。将vip部署在主节点上，即将服务或业务处理全部落到主节点上，取消slb。需要说明的是，在本发明实施例中部署在有状态集群中的业务或服务均指能通过systemd或者docker的方式实现异常退出后可自动启动的业务或服务。将分布式锁与主节点进行锁定，可在主节点出现故障时，其他节点通过竞争锁的方式，获得主节点身份。

具体的，在添加vip时，还可将本机的主从服务状态设置为主状态。即，在本机网卡中添加vip，可将本节点内的主从服务状态设置为主状态，以便通过vip对外通过访问服务，以及对其他从节点上的服务进行管理。其中，主从服状态为具有主状态和从状态两种可选状态的服务状态，如具有主状态和从状态的ovn-db服务，在某一个节点上的服务状态(在部署在主节点上为主状态，部署在从节点上则为从状态)。

s104、在主节点获取分布式锁后，以从节点身份加入有状态集群，并加入申请主身份队列。

在主节点获取到分布式锁之后，目标节点可以从节点是否加入有状态集群，与此同时，目标节点还可以加入申请主身份队列中。以在主节点出现故障后，获得主节点身份，保障有状态集群的服务稳定性。

应用本发明实施例所提供的方法，目标节点重启后，获取分布式协调服务记录的身份标识文件；利用身份标识文件确定主节点身份标识，并判断主节点身份标识与本机标识是否相同；如果是，则获取分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip；如果否，则在主节点获取分布式锁后，以从节点身份加入有状态集群，并加入申请主身份队列。

无论是仅有目标节点单点重启，还是整个集群均重启的情况下，目标节点在重启后，首先获得取身份标识文件，而后利用身份标识文件确定主节点身份。判断主节点身份标识是否与本机标识相同，若相同，则表明目标节点在重启前为主节点，则获取分布式锁，并在本机网卡中设置有状态集群对外提供访问访问的vip。其中，以分布式锁的方式锁定主节点，可在主节点故障时，其他节点通过竞争分布式锁的方式竞争主身份；若不同，则表明目标节点在重启前为从节点，则可在主节点获取到分布式锁后，以从节点身份加入有状态集群，并加入申请主身份的队列中。由于有状态集群对外提供服务的vip在重启后仍然布置在主节点上，因而即使是整个集群重启时，也无需要求重启顺序，可直接按照重启前各个节点在有状态服务中的主从身份重新加入集群即可。另外，若在业务运行过程中，主节点异常，可由申请主身份队列中其他节点通过竞争分布式锁的方式获得主节点身份。如此，便可在有状态集群运行时、集群重启时、或单节点重启时，保障有状态集群数据完整性。相较于通过额外的pacemaker模块管理集群的启动和运行，本发明实施例所提供的方法，架构简单，容易实现。

另外，本发明实施例中将有状态集群对外提供服务的vip设置在主节点上，服务与客户端之间可直接建立tcp连接，可绕开slb，实现更好的可维护性和高效通信。

需要说明的是，基于上述实施例，本发明实施例还提供了相应的改进方案。在优选/改进实施例中涉及与上述实施例中相同步骤或相应步骤之间可相互参考，相应的有益效果也可相互参照，在本文的优选/改进实施例中不再一一赘还。

优选地，考虑到集群在运行过程中，可能会出现主节点故障等问题，为避免因集群缺失主节点，因此本发明实施例还提供了如下解决方案：

在执行步骤s104之后，即在以从节点身份加入有状态集群，并加入申请主身份队列之后，还可执行以下步骤：

步骤一、循环监听分布式协调服务的分布式锁，以及主从服务的状态变更消息；

步骤二、获取分布式锁，执行获取分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip的步骤；

步骤三、将本机标识作为主节点身份标识写入身份标识文件。

为便于描述，下面将上述三个步骤结合起来进行详细说明。

循环监听分布式协调服务的分布式锁，便可实时得知集群内的运行状态，如主节点是否正常等情况。获得主从服务状态变更消息，可及时调整本机的主从服务的状态，以便更好的对外提供访问服务。当主节点故障时，可以竞争方式，获取分布式锁。具体可以是：

方式一：zookeeper实现分布式锁

实现方式包括利用节点名称的唯一性来实现共享锁和利用临时顺序节点实现共享锁。其中，利用节点名称的唯一性来实现共享锁的算法思路：利用名称唯一性，加锁操作时，只需要所有节点一起创建/test/lock节点，只有一个创建成功，成功者获得锁。解锁时，只需删除/test/lock节点，其余节点再次进入竞争创建节点，直到所有节点都获得锁。利用临时顺序节点实现共享锁的算法思路：对于加锁操作，可以让所有节点都去/lock目录下创建临时顺序节点，如果创建的节点发现自身创建节点序列号是/lock/目录下最小的节点，则获得锁。否则，监视比自己创建节点的序列号小的节点(比自己创建的节点小的最大节点)，进入等待。

方式二：redis实现分布式锁

redis实现分布式锁主要靠四个命令：setnx(setifnotexits维护着是乐观锁)：当不存在key的时候，才为key设置值为value。setnx与set的区别：set是存在key，则去覆盖value；setnx是不存在key，则重新给key和value赋值；getset：根据key得到旧的值，并set新的值；expire：设置过期时间；del：删除。具体实现方式在获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的uuid，通过此在释放锁的时候进行判断。另外，在获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。在释放锁的时候，通过uuid判断是不是该锁，若是该锁，则执行delete进行锁释放。

方式三：数据库实现分布式锁

实现方式：利用的是乐观锁和悲观锁，其中，乐观锁：在表中添加版本号的字段，每次更新前都先查询出带版本号的数据，然后再更新的时候where条件语句后带版本号条件，更新成功表示锁已占用，更新不成功表示锁没被占用。悲观锁：利用select...forupdate(x锁)/select...lockinsharemode(s锁)，一般来说用x锁的较多，因为后续多会做写功能的实现。

当获取到分布式锁时，可执行获取分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip的步骤，即上文中的步骤s103的操作。然后，将本机标识作为主节点身份标识写入身份标识文件中，以保障身份标识文件总是记录最新的状态信息。

优选地，考虑到目标节点在重启之前可能为主节点，但由于故障时间过长等原因，在目标节点重新启动时，已有新的主节点在正常工作，因此，在目标节点重新启动时，在获取分布式协调服务记录的身份标识文件，具体包括：

步骤一、目标节点重启后，判断本机网卡中是否存在vip；

步骤二、如果存在，则将vip从本机网卡中删除，并初始化本机状态为初始化状态，并设置到身份标识文件中；

步骤三、通过分布式协调服务的接口，获取身份标识文件。

为了便于描述，下面将上述三个步骤结合起来进行说明。

为了避免同一个有状态集群中出现两个vip，破坏集群的数据一致性，因此在目标节点重启后，可先判断本机网卡中是否存在vip，如果存在，则将该vip从本机网卡中删除，并初始化本机状态为init状态，并设置到身份标识文件中。然后，通过分布式协调服务的接口，获取身份标识文件。

实施例二：

为了便于本领域技术人员更好的理解本发明实施例所提供的技术方案，下面以分布式协调服务具体为etcd为例，对本发明实施例所提供的技术方案进行详细说明。

需要说明的是，本实施例的前提是取消slb的负载均衡功能，而将业务处理全部落到主节点上，这对系统整体规模和业务压力也有一定的要求，只适合中小型规模的业务架构。各个业务都能通过systemd或者docker的方式实现异常退出后自动启动。集群重启时必须要求之前的主节点能正常启动，如集群含有节点1，2，3，其中1为主节点，集群整体重启后，节点1必须在位，其他2和3可以不在位。

基于上述实施例一所提供的有状态集群恢复方法，设计一个选主模块，即该选主模块可实现上述实施例一所提供的有状态集群恢复方法。

请参考图3、图4、图5和图6，图3为本发明实施例中有状态集群重启前的运行示意图，图4为本发明实施例中有状态集群重启时的重启示意图，图5为本发明实施例中选主模块的启动示意图；图6为本发明实施例中当主节点故障时，从节点上的选主模块的运行示意图。

首先，在有状态集群内的每一个节点上部署选主模块。并对选主模块进行初始化设置，如可在etcd中选择任意一个节点作为主节点，即将集群内的某一个节点作为初始主节点。每一个节点上的选主模块启动之后，均可执行以下步骤：

如果本机网卡上存在vip，则将该vip删除；将本机状态设置为初始化状态，并将该初始化状态设置到var/run/leader中；通过etcd接口查看主节点id，并判断主节点id和本节点id是否相同；具体的，如果相同，则表明本节点为在初始化设置中，被设置为主节点；如果不同，则表示本节点被设置为从节点。

当本节点被设置为主节点时，通过etcd接口获取leader锁，并将本机状态修改为主准备状态，并将状态信息设置到var/run/leader中；然后等待5秒，通知本节点的备服务更改为主状态，如ovn-db，对于多主的的服务则无需更改，如galera+mariadb；将本机节点id写入到etcd的主节点身份中，将本机状态修改为主状态，并将主状态信息设置到var/run/leader中；将vip添加到网卡，并循环监听etcd的leader锁以及处理身份变更，如将主身份变更为从身份。

当本节点被设置为主节点时，将本机状态修改为主等待状态，并将该主等待状态设置到var/run/leader中；通过etcd循环查询leader锁是否已被获取，若还未被获取，则表明主节点还未启动，等待1秒后，继续查询，直到主节点启动。当监测到主节点启动之后，通知本节点的主服务修改为备状态，对于多主的服务以及已经为备状态的备服务则无效修改。然后，将本机状态修改为从状态，并将从状态设置到var/run/leader中。相应地，同主节点一样，从节点，也可循环监听etcd的leader锁以及处理身份变更，如将主身份变更为从身份。

从节点循环监听etcd的leader锁，当主节点故障发生故障时，从节点可以竞争的方式，争夺etcd中的leader锁，当获得leader锁之后，可静候5秒。然后，将当前状态修改为主准备状态，并设置到var/run/leader中。然后，通知本节点的备服务更改为主状态，对于多主的的服务则无需更改；将本机节点id写入到etcd的主节点身份中，将本机状态修改为主状态，并将主状态信息设置到var/run/leader中；将vip添加到网卡，并循环监听etcd的leader锁以及处理身份变更，如将主身份变更为从身份。

其中，图5和图6中的静默5秒，以及循环查询时的等待1秒均可替换为其他时长，但静默时间要为查询等待时间的二倍。在集群的所有节点运行“选主模块”(即图3所示的选主服务)，此模块通过etcd的分布式锁竞争主身份，并将身份信息设置到/var/run/leader文件中(状态信息包括：master、to_slave、slave、to_master)，并持续维护此文件，当主身份发生变化时更新此文件的值，即改变状态。

选主模块可保证该模块退出前的身份和重启后的身份保持一致，即主节点的选主模块退出重启后仍然能获得主身份，非主节点的选主模块退出重启后，只能获得非主身份。

选主模块在更改主身份时同时实现vip的切换，保持vip所在节点和主节点绑定关系。

在节点重启时，由于/var/run/leader是内存文件，文件并不存在，各个集群业务(如mariadb，rabbitmq-server)要等待此文件初始化再操作。选主模块启动时，会根据上述步骤设置/var/run/leader值。当此值为slave或者master之一时，各个集群业务根据此值来选择不同的启动方式。

请参考图7，图7为本发明实施例中一种主节点重启的示意图，主节点启动mariadb和rabbimq-server的启动举例，请参考图8，图8为本发明实施例中一种从节点重启的示意图。

为了便于说明，下面以初始化、主故障、集群断电重启两个场景举例说明实现mariadb和rabbitmq-server集群重启的步骤：

节点ip规划如图9所示，图9为本发明实施例中一种节点ip规划示意图。需要说明的是图9所示的规划示意图中的ip还可为其他具体的ip地址，并不以图9为限定。启动脚本如下：

选主模块，mariadb，rabbitmq-server的启动脚本为：leader_start.sh，mariadb_start.sh，rabbit_start.sh，三个服务都是通过systemd管理，异常后自动被重新拉起，三个节点的mariadb组成galera+mariadb集群，三个节点的rabbitmq-server组成rabbitmq集群。

一、部署时初始化：

1)部署时设置etcd的kv值：“master-id”：”hostl”

2)三个节点同时启动，并且每个节点的三个服务也同时启动。

3)节点1，2，3的/var/run/leader不存在。

4)mariadb_start.sh和rabbit_start.sh保持等待此文件的状态：

5)节点1的leader.sh查询到etcd的“master-id”值和本机相同，则获取”leader”锁，称为主节点，写master到/var/run/leader中，并将10.0.0.254添加到10.0.0.11的网卡上。

6)节点1的mariadb.sh和rabbit.sh检测到/var/run/leader为master之后，按照主身份启动各自业务进程分别为：

mariadb.sh：

sed-ie′/^safe_to_bootstrap/s/0/1/′/var/lib/mysql/grastate.dat

mysqld_safe--wsrep-new-cluster

rabbit.sh：

rabbitmqctlforce_boot

/usr/sbin/rabbitmq-server

7)节点2，3的leader_py.sh写slave到/var/run/leader

8)节点2，3的mariadb.sh和rabbit.sh检测到/var/run/leader为slave之后，按照备身份启动各自业务进程分别为：

mariadb.sh：

sed-ie′/^safe_to_bootstrap/s/1/0/′/var/lib/mysql/grastate.dat

mysqld_safe

rabbit.sh：

/usr/sbin/rabbitmq-server

9)此时mariadb集群和rabbitmq集群已经建立好，客户端可以通过10.0.0.254访问mariadb服务和rabbitmq-server服务

二、节点1异常断电：

1)节点2竞争到leader锁资源，变成主身份，节点3维持从节点(或称备节点)身份。

2)节点2的leader.sh将/var/run/leader值更改为”master”

3)节点2的leader.sh更改etcd的kv值：“master-id”：”host2”

4)节点2的leader.sh将10.0.0.254添加到10.0.0.12的网卡上。

5)mariadb集群和rabbitmq集群已经建立好，并且支持多主读写，无需改变什么。客户端可以通过10.0.0.254访问mariadb服务和rabbitmq-server服务。

三、三个节点整体断电重启：

1)etcd的kv值为：“master-id”：”host2”

后面的操作与“部署时初始化”相同，由于hsot2在重启前为主节点，因而在重启时host2获得主身份，其他节点获得备身份。

如此，便可通过vip直接访问集群中单个节点上的业务。集群中的节点通过分布式协调组件的竞争到主身份后，将此节点信息写入共享存储中，后续集群重启时，仍由上次主节点获得主身份。业务运行过程中，主节点异常，会有其他节点获得主节点身份，并将新的节点id更新到共享存储中。各集群业务在整体恢复时，不再是尝试恢复关闭前的集群状态，而是强制的由主节点来boostrap集群，从节点以成员的身份加入集群，这就避免了重启时对启动顺序的要求。

实施例三：

相应于上面的方法实施例，本发明实施例还提供了一种有状态集群恢复装置，下文描述的有状态集群恢复装置与上文描述的有状态集群恢复方法可相互对应参照。

参见图10所示，该装置包括以下模块：

身份标识文件获取模块101，用于目标节点重启后，获取分布式协调服务记录的身份标识文件；

标识判断模块102，用于利用身份标识文件确定主节点身份标识，并判断主节点身份标识与本机标识是否相同；

主身份确定模块103，用于如果是，则获取分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip；

从身份确定模块104，用于如果否，则在主节点获取分布式锁后，以从节点身份加入有状态集群，并加入申请主身份队列。

应用本发明实施例所提供的装置，目标节点重启后，获取分布式协调服务记录的身份标识文件；利用身份标识文件确定主节点身份标识，并判断主节点身份标识与本机标识是否相同；如果是，则获取分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip；如果否，则在主节点获取分布式锁后，以从节点身份加入有状态集群，并加入申请主身份队列。

无论是仅有目标节点单点重启，还是整个集群均重启的情况下，目标节点在重启后，首先获得取身份标识文件，而后利用身份标识文件确定主节点身份。判断主节点身份标识是否与本机标识相同，若相同，则表明目标节点在重启前为主节点，则获取分布式锁，并在本机网卡中设置有状态集群对外提供访问访问的vip。其中，以分布式锁的方式锁定主节点，可在主节点故障时，其他节点通过竞争分布式锁的方式竞争主身份；若不同，则表明目标节点在重启前为从节点，则可在主节点获取到分布式锁后，以从节点身份加入有状态集群，并加入申请主身份的队列中。由于有状态集群对外提供服务的vip在重启后仍然布置在主节点上，因而即使是整个集群重启时，也无需要求重启顺序，可直接按照重启前各个节点在有状态服务中的主从身份重新加入集群即可。另外，若在业务运行过程中，主节点异常，可由申请主身份队列中其他节点通过竞争分布式锁的方式获得主节点身份。如此，便可在有状态集群运行时、集群重启时、或单节点重启时，保障有状态集群数据完整性。相较于通过额外的pacemaker模块管理集群的启动和运行，本发明实施例所提供的装置，架构简单，容易实现。

另外，本发明实施例中将有状态集群对外提供服务的vip设置在主节点上，服务与客户端之间可直接建立tcp连接，可绕开slb，实现更好的可维护性和高效通信。

在本发明的一种具体实施方式中，主身份确定模块103，具体用于将本机的主从服务状态设置为主状态，并在本机网卡中添加vip。

在本发明的一种具体实施方式中，还包括：

循环监听模块，用于在以从节点身份加入有状态集群，并加入申请主身份队列之后，循环监听分布式协调服务的分布式锁，以及主从服务的状态变更消息。

在本发明的一种具体实施方式中，还包括：

主身份竞争模块，用于在循环监听分布式协调服务的分布式锁，以及主从服务的状态变更消息之后，获取分布式锁，执行获取分布式协调服务的分布式锁，并在本机网卡中设置有状态集群对外提供访问服务的vip的步骤；将本机标识作为主节点身份标识写入身份标识文件。

在本发明的一种具体实施方式中，主身份竞争模块，具体用于以竞争方式，获取分布式锁。

在本发明的一种具体实施方式中，身份标识文件获取模块101，具体用于目标节点重启后，判断本机网卡中是否存在vip；如果存在，则将vip从本机网卡中删除，并初始化本机状态为初始化状态，并设置到身份标识文件中；通过分布式协调服务的接口，获取身份标识文件。

在本发明的一种具体实施方式中，分布式协调服务持续维护身份标识文件，当主身份发生变化时更新身份标识文件；其中，身份标识文件中保存了目标节点的当前状态，当前状态为初始化状态、主准备状态、主状态、主等待状态、从准备状态和从状态中的任意一种。

实施例四：

相应于上面的方法实施例，本发明实施例还提供了一种有状态集群恢复设备，下文描述的一种有状态集群恢复设备与上文描述的一种有状态集群恢复方法可相互对应参照。

参见图11所示，该有状态集群恢复设备包括：

存储器d1，用于存储计算机程序；

处理器d2，用于执行计算机程序时实现上述方法实施例的有状态集群恢复方法的步骤。

具体的，请参考图12，为本实施例提供的一种有状态集群恢复设备的具体结构示意图，该有状态集群恢复设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，cpu)322(例如，一个或一个以上处理器)和存储器332，一个或一个以上存储应用程序342或数据344的存储介质330(例如一个或一个以上海量存储设备)。其中，存储器332和存储介质330可以是短暂存储或持久存储。存储在存储介质330的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对数据处理设备中的一系列指令操作。更进一步地，中央处理器322可以设置为与存储介质330通信，在有状态集群恢复设备301上执行存储介质330中的一系列指令操作。

有状态集群恢复设备301还可以包括一个或一个以上电源326，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口358，和/或，一个或一个以上操作系统341。例如，windowsservertm，macosxtm，unixtm，linuxtm，freebsdtm等。

上文所描述的有状态集群恢复方法中的步骤可以由有状态集群恢复设备的结构实现。

实施例五：

相应于上面的方法实施例，本发明实施例还提供了一种可读存储介质，下文描述的一种可读存储介质与上文描述的一种有状态集群恢复方法可相互对应参照。

一种可读存储介质，可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例的有状态集群恢复方法的步骤。

该可读存储介质具体可以为u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可存储程序代码的可读存储介质。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。