CN115794769A - 高可用数据库管理的方法、电子设备及存储介质 - Google Patents

Abstract

本申请提出的高可用数据库管理的方法、电子设备及存储介质，涉及互联网技术领域。包括：通过Orchestrator节点对MySQL集群的健康状态进行监控，得到目标监控结果；若目标监控结果为第一监控结果，则将Consul集群中的主MySQL实例的节点状态修改为非MySQL集群成员；通过Orchestrator节点对至少一个从MySQL实例进行筛选，得到选定MySQL实例；将Consul集群中的选定MySQL实例的节点角色修改为主角色；将节点状态为MySQL集群成员且节点角色为主角色的MySQL实例作为新的主MySQL实例，并将访问请求发送至新的主MySQL实例。本申请实施例提高了数据库的可用率。

Description

高可用数据库管理的方法、电子设备及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种高可用数据库管理的方法、电子设备及存储介质。

背景技术

目前，在信息时代，几乎任何一个信息系统都需要数据库系统的支撑。数据库承担了信息的存储、处理工作。如果数据库不可用，很可能导致整个业务系统不可用。数据库系统经常会由于气候因素、网络故障、硬件故障、操作系统故障等意外中断甚至出现数据丢失，给企业带来巨大的经济损失。因此，如何提供一种高可用数据库管理的方法，提高数据库的可用率，成为了亟待解决的技术问题。

发明内容

本申请实施例的主要目的在于提出一种高可用数据库管理的方法、电子设备及存储介质，能够提高数据库的可用率。

为实现上述目的，本申请实施例的第一方面提出了一种高可用数据库管理的方法，应用于至少两个机房，一个所述机房对应一个MySQL实例，所述MySQL实例构成MySQL集群，所述MySQL集群中有一个主MySQL实例，所述MySQL集群中有至少一个从MySQL实例，一个所述机房对应一个Orchestrator节点，所述Orchestrator节点构成Orchestrator集群，一个所述机房对应一个Consul节点，所述Consul节点构成Consul集群，所述Consul集群存储有所述MySQL实例的第一注册信息，所述第一注册信息包括节点状态和节点角色，节点状态包括非MySQL集群成员和MySQL集群成员，节点角色包括主角色；

所述方法包括：

通过所述Orchestrator节点对所述MySQL集群的健康状态进行监控，得到目标监控结果；所述目标监控结果包括第一监控结果，所述第一监控结果用于表征当前的所述主MySQL实例已故障；

若所述目标监控结果为所述第一监控结果，则将所述Consul集群中的所述主MySQL实例的所述节点状态修改为非MySQL集群成员；

通过所述Orchestrator节点对至少一个所述从MySQL实例进行筛选，得到选定MySQL实例；

将所述Consul集群中的所述选定MySQL实例的所述节点角色修改为主角色；

若接收到访问请求，读取在所述Consul集群中的所述第一注册信息，以得到每一所述MySQL实例的节点状态和每一所述MySQL实例的节点角色；

根据所述节点状态和所述节点角色对所述MySQL实例进行筛选，将所述节点状态为MySQL集群成员且所述节点角色为所述主角色的所述MySQL实例作为新的所述主MySQL实例，并将所述访问请求发送至新的所述主MySQL实例。

在一些实施例，每一所述机房包括至少两台机器，至少两台所述机器中有一台主机器，所述主机器绑定了虚拟网络地址，一个所述机房对应一个HAProxy集群，所述HAProxy集群包括至少两个HAProxy进程，一个所述机器对应一个HAProxy进程，所述若接收到访问请求，读取在所述Consul集群中的所述第一注册信息，包括：

通过所述虚拟网络地址将访问请求发送给所述主机器的所述HAProxy进程；

若通过所述HAProxy进程接收到所述访问请求，通过所述HAProxy进程读取在所述Consul集群中的所述第一注册信息。

在一些实施例，一个所述机房对应一个Keepalived集群，所述Keepalived集群包括至少两个Keepalived节点，一个所述机器对应一个所述Keepalived节点，在所述通过所述虚拟网络地址将访问请求发送给所述主机器的所述HAProxy进程之前，所述方法还包括：

通过Keepalived集群对所述主机器进行健康状态检测，得到机器状态检测结果；

若所述机器状态检测结果为非健康状态，则将所述虚拟网络地址绑定在至少两台所述机器中的另一个，得到新的所述主机器。

在一些实施例，所述通过Keepalived集群对所述主机器进行健康状态检测，得到机器状态检测结果，包括：

通过至少两台所述机器之间的Keepalived节点互发心跳信息；若未接收到来自所述主机器的所述心跳信息，且超过预设的等待时长阈值，则所述机器状态检测结果为非健康状态；

或者，

对于所述主机器，通过所述Keepalived节点对所述HAProxy进程进行健康监控，得到监控结果；若监控结果为进程监控失败，则所述机器状态检测结果为所述非健康状态。

在一些实施例，所述若所述目标监控结果为所述第一监控结果，则将所述Consul集群中的所述主MySQL实例的所述节点状态修改为非MySQL集群成员，包括：

若所述目标监控结果为所述第一监控结果，对每一所述从MySQL实例进行日志读取，得到每一所述从MySQL实例的日志数量；

对所述日志数量最多的所述从MySQL实例进行数据检查，得到数据检查结果；所述数据检查结果包括第一应用结果，所述第一应用结果用于表征日志已被应用；

若所述数据检查结果为所述第一应用结果，则将所述Consul集群中的所述主MySQL实例的所述节点状态修改为非MySQL集群成员。

在一些实施例，所述通过所述Orchestrator节点对至少一个所述从MySQL实例进行筛选，得到选定MySQL实例，包括：

通过所述Orchestrator节点对每一所述从MySQL实例进行日志读取，得到每一所述MySQL实例的日志数量；

根据所述日志数量从至少一个所述从MySQL实例筛选得到所述选定MySQL实例。

在一些实施例，所述通过所述Orchestrator节点对至少一个所述从MySQL实例进行筛选，得到选定MySQL实例，包括：

通过所述Orchestrator节点对每一所述从MySQL实例进行日志读取，得到每一所述MySQL实例的最新接收日志时间；

根据所述最新接收日志时间从至少一个所述从MySQL实例筛选得到所述选定MySQL实例。

在一些实施例，在所述通过所述HAProxy进程读取在所述Consul集群中的所述第一注册信息之后，所述方法还包括：

若所述主MySQL实例的节点状态为所述非MySQL集群成员，断开所述HAProxy进程与所述主MySQL实例的连接。

为实现上述目的，本申请实施例的第二方面提出了一种电子设备，所述电子设备包括存储器、处理器、所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的方法。

为实现上述目的，本申请实施例的第三方面提出了一种存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的方法。

本申请提出的高可用数据库管理的方法、电子设备及存储介质，通过跨机房部署MySQL集群、跨机房部署Orchestrator集群和跨机房部署Consul集群，实现对MySQL集群的健康监控和故障转移，能在主数据库出现故障时，能够及时发现故障和及时更换主数据库，提高了数据库的可用率。

附图说明

图1是本申请实施例提供的机房部署架构示意图；

图2是本申请一个实施例提供的MySQL集群主从切换的应用示意流程图

图3是本申请一个实施例提供的高可用数据库管理的方法的流程图；

图4是本申请一个实施例提供的写请求转发的应用示意流程图；

图5是本申请一个实施例提供的读请求转发的应用示意流程图；

图6是图1中的步骤S102的流程图；

图7是图1中的步骤S105的流程图；

图8是本申请另一个实施例提供的高可用数据库管理的方法的流程图；

图9是本申请一个实施例提供的电子设备的硬件结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

在信息时代，几乎任何一个信息系统都需要数据库系统的支撑。数据库承担了信息的存储、处理工作。如果数据库不可用，很可能导致整个业务系统不可用。所以，成熟的数据库一般会有一种甚至多种高可用方案来避免单点故障，如果某个节点不可用，其他节点可以接管该节点的工作，保证服务的可用性。

例如，数据库系统经常会由于气候因素、网络故障、硬件故障、操作系统故障等意外中断甚至出现数据丢失，给企业带来巨大的经济损失。因此，如何提供一种高可用数据库管理的方法，提高数据库的可用率，成为了亟待解决的技术问题。

基于此，本申请实施例提供高可用数据库管理的方法、电子设备及存储介质，旨在通过跨机房部署MySQL集群、跨机房部署Orchestrator集群和跨机房部署Consul集群，实现对MySQL集群的健康监控和故障转移，能在主MySQL实例(主数据库)出现故障时，能够及时发现故障和及时更换主数据库，提高了数据库的可用率。

参照图1，图1是本申请实施例提供的机房部署架构示意图。图1中的H表示HAProxy进程、K表示Keepalived节点、C表示Consul节点、O表示Orchestrator节点。HAProxy进程、Consul节点和Orchestrator节点分别与MySQL集群通信连接。一个机房内的所有Keepalived节点之间通信连接。一个机房内的Keepalived节点和HAProxy进程通信连接。

跨机房部署MySQL集群是指：存在至少两个机房，且一个机房对应一个MySQL实例，所有的MySQL实例构成MySQL集群。例如，参照图1，在2个地理位置相隔超过1000KM以上城市的3个机房(城市A有2个机房，城市B有1个机房)部署3个MySQL实例并组成MySQL集群。其中，每个机房部署一个MySQL实例。本申请实施例的MySQL实例用于表示数据库，例如主MySQL实例表示主数据库，从MySQL实例表示从数据库。

跨机房部署Orchestrator集群是指：存在至少两个机房，且一个机房对应一个Orchestrator节点，所有的Orchestrator节点构成Orchestrator集群。另外，Orchestrator集群还存储有主MySQL实例的第二注册信息，第二注册信息包括主节点IP和主节点端口。

跨机房部署Consul集群是指：存在至少两个机房，且一个机房对应一个Consul节点，所有的Consul节点构成Consul集群。Consul集群存储有全部的MySQL实例的第一注册信息，第一注册信息包括节点IP、节点端口、节点状态和节点角色。

跨机房部署Keepalived集群是指：存在两个机房，一个机房对应一个Keepalived集群。一个机房包括至少两台机器，一台机器对应一个Keepalived节点。一个机房内所有的Keepalived节点构成Keepalived集群。

跨机房部署HAProxy集群是指：存在两个机房，一个机房对应一个HAProxy集群。一个机房包括至少两台机器；一台机器对应一个HAProxy进程，一个机房内的所有的HAProxy进程构成HAProxy集群。

其中，MySQL集群为业务应用程序提供数据库存储服务，Orchestrator集群为MySQL集群在发生故障时提供切换服务，Consul集群为Orchestrator提供第一注册信息(第一注册信息比如MySQL集群的节点角色，MySQL所使用的HAProxy、Keepalive主机信息)。

需要说明的是，在MySQL集群的多个MySQL实例中，有一个主MySQL实例，有多个从MySQL实例。Consul集群存储有全部MySQL实例的第一注册信息，第一注册信息包括节点IP、节点端口、节点状态和节点角色。节点IP和节点端口用于表示MySQL实例对应的数据库。节点状态用于表示MySQL实例是否为MySQL集群的成员，例如节点状态的取值可为以下任意一种：非MySQL集群成员、MySQL集群成员和空。节点角色用于表示MySQL实例在MySQL集群中的角色，节点角色的取值可为以下任意一种：主角色、从角色和空。

在每个机房内，Keepalived集群配置自己机房网段内的虚拟网络地址(VIP)。在一实施例中，一个机房对应一个VIP，则对于每个机房而言，通过VIP访问主机器的HAProxy进程，通过HAProxy进程将访问请求(访问请求包括写请求和读请求)转发到MySQL集群：每个机房的应用服务器通过连接本机房的VIP连接到主机器的HAProxy进程，HAProxy进程将写请求转发到MySQL集群的主MySQL实例(主MySQL实例用于表示主服务器或主数据库)，将读请求通过负载均衡的方式转发到主MySQL实例和从MySQL实例(从MySQL实例用于表示从服务器或从数据库)。对于写请求来说，需要将写请求转发到MySQL集群的主MySQL实例。但是，由于发生故障或其他原因，导致当前的主MySQL实例不可用，降低了数据库的可用率。因此，在本申请实施例中，在将访问请求转发给MySQL集群的主MySQL实例之前，需要进行故障监控和故障转移，提高数据库的可用率。例如，通过Orchestrator节点对MySQL集群的健康状态进行监控，以及通过主机器的HAProxy进程通过读取Consul集群中的第一注册信息来查找新的主MySQL实例。

本申请实施例提供高可用数据库管理的方法、电子设备及存储介质，具体通过如下实施例进行说明，首先描述本申请实施例中的高可用数据库管理的方法。

图3是本申请实施例提供的高可用数据库管理的方法的一个可选的流程图，可以包括但不限于包括步骤S101至步骤S106。

步骤S101，通过Orchestrator节点对MySQL集群的健康状态进行监控，得到目标监控结果；目标监控结果包括第一监控结果，第一监控结果用于表征当前的主MySQL实例已故障；

步骤S102，若目标监控结果为第一监控结果，则将Consul集群中的主MySQL实例的节点状态修改为非MySQL集群成员；

步骤S103，通过Orchestrator节点对至少一个从MySQL实例进行筛选，得到选定MySQL实例；

步骤S104，将Consul集群中的选定MySQL实例的节点角色修改为主角色；

步骤S105，若接收到访问请求，读取在Consul集群中的第一注册信息，以得到每一MySQL实例的节点状态和每一MySQL实例的节点角色；

步骤S106，根据节点状态和节点角色对MySQL实例进行筛选，将节点状态为MySQL集群成员且节点角色为主角色的MySQL实例作为新的主MySQL实例，并将访问请求发送至新的主MySQL实例。

本申请实施例所示意的步骤S101至步骤S106，参阅图2，通过Orchestrator节点对MySQL集群的健康状态进行监控，可以及时发现当前的主MySQL实例发生故障。并在确定发生故障后，将当前的主MySQL实例的节点状态修改为非MySQL集群成员，但此时该主MySQL实例的节点角色还是主角色。由于当前的主MySQL实例已故障，需要重新选取新的主MySQL实例。本申请实施例通过Orchestrator节点对至少一个从MySQL实例进行筛选，得到选定MySQL实例，但该选定MySQL实例此时的节点状态为MySQL集群成员，但节点角色为从角色，不能直接作为新的主MySQL实例。因此，通过Orchestrator节点对选定MySQL实例进行提升，以便让选定MySQL实例成为主MySQL实例，并将选定MySQL实例的节点角色修改为主角色。而后，参阅图4，将节点状态为MySQL集群成员且节点角色为主角色的MySQL实例作为新的主MySQL实例，并将访问请求(该访问请求可为写请求，也可为读请求)发送至新的主MySQL实例。综上所述，本申请实施例通过对MySQL集群进行故障监控，并在确定故障后，及时进行主MySQL实例的切换，提高了数据库的可用率。

需要说明的是，参阅图5，若访问请求为读请求，将该读请求转发至MySQL实例，该MySQL实例可以是从MySQL实例，也可以是主MySQL实例。

在一些实施例的步骤S101中，通过Orchestrator节点对MySQL集群的健康状态进行监控，得到目标监控结果。目标监控结果包括第一监控结果和第二监控结果。第一监控结果用于表征当前的主MySQL实例已故障。第二监控结果用于表征当前的主MySQL实例未故障。

在一示例中，每隔预设时间阈值通过Orchestrator节点连接主MySQL实例；若节点连接主MySQL实例失败，则目标监控结果为第一监控结果；若连接主MySQL实例成功，则目标监控结果为第二监控结果。其中，预设时间阈值可为5秒、6秒、10秒等等，本申请实施例不作具体限定。

在另一示例中，每隔预设时间阈值通过Orchestrator节点连接主MySQL实例；若节点连接主MySQL实例失败，则通过从MySQL实例连接主MySQL实例；若从MySQL实例连接主MySQL实例失败，则目标监控结果为第一监控结果；若连接从MySQL实例连接主MySQL实例成功，则目标监控结果为第二监控结果。

在一些实施例的步骤S102中，若目标监控结果为第一监控结果，说明当前的主MySQL实例已发生故障，处于不可用状态。需要说明的是，若MySQL实例A的节点状态为非MySQL集群成员，则该MySQL实例A将被排除出MySQL集群，从而无法参与MySQL集群之前的请求转发。因此，在将Consul集群中的主MySQL实例的节点状态修改为非MySQL集群成员之后，便可将非MySQL集群成员的MySQL实例排除出实例列表。而后，若接收到访问请求，HAProxy进程将通过读取Consul集群中的实例列表选择MySQL实例，由于非MySQL集群成员的MySQL实例不在该实例列表中，从而避免了读取已经故障的主MySQL实例中的数据。

在一示例中，若目标监控结果为第一监控结果，将Consul集群中的主MySQL实例的节点状态修改为非MySQL集群成员；通过主机器的HAProxy进程读取Consul集群中的第一注册信息，得到每一MySQL实例的节点状态和节点角色；对于每一MySQL实例，若节点状态为非MySQL集群成员、且节点角色为主角色，则断开主机器的HAProxy进程与MySQL实例之间的连接。通过断开连接，从而保证应用不会将数据继续写到老的主MySQL实例。

在另一示例中，若目标监控结果为第一监控结果，将Consul集群中的主MySQL实例的节点状态修改为非MySQL集群成员；通过HAProxy进程读取Consul集群中的第一注册信息，得到每一MySQL实例的节点状态和节点角色；对于每一MySQL实例，若节点状态为非MySQL集群成员、且节点角色为主角色，则断开主机器的HAProxy进程与MySQL实例之间的连接，且将Consul集群中的主MySQL实例的节点角色修改为从角色。在断开连接之后，修改节点角色，以便更新Consul集群中的第一注册信息，使得不会存在有两个MySQL实例的节点角色都是主角色的情况，从而提高新的主MySQL实例的选取效率。

参阅图6，在一些实施例中，步骤S102具体包括但不限于步骤S201至步骤S203：

步骤S201，若目标监控结果为第一监控结果，对每一从MySQL实例进行日志读取，得到每一从MySQL实例的日志数量；

步骤S202，对日志数量最多的从MySQL实例进行数据检查，得到数据检查结果；数据检查结果包括第一应用结果，第一应用结果用于表征日志已被应用；

步骤S203，若数据检查结果为第一应用结果，则将Consul集群中的主MySQL实例的节点状态修改为非MySQL集群成员。

需要说明的是，主MySQL实例和从MySQL实例之间是通过二进制日志来实现数据同步的。例如，若主MySQL实例接收写请求，会将数据写入二进制日志文件，并将记录的二进制日志传输到从MySQL实例，以便从MySQL实例解析二进制日志文件并更新从MySQL实例的数据，从而实现的数据同步。因此，本申请实施例所示意的步骤S201至步骤S203，检查接收日志最多的从MySQL实例，检查二进制日志是否已经被应用到数据文件，得到数据检查结果。数据检查结果包括第一应用结果和第二应用结果。第一应用结果用于表征日志已被应用，第二应用结果用于表征日志未被应用。若数据检查结果为第二应用结果，则说明从MySQL实例的数据同步还未完成，需等待从MySQL实例继续进行日志应用，直至数据检查结果为第一应用结果。在得到第一应用结果后，说明从MySQL实例已进行完数据同步。此时，不再需要主MySQL实例，则将Consul集群中的主MySQL实例的节点状态修改为非MySQL集群成员，避免对已经故障的主MySQL实例进行数据读取。

在一些实施例的步骤S103中，通过Orchestrator节点对至少一个从MySQL实例进行筛选，得到选定MySQL实例。

若MySQL集群中包括两个MySQL实例，则一个是主MySQL实例(已经故障)，则另一个就是从MySQL实例。此时，将该从MySQL实例作为选定MySQL实例。

若从MySQL集群包括三个以上MySQL实例，则一个是主MySQL实例(已经故障)，还有两个从MySQL实例。此时，可对从MySQL实例随机选取，得到选定MySQL实例。

考虑到多个从MySQL实例中的重要程度不同，若至少简单的随机选取会影响数据读取效率。因此，步骤S103具体还包括以下步骤：

通过Orchestrator节点对每一从MySQL实例进行日志读取，得到每一MySQL实例的日志数量；根据日志数量从至少一个从MySQL实例筛选得到选定MySQL实例；

或者，

通过Orchestrator节点对每一从MySQL实例进行日志读取，得到每一MySQL实例的最新接收日志时间；根据最新接收日志时间从至少一个从MySQL实例筛选得到选定MySQL实例。

在本申请实施例中，若哪个从MySQL实例接收到的日志数量最多，说明该从MySQL实例的数据同步最多，将该从MySQL实例作为选定MySQL实例，在数据读取中，减少对其他从MySQL实例的访问，提高了数据读取效率。又或者，若哪个从MySQL实例在接收日志时，是最后一个接收到的(通过本申请实施例的最小接收日志时间确定)，则将该从MySQL实例作为选定节点。这是因为，即使该从MySQL实例不是数据同步最多的，但却接收到的数据却是最新的，说明该从MySQL实例比较活跃，从而有助于提高数据读取的效率。

在一些实施例的步骤S104中，将Consul集群中的选定MySQL实例的节点角色修改为主角色。需要说明的是，在步骤S104之前，该选定MySQL实例在Consul集群中的节点状态为MySQL集群成员，节点角色为从角色。在步骤S104之后，该选定MySQL实例在Consul集群中的节点状态为MySQL集群成员，节点角色为主角色。这样一来，后续通过Consul集群中的第一注册信息中，将得到一个节点状态为MySQL集群成员且节点角色为主角色的MySQL实例，并将该MySQL实例作为新的主MySQL实例。

在一些实施例的步骤S105中，若接收到访问请求，读取在Consul集群中的第一注册信息，以得到每一MySQL实例的节点状态和每一MySQL实例的节点角色。需要说明的是，现有技术一般是在接收到访问请求之后，就将访问请求转发至当前的主MySQL实例，并不考虑是否当前的MySQL实例已发生故障。而在本申请实施例中，在每接收到访问请求之后，先读取在Consul集群中的第一注册信息，以便从第一注册信息中的节点状态和节点角色得到新的主MySQL实例。

每一机房包括至少两台机器，至少两台机器中有一台主机器，主机器绑定了虚拟网络地址，一个机房对应一个HAProxy集群，HAProxy集群包括至少两个HAProxy进程，一个机器对应一个HAProxy进程，参阅图7，在一些实施例中，步骤S105具体包括但不限于步骤S301至步骤S302：

步骤S301，通过虚拟网络地址将访问请求发送给主机器的HAProxy进程；

步骤S302，若通过HAProxy进程接收到访问请求，通过HAProxy进程读取在Consul集群中的第一注册信息。

本申请实施例所示意的步骤S301至步骤S302，每个机房的应用服务器通过连接本机房的虚拟网络地址(VIP)连接到主机器的HAProxy进程，通过VIP向HAProxy进程发送访问请求。在HAProxy进程接收到访问请求之后，不直接转发至当前的主MySQL实例，而是先读取在Consul集群中的第一注册信息。参照上述，无论当前的主MySQL实例是否发生故障，本申请实施例都将根据第一注册信息中的节点状态和节点角色得出新的主MySQL实例。

需要说明的是，由于Keepalived集群是通过VRRP进行通信的，且VRRP底层协议使用数据链路层协议实现，也就意味着Keepalived节点所在的机器之间需连接到同一个路由器之下。对于跨机房网络不同机房之间的机器不可能连接搭到相同的路由器之下，因此在每个机房部署一个Keepalived集群，使每个机房都拥有单独的VIP。

在一示例中，每一机房的Keepalived集群配置好一个虚拟网络地址，以便应用服务器通过虚拟网络地址与主机器的HAProxy进程通信连接。因此，在步骤S201之前，获取由Keepalived集群配置的虚拟网络地址，并将虚拟网络地址绑定在至少两台机器中的一个，得到主机器。

考虑到了主机器可能会发生故障，从而导致无法进行请求转发。因此，需对主机器进行健康状态检测，以便及时发现主机器是否健康，从而及时对主机器进行切换，得出新的主机器。参阅图8，在一些实施例中，在步骤S301之前，本申请实施例的方法还包括但不限于步骤S401至步骤S402：

步骤S401，通过Keepalived集群对主机器进行健康状态检测，得到机器状态检测结果；

步骤S402，若机器状态检测结果为非健康状态，则将虚拟网络地址绑定在至少两台机器中的另一个，得到新的主机器。

本申请实施例所示意的步骤S401至步骤S402，通过对主机器进行健康状态检测，及时得到机器状态检测结果。机器状态检测结果包括健康状态和非健康状态。若机器状态检测结果为健康状态，则继续对主机器进行健康状态检测，且不进行主机器的切换。若机器状态检测结果为非健康状态，则将虚拟网络地址绑定在除了当前的主机器之外的其他机器中的一个，从而得到新的主机器。由于避免了将访问请求发送至已经处于非健康状态的主机器的HAProxy进程，提高了请求转发的效率，也避免了数据丢失。

步骤S401具体包括但不限于：

通过至少两台机器之间的Keepalived节点互发心跳信息；

若未接收到来自主机器的所述心跳信息，且超过预设的等待时长阈值，则机器状态检测结果为非健康状态。

具体地，通过机器之间的Keepalived节点互相发送心跳信息，以便通过是否接收到来自主机器的心跳信息判断主机器的机器状态检测结果。需要说明的是，若未接收到来自主机器的心跳信息，可能是因为网络延迟或心跳信息丢失，也可能是主机器已发送故障并未发送心跳信息。为了排除网络延迟等非机器故障原因，因此引入了等待时长阈值。若超过了等待时间阈值都未能接收到来自主机器的心跳信息，则说明主机器已发生故障，从而机器状态检测结果为非健康状态。

需要说明的是，访问请求具体是要通过HAProxy进程进行转发，若HAProxy进程处于非健康状态，即使主机器未发生故障，仍能正常进行心跳信息的发送，也无法通过HAProxy进程进行访问请求的正常转发。因此，在一些实施例中，步骤S401具体还包括但不限于：

对于主机器，通过Keepalived节点对HAProxy进程进行健康监控，得到监控结果；

若监控结果为进程监控失败，则机器状态检测结果为非健康状态。

具体地，即使主机器未发生故障，若HAProxy进程的监控结果为进程监控失败，由于该主机器的HAProxy进程已无法进行访问请求的转发，需重新选取主机器，因此，当前的主机器的机器状态检测结果为非健康状态。

在一些实施例的步骤S106中，根据节点状态和节点角色对MySQL实例进行筛选，将节点状态为MySQL集群成员且节点角色为主角色的MySQL实例作为新的主MySQL实例，并将访问请求发送至新的主MySQL实例。需要说明的是，无论是否接收到访问请求，本申请实施例都通过Orchestrator节点对MySQL集群的健康状态进行监控，并及时修改节点状态和节点角色，以便及时更新Consul集群中的第一注册信息。可以理解的是，若MySQL集群的目标监控结果为第二监控结果，则在接收到访问请求后，根据节点状态和节点角色得到的主MySQL实例就是当前的主MySQL实例。若MySQL集群的目标监控结果为第一监控结果，则在接收到访问请求后，根据节点状态和节点角色得到的主MySQL实例将不同于当前的主MySQL实例(已经故障)。因此，本申请实施例避免了将访问请求发给已经故障的主MySQL实例，减少了数据丢失。

本申请实施例至少具备以下优点：

a)实现异地容灾：MySQL集群使用异地跨机房部署，能够抵抗由于机房断网、机房出现故障等情况时的数据丢失。

b)能够实现跨机房高可用：所有组建采用异地跨机房部署，在本地机房出现故障时，会自动查找其他机房的从数据库作为主数据库并将应用的请求自动转发到其他机房。

c)能够实现数据的一致性：若出现故障，则在数据库在切换之前，切断应用与故障的主数据库之间的连接，避免了由于故障的主数据库可能由于假死时造成应用同时写数据到老的主数据库与新的主数据库的数据混乱的问题。

本申请实施例还提供了电子设备，电子设备包括：存储器、处理器、存储在存储器上并可在处理器上运行的程序以及用于实现处理器和存储器之间的连接通信的数据总线，程序被处理器执行时实现上述高可用数据库管理的方法。该电子设备可以为包括平板电脑、车载电脑等任意智能终端。

请参阅图9，图9示意了另一实施例的电子设备的硬件结构，电子设备包括：

处理器501，可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请实施例所提供的技术方案；

存储器502，可以采用只读存储器(Read Only Memory，ROM)、静态存储设备、动态存储设备或者随机存取存储器(Random Access Memory，RAM)等形式实现。存储器502可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器502中，并由处理器501来调用执行本申请实施例的高可用数据库管理的方法；

输入/输出接口503，用于实现信息输入及输出；

通信接口504，用于实现本设备与其他设备的通信交互，可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信；

总线505，在设备的各个组件(例如处理器501、存储器502、输入/输出接口503和通信接口504)之间传输信息；

其中处理器501、存储器502、输入/输出接口503和通信接口504通过总线505实现彼此之间在设备内部的通信连接。

本申请实施例还提供了存储介质，存储介质为计算机可读存储介质，用于计算机可读存储，存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现上述高可用数据库管理的方法。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例提供的高可用数据库管理的方法、电子设备及存储介质，通过跨机房部署MySQL集群、跨机房部署Orchestrator集群和跨机房部署Consul集群，实现对MySQL集群的故障监控和故障转移。能在主MySQL实例(主数据库)出现故障时，能够及时发现故障和及时更换主数据库，提高了数据库的可用率。

本申请实施例描述的实施例是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

本领域技术人员可以理解的是，图2-8中示出的技术方案并不构成对本申请实施例的限定，可以包括比图示更多或更少的步骤，或者组合某些步骤，或者不同的步骤。

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

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

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

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

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

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

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

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

以上参照附图说明了本申请实施例的优选实施例，并非因此局限本申请实施例的权利范围。本领域技术人员不脱离本申请实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本申请实施例的权利范围之内。

Claims (10)

1.一种高可用数据库管理的方法，其特征在于，应用于至少两个机房，一个所述机房对应一个MySQL实例，所述MySQL实例构成MySQL集群，所述MySQL集群中有一个主MySQL实例，所述MySQL集群中有至少一个从MySQL实例，一个所述机房对应一个Orchestrator节点，所述Orchestrator节点构成Orchestrator集群，一个所述机房对应一个Consul节点，所述Consul节点构成Consul集群，所述Consul集群存储有所述MySQL实例的第一注册信息，所述第一注册信息包括节点状态和节点角色，节点状态包括非MySQL集群成员和MySQL集群成员，节点角色包括主角色；

所述方法包括：

通过所述Orchestrator节点对所述MySQL集群的健康状态进行监控，得到目标监控结果；所述目标监控结果包括第一监控结果，所述第一监控结果用于表征当前的所述主MySQL实例已故障；

若所述目标监控结果为所述第一监控结果，则将所述Consul集群中的所述主MySQL实例的所述节点状态修改为非MySQL集群成员；

通过所述Orchestrator节点对至少一个所述从MySQL实例进行筛选，得到选定MySQL实例；

将所述Consul集群中的所述选定MySQL实例的所述节点角色修改为主角色；

若接收到访问请求，读取在所述Consul集群中的所述第一注册信息，以得到每一所述MySQL实例的节点状态和每一所述MySQL实例的节点角色；

根据所述节点状态和所述节点角色对所述MySQL实例进行筛选，将所述节点状态为MySQL集群成员且所述节点角色为所述主角色的所述MySQL实例作为新的所述主MySQL实例，并将所述访问请求发送至新的所述主MySQL实例。

2.根据权利要求1所述的方法，其特征在于，每一所述机房包括至少两台机器，至少两台所述机器中有一台主机器，所述主机器绑定了虚拟网络地址，一个所述机房对应一个HAProxy集群，所述HAProxy集群包括至少两个HAProxy进程，一个所述机器对应一个HAProxy进程，所述若接收到访问请求，读取在所述Consul集群中的所述第一注册信息，包括：

通过所述虚拟网络地址将访问请求发送给所述主机器的所述HAProxy进程；

若通过所述HAProxy进程接收到所述访问请求，通过所述HAProxy进程读取在所述Consul集群中的所述第一注册信息。

3.根据权利要求2所述的方法，其特征在于，一个所述机房对应一个Keepalived集群，所述Keepalived集群包括至少两个Keepalived节点，一个所述机器对应一个所述Keepalived节点，在所述通过所述虚拟网络地址将访问请求发送给所述主机器的所述HAProxy进程之前，所述方法还包括：

通过Keepalived集群对所述主机器进行健康状态检测，得到机器状态检测结果；

若所述机器状态检测结果为非健康状态，则将所述虚拟网络地址绑定在至少两台所述机器中的另一个，得到新的所述主机器。

4.根据权利要求3所述的方法，其特征在于，所述通过Keepalived集群对所述主机器进行健康状态检测，得到机器状态检测结果，包括：

通过至少两台所述机器之间的Keepal ived节点互发心跳信息；若未接收到来自所述主机器的所述心跳信息，且超过预设的等待时长阈值，则所述机器状态检测结果为非健康状态；

或者，

对于所述主机器，通过所述Keepal ived节点对所述HAProxy进程进行健康监控，得到监控结果；若监控结果为进程监控失败，则所述机器状态检测结果为所述非健康状态。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述若所述目标监控结果为所述第一监控结果，则将所述Consul集群中的所述主MySQL实例的所述节点状态修改为非MySQL集群成员，包括：

若所述目标监控结果为所述第一监控结果，对每一所述从MySQL实例进行日志读取，得到每一所述从MySQL实例的日志数量；

对所述日志数量最多的所述从MySQL实例进行数据检查，得到数据检查结果；所述数据检查结果包括第一应用结果，所述第一应用结果用于表征日志已被应用；

若所述数据检查结果为所述第一应用结果，则将所述Consul集群中的所述主MySQL实例的所述节点状态修改为非MySQL集群成员。

6.根据权利要求1至4任一项所述的方法，其特征在于，所述通过所述Orchestrator节点对至少一个所述从MySQL实例进行筛选，得到选定MySQL实例，包括：

通过所述Orchestrator节点对每一所述从MySQL实例进行日志读取，得到每一所述MySQL实例的日志数量；

根据所述日志数量从至少一个所述从MySQL实例筛选得到所述选定MySQL实例。

7.根据权利要求1至4任一项所述的方法，其特征在于，所述通过所述Orchestrator节点对至少一个所述从MySQL实例进行筛选，得到选定MySQL实例，包括：

通过所述Orchestrator节点对每一所述从MySQL实例进行日志读取，得到每一所述MySQL实例的最新接收日志时间；

根据所述最新接收日志时间从至少一个所述从MySQL实例筛选得到所述选定MySQL实例。

8.根据权利要求2至4任一项所述的方法，其特征在于，在所述通过所述HAProxy进程读取在所述Consul集群中的所述第一注册信息之后，所述方法还包括：

若所述主MySQL实例的节点状态为所述非MySQL集群成员，断开所述HAProxy进程与所述主MySQL实例的连接。

9.一种电子设备，其特征在于，所述电子设备包括存储器、处理器、所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1至8任一项所述的方法。

10.一种存储介质，所述存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的方法。

Images