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

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

Info

Publication number
CN117370316A
CN117370316A CN202311668063.XA CN202311668063A CN117370316A CN 117370316 A CN117370316 A CN 117370316A CN 202311668063 A CN202311668063 A CN 202311668063A CN 117370316 A CN117370316 A CN 117370316A
Authority
CN
China
Prior art keywords
communication
instance
state detection
detection result
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311668063.XA
Other languages
English (en)
Inventor
姚前
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Primitive Data Beijing Information Technology Co ltd
Original Assignee
Primitive Data Beijing Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Primitive Data Beijing Information Technology Co ltd filed Critical Primitive Data Beijing Information Technology Co ltd
Priority to CN202311668063.XA priority Critical patent/CN117370316A/zh
Publication of CN117370316A publication Critical patent/CN117370316A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Hardware Redundancy (AREA)

Abstract

本申请实施例提供了一种数据库的高可用管理方法和装置、电子设备及存储介质，属于数据库技术领域。该方法应用于服务节点集群的多个服务节点中的目标服务节点，目标服务节点与目标数据库实例部署在同一个目标服务器，数据库的高可用管理方法包括：通过预设的心跳进程对目标数据库实例进行实例状态检测，得到实例状态检测结果，再通过预设的通信进程对目标服务节点与服务节点集群中各个服务节点的通信进行通信状态检测，得到通信状态检测结果，基于实例状态检测结果和通信状态检测结果对目标数据库实例进行故障转移。因此，本申请实施例能够提高数据库管理系统的可用性的同时，减少对第三方服务的依赖。

Description

数据库的高可用管理方法和装置、电子设备及存储介质
技术领域
本申请涉及数据库技术领域，尤其涉及一种数据库的高可用管理方法和装置、电子设备及存储介质。
背景技术
目前，现代软件体系中，对于数据库管理系统可用性的要求越来越高，数据库一般采用一主多备的容灾部署架构来实现高可用。主库对外提供读写服务，备库和主库之间做实时日志同步，当主库故障时，备库可通过提升角色来代替原主库继续对外提供服务。但是，其数据库本身不具备自动故障转移的能力，所以需要单独部署一套监控运维系统来完成自动的故障探测和数据库的故障转移。因此，如何在不依赖数据库外部服务的前提下，实现高可用服务去中心化，成为了亟待解决的技术问题。
发明内容
本申请实施例的主要目的在于提出一种数据库资源管理方法和装置、电子设备及存储介质，旨在提高数据库管理系统的可用性的同时，减少对第三方服务的依赖。
为实现上述目的，本申请实施例的第一方面提出了一种数据库的高可用管理方法，所述数据库的高可用管理方法应用于服务节点集群的多个服务节点中的目标服务节点，所述目标服务节点与目标数据库实例部署在同一个目标服务器，所述数据库的高可用管理方法包括：
通过预设的心跳进程对所述目标数据库实例进行实例状态检测，得到实例状态检测结果；
通过预设的通信进程对所述目标服务节点与所述服务节点集群中各个所述服务节点的通信进行通信状态检测，得到通信状态检测结果；
基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移。
根据本发明的一些实施例，在所述基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移之后，所述数据库的高可用管理方法，还包括：
通过预设的看护进程对所述心跳进程进行心跳进程状态检测，得到心跳进程状态；
通过预设的看护进程对所述通信进程进行通信进程状态检测，得到通信进程状态；
若所述心跳进程状态为非运行状态，则重启所述心跳进程，若所述通信进程状态为非运行状态，则重启所述通信进程。
根据本发明的一些实施例，所述通过预设的通信进程对所述目标服务节点与所述服务节点集群中各个所述服务节点的通信进行通信状态检测，得到通信状态检测结果，包括：
通过所述通信进程向所述服务节点集群中各个所述服务节点发送消息请求；
通过所述通信进程接收各个所述服务节点响应于所述消息请求发送的反馈信息；
如果接收到的所述反馈信息的第一数目大于未接收到的所述反馈信息的第二数目，则通信状态检测结果为通信成功；
如果接收到的所述反馈信息的第一数目小于或等于未接收到的所述反馈信息的第二数目，则通信状态检测结果为通信失败。
根据本发明的一些实施例，多个服务节点为两个服务节点，所述基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移，包括：
若所述通信状态检测结果为通信失败，则对所述目标服务节点与网关之间的通信进行网路延迟状态检测，得到网络延迟状态检测结果；
基于所述实例状态检测结果和所述网络延迟状态检测结果对所述目标数据库实例进行故障转移。
根据本发明的一些实施例，其特征在于，所述通过预设的心跳进程对所述目标数据库实例进行实例状态检测，得到实例状态检测结果，包括：
获取所述目标数据库实例的心跳监测数据；
根据所述心跳监测数据和预设的故障检测逻辑规则进行故障检测，得到所述实例状态检测结果。
根据本发明的一些实施例，所述基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移，包括：
若所述实例状态检测结果为非运行状态、或所述通信状态检测结果为通信失败，确定所述目标数据库实例的角色；
若所述目标数据库实例的角色为主数据库实例，则解除所述目标数据库实例绑定的虚拟地址，重启或切换所述目标数据库实例。
根据本发明的一些实施例，所述重启或切换所述目标数据库实例，包括：
确定所述数据库实例对应的磁盘的状态，得到磁盘状态；
若所述磁盘状态为磁盘故障，则切换所述目标数据库实例。
为实现上述目的，本申请实施例的第二方面提出了一种数据库的高可用管理装置，所述数据库的高可用管理装置应用于服务节点集群的多个服务节点中的目标服务节点，所述目标服务节点与目标数据库实例部署在同一个目标服务器，所述数据库的高可用管理装置包括：
实例状态检测模块，用于通过预设的心跳进程对所述目标数据库实例进行实例状态检测，得到实例状态检测结果；
通信状态检测模块，用于通过预设的通信进程对所述目标服务节点与所述服务节点集群中各个所述服务节点的通信进行通信状态检测，得到通信状态检测结果；
故障转移模块，用于基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移。
为实现上述目的，本申请实施例的第三方面提出了一种电子设备，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的方法。
为实现上述目的，本申请实施例的第四方面提出了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的方法。
本申请提出的数据库的高可用管理方法和装置、电子设备及存储介质,其应用于服务节点集群的多个服务节点中的目标服务节点，目标服务节点与目标数据库实例部署在同一个目标服务器，数据库的高可用管理方法包括：通过预设的心跳进程对目标数据库实例进行实例状态检测，得到实例状态检测结果。然后通过预设的通信进程对目标服务节点与服务节点集群中各个服务节点的通信进行通信状态检测，得到通信状态检测结果，最后基于实例状态检测结果和通信状态检测结果对目标数据库实例进行故障转移。由于每个高可用服务节点和数据库实例部署在同一个服务器上，并在高可用服务节点内部通过通信进程和心跳进程实现故障检查和元数据同步，不依赖外部服务。因此，本申请实施例能够提高数据库管理系统的可用性的同时，减少对第三方服务的依赖。
附图说明
图1是本申请实施例提供的数据库的高可用管理方法的流程图；
图2是本申请另一实施例提供的数据库的高可用管理方法的流程图；
图3是图1中的步骤S102的流程图；
图4是图1中的步骤S103的一个可选的流程图；
图5是图1中的步骤S101的流程图；
图6是图1中的步骤S103的一个可选的流程图；
图7是图6中的步骤S602的流程图；
图8是本申请实施例提供的数据库的高可用管理装置的结构示意图；
图9是本申请实施例提供的电子设备的硬件结构示意图；
图10是本申请一实施例提供的数据库的高可用管理方法应用的系统架构示意图；
图11是本申请另一实施例提供的数据库的高可用管理方法应用的系统架构示意图；
图12是本申请实施例提供的数据库的高可用管理方法的应用示例图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。
需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
目前，现代软件体系中，对于数据库管理系统可用性的要求越来越高，数据库一般采用一主多备的容灾部署架构来实现高可用。主库对外提供读写服务，备库和主库之间做实时日志同步，当主库故障时，备库可通过提升角色来代替原主库继续对外提供服务。但是，其数据库本身不具备自动故障转移的能力，所以需要单独部署一套监控运维系统来完成自动的故障探测和数据库的故障转移。因此，如何在不依赖数据库外部服务的前提下，实现高可用服务去中心化，成为了亟待解决的技术问题。
基于此，本申请实施例提供了一种数据库的高可用管理方法和装置、电子设备及存储介质，旨在提高数据库管理系统的可用性的同时，减少对第三方服务的依赖。
本申请实施例提供的数据库的高可用管理方法和装置、电子设备及存储介质，具体通过如下实施例进行说明，首先描述本申请实施例中的数据库的高可用管理方法。
本申请实施例提供的数据库的高可用管理方法，涉及数据库技术领域。本申请实施例提供的数据库的高可用管理方法可应用于服务器端中，还可以是运行于服务器端中的软件。在一些实施例中，服务器端可以配置成独立的物理服务器，也可以配置成多个物理服务器构成的服务器集群或者分布式系统，还可以配置成提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN以及大数据和人工智能平台等基础云计算服务的云服务器；软件可以是实现数据库的高可用管理方法的应用等，但并不局限于以上形式。
本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
图1是本申请实施例提供的数据库的高可用管理方法的一个可选的流程图，数据库的高可用管理方法应用于服务节点集群的多个服务节点中的目标服务节点，目标服务节点与目标数据库实例部署在同一个目标服务器，图1中的方法可以包括但不限于包括步骤S101至步骤S103。
步骤S101，通过预设的心跳进程对目标数据库实例进行实例状态检测，得到实例状态检测结果；
步骤S102，通过预设的通信进程对目标服务节点与服务节点集群中各个服务节点的通信进行通信状态检测，得到通信状态检测结果；
步骤S103，基于实例状态检测结果和通信状态检测结果对目标数据库实例进行故障转移。
本申请实施例所示意的步骤S101至步骤S103，通过预设的心跳进程对目标数据库实例进行实例状态检测，得到实例状态检测结果。然后通过预设的通信进程对目标服务节点与服务节点集群中各个服务节点的通信进行通信状态检测，得到通信状态检测结果，最后基于实例状态检测结果和通信状态检测结果对目标数据库实例进行故障转移。由于每个高可用服务节点和数据库实例部署在同一个服务器上，并在高可用服务节点内部通过通信进程和心跳进程实现故障检查和元数据同步，不依赖外部服务。并且高可用服务独立于数据库进程运行，当高可用服务服于不可控的故障导致进程退出后，数据库的服务依旧是可以持续提供服务的，高可用服务退出不会导致数据库服务进程退出。因此，本申请实施例能够提高数据库管理系统的可用性的同时，减少了对第三方服务的依赖并且实现了高可用服务和数据库服务解耦，高可用服务故障无法波及数据库服务。
需要说明的是，本申请采用分布式系统的设计，多个服务节点中的每个服务节点与各自的数据库实例部署在同一个服务器上。服务节点内部通过通信协调实现故障检查和元数据同步，不依赖外部服务，每个节点的高可用服务都是同一套程序，根据数据库实例的角色自动切换检测逻辑，实现了去中心化。
在一些实施例的步骤S103之后，数据库的高可用管理方法还包括：看护进程。由于数据库的高可用管理方法需要存在看护进程，用于看护心跳进程和通信进程，从而确保高可用服务自身的高可用。
请参阅图2，在一些实施例中，数据库的高可用管理方法方法还可以包括但不限于包括步骤S201至步骤S203：
步骤S201，通过看护进程对心跳进程进行心跳进程状态检测，得到心跳进程状态；
步骤S202，通过看护进程对通信进程进行通信进程状态检测，得到通信进程状态；
步骤S203，若心跳进程状态为非运行状态，则重启心跳进程，若通信进程状态为非运行状态，则重启通信进程。
在一些实施例的步骤S201中，可以通过预先设置的看护进程脚本对心跳进程进行心跳进程状态检测，得到心跳进程状态，以用于判断当前心跳进程是否处于正常运行状态。也可以通过第三方看护进程工具，以实现更加高效的心跳进程状态检测，不限于此。
在一些实施例的步骤S202中，可以通过预先设置的看护进程脚本对通信进程进行通信进程状态检测，得到通信进程状态，以用于判断当前通信进程是否处于正常运行状态。也可以通过第三方看护进程工具，以实现更加高效的通信进程状态检测，不限于此。
在一些实施例的步骤S203中，若心跳进程状态为非运行状态，即说明此时心跳进程中断，需立刻重启心跳进程以确保高可用服务节点的故障检测功能可以正常运行。若通信进程状态为非运行状态，即说明此时通信进程中断，则需立刻重启通信进程以确保高可用服务节点的元数据同步功能可以正常运行。
需要说明的是，看护进程可以在心跳进程和通信进程启动时自动启动，并持续运行，以确保高可用服务的持续可用性。
本申请实施例所示意的步骤S201至步骤S203，通过看护进程对心跳进程进行心跳进程状态检测，得到心跳进程状态，通过看护进程对通信进程进行通信进程状态检测，得到通信进程状态，若心跳进程状态为非运行状态，则重启心跳进程，若通信进程状态为非运行状态，则重启通信进程。因此，当任何一个进程意外退出，可以及时的重新启动对应的进程模块，从而确保高可用服务自身的高可用。
请参阅图3，在一些实施例中，步骤S102可以包括但不限于包括步骤S301至步骤S304：
步骤S301，通过通信进程向服务节点集群中各个服务节点发送消息请求；
步骤S302，通过通信进程接收各个服务节点响应于消息请求发送的反馈信息；
步骤S303，如果接收到的反馈信息的第一数目大于未接收到的反馈信息的第二数目，则通信状态检测结果为通信成功；
步骤S304，如果接收到的反馈信息的第一数目小于或等于未接收到的反馈信息的第二数目，则通信状态检测结果为通信失败。
在一些实施例的步骤S301中，通过通信进程向服务节点集群中各个服务节点发送消息请求，以实现对每一服务节点进行通信状态检测。
在一些实施例的步骤S302中，通过通信进程接收各个服务节点响应于消息请求发送的反馈信息，以根据反馈信息的数量来判断通信进程状态是否正常。
在一些实施例的步骤S303中，可以通过多数派校验来判断当前节点是否故障，如果接收到的反馈信息的第一数目大于未接收到的反馈信息的第二数目，即表明多数节点可以正常运行，即通信进行状态正常，则通信状态检测结果为通信成功。
在一些实施例的步骤S304中，采用通过多数派校验来判断当前节点是否故障，如果接收到的反馈信息的第一数目小于或等于未接收到的反馈信息的第二数目，即表明多数节点不可以正常运行，即通信进行状态不正常，则通信状态检测结果为通信失败。
本申请实施例所示意的步骤S301至步骤S304，通过通信进程向服务节点集群中各个服务节点发送消息请求，再通过通信进程接收各个服务节点响应于消息请求发送的反馈信息。如果接收到的反馈信息的第一数目大于未接收到的反馈信息的第二数目，则通信状态检测结果为通信成功。如果接收到的反馈信息的第一数目小于或等于未接收到的反馈信息的第二数目，则通信状态检测结果为通信失败。因此，可以通过多数派校验的方式以高效地实现通信进程状态检测功能。
请参阅图4和图10，在一些实施例中，多个服务节点为两个服务节点，步骤S103可以包括但不限于包括步骤S401至步骤S402：
步骤S401，若通信状态检测结果为通信失败，则对目标服务节点与网关之间的通信进行网路延迟状态检测，得到网络延迟状态检测结果；
步骤S402，基于实例状态检测结果和网络延迟状态检测结果对目标数据库实例进行故障转移。
在一些实施例的步骤S401中，当多个服务节点为两个服务节点时，若通信状态检测结果为通信失败，则说明至少有一个服务节点存在通信故障。因此，对目标服务节点与网关之间的通信进行网路延迟状态检测，以实现无需第三方服务器的情况下对目标服务节点的网路延迟状态检测。
需要说明的是，当多个服务节点为两个服务节点时，此时的系统是一个特殊的部署架构，相比3节点可以通过多数派校验来判断当前节点是否故障，而两节点无法达到多数派的要求。故此处引入了网关作为仲裁节点的概念，作为网络判断的公立方，这个仲裁节点可以是网关，也可以是第三台服务器，当然，为了节省服务器成本，如果主备在同网段内的话，一般采用网关作为仲裁节点，因为对于网关来说，主备的机器都是可以ping通的。
请参阅图11，需要进一步说明的是，加入了网关做仲裁节点以后，就可能出现以下几种情况：
1.正常情况下，对方IP和网关都可以ping通的；
2.ping不通对方IP，但是可以ping通网关：说明对方机器宕机网络故障或者宕机了，此时就应该考虑切换；
3.ping不通对方IP，也ping不通网关：说明自己出现了网络故障，需要关闭数据库进程来保护数据。
具体的，可以根据上述几种情况设置网络延迟状态检测结果。
在一些实施例的步骤S402中，基于实例状态检测结果和网络延迟状态检测结果对目标数据库实例进行故障转移，以实现在仅有两个服务节点的情况下，精准地对服务节点进行故障转移。
本申请实施例所示意的步骤S401至步骤S402，若通信状态检测结果为通信失败，则通过对目标服务节点与网关之间的通信进行网路延迟状态检测，得到网络延迟状态检测结果。基于实例状态检测结果和网络延迟状态检测结果对目标数据库实例进行故障转移。因此，实现了在仅有两个服务节点的情况下，节省了服务器成本的同时，精确地完成了服务节点的网络故障检测和目标数据库实例的故障转移。
请参阅图5，在一些实施例中，步骤S101可以包括但不限于包括步骤S501至步骤S502：
步骤S501，获取目标数据库实例的心跳监测数据；
步骤S502，根据心跳监测数据和预设的故障检测逻辑规则进行故障检测，得到实例状态检测结果。
在一些实施例的步骤S501中，可以通过在数据库服务器上设置一个定时任务来获取目标数据库实例的心跳监测数据。心跳进程可以定期向数据库发送一个特定的查询或者命令，以检测目标数据库实例的状态和可用性。也可以采用专门的监控工具，不限于此。
在一些实施例的步骤S502中，心跳监测数据包括不同的故障场景数据，预设的故障检测逻辑规则可以根据不同的故障场景数据进行智能的故障判断，根据不同的故障场景数据按照故障检测逻辑规则进行故障检测，即可快速了解目标数据库实例的故障情况，根据目标数据库实例的故障情况得到实例状态检测结果。
本申请实施例所示意的步骤S501至步骤S502，通过获取目标数据库实例的心跳监测数据，并根据心跳监测数据和预设的故障检测逻辑规则进行故障检测，得到实例状态检测结果，以实现对实例状态和故障情况的快速判断。
请参阅图6，在一些实施例，步骤S103可以包括但不限于包括步骤S601至步骤S602：
步骤S601，若实例状态检测结果为非运行状态、或通信状态检测结果为通信失败，确定目标数据库实例的角色；
步骤S602，若目标数据库实例的角色为主数据库实例，则解除目标数据库实例绑定的虚拟地址，重启或切换目标数据库实例。
在一些实施例的步骤S601中，若实例状态检测结果为非运行状态、或通信状态检测结果为通信失败，确定目标数据库实例的角色，以用于判断具体的故障情况。
在一些实施例的步骤S602中，若目标数据库实例的角色为主数据库实例，即说明故障发生在主数据库实例中，应当解除目标数据库实例绑定的虚拟地址，并发送重启或切换指令，以使目标数据库实例进行重启或将目标数据库实例切换成其它可运行数据库实例。
本申请实施例所示意的步骤S601至步骤S602，若实例状态检测结果为非运行状态、或通信状态检测结果为通信失败，则通过确定目标数据库实例的角色，以用于判断具体的故障情况。当确认故障发生在住数据库实例时，解除目标数据库实例绑定的虚拟地址，重启或切换目标数据库实例，以快速切换或重启目标数据库实例，从而提高数据库的可用性。
请参阅图7，在一些实施例中，步骤S602可以包括但不限于包括步骤S701至步骤S702：
步骤S701，确定数据库实例对应的磁盘的状态，得到磁盘状态；
步骤S702，若磁盘状态为磁盘故障，则切换目标数据库实例。
在一些实施例的步骤S701中，确定数据库实例对应的磁盘的状态，得到磁盘状态，以用于后续判断磁盘是否发生故障。
需要说明的是，首先需要确定目标数据库实例所使用的磁盘。这个磁盘可以是一个本地磁盘、网络存储、云存储等。对于本地磁盘，可以根据数据库配置文件或操作系统的磁盘分区信息确定所使用的磁盘。然后根据所使用的磁盘类型和操作系统提供的功能，可以获取磁盘的状态信息。也可以使用操作系统提供的命令行工具、API接口，或者使用第三方的磁盘监控工具。不同的操作系统和磁盘类型可能提供不同的方式来获取磁盘状态信息，不限于此。
在一些实施例的步骤S702中，若磁盘状态为磁盘故障，则切换目标数据库实例，即在目标数据库实例发生故障的前提下，检测出其对应的磁盘也发生了故障，切换备用数据库实例作为新的主数据库实例。
需要说明的是，由于若原本故障的主数据库实例对应的磁盘也发生故障，那么磁盘故障导致无法对此数据库实例进行重启，则此时只能切换备用数据库实例作为新的主数据库实例。
本申请实施例所示意的步骤S701至步骤S702，通过确定数据库实例对应的磁盘的状态，得到磁盘状态，若磁盘状态为磁盘故障，则切换目标数据库实例，以实现对磁盘发生故障的主数据库实例进行快速切换，避免了因反复重启磁盘故障的数据库实例导致的数据库服务停滞，从而提高了数据库故障处理的效率。
本申请实施例还提供一种数据库的高可用管理方法的应用示例。如图12所示，数据库的高可用管理方法包括：
（1）开始进程。
（2）检测服务节点集群的目标服务节点。
（3）根据目标服务节点数据判断数据库是否处于运行中。如果数据库处于运行中，进入步骤（4）。如果数据库未运行，进入步骤（18）。
（4）确定当前数据库是否为主数据库。如果当前数据库是主数据库，进入步骤（5）。如果当前数据库不是主数据库，进入步骤（12）。
（5）确定当前网络是否孤单。如果当前网络孤单，进入步骤（6）。如果当前网络不孤单，进入步骤（7）。
（6）卸载数据库实例绑定的虚拟地址（VIP），并关闭数据库实例，结束进程。
（7）确定是否存在双主数据库。如果存在双主数据库，进入步骤（8）。如果不存在双主数据库，进入步骤（10）。
（8）进行双主决策确定真主数据库。
（9）确定当前数据库是否为真主数据库。如果当前数据库是真主数据库，进入步骤（10）。如果不是，返回步骤（6）。
（10）挂载数据库实例绑定的虚拟地址，并检查同步备列表。
（11）刷新元数据，并结束进程。
（12）确定当前数据库是否为备用数据库。如果是，进入步骤（13）。如果不是，进入步骤（17）。
（13）确定当前数据库是否为可接管的同步备用数据库。如果是，进入步骤（14）。如果不是，进入步骤（16）。
（14）判断主数据库是否离线。如果是，进入步骤（15）。如果不是，进入步骤（16）。
（15）进行失效转移（failover）并挂载数据库实例绑定的虚拟地址，结束进程。
（16）与主数据库进行元数据同步，并结束进程。
（17）确定数据库是否为级联备数据库。如果是，返回步骤（16）。如果不是，关闭实例并结束进程。
（18）判断决策当前节点的角色对应的数据库是否为主数据库。如果是，进入步骤（21）。如果不是，进入步骤（19）。
（19）确定是否需要处理非主实例。如果需要，进入步骤（20）。如果不需要，结束进程。
（20）重启实例，并结束进程。
（21）卸载数据库实例绑定的虚拟地址（VIP），并确定磁盘是否故障。如果是，进入步骤（22）。如果不是，进入步骤（23）。
（22）进行切换实例，将备用数据库切换为主数据库，给同步备发送失效转移请求，并结束进程。
（23）确定是重启还是切换实例。如果是重启实例，进入步骤（24）。如果是切换实例，返回步骤（22）。
（24）重启实例，并确定是否重启成功。如果是，结束进程。如果否，返回步骤（22）。
请参阅图8，本申请实施例还提供一种数据库的高可用管理装置，可以实现上述数据库的高可用管理方法，数据库的高可用管理装置应用于服务节点集群的多个服务节点中的目标服务节点，目标服务节点与目标数据库实例部署在同一个目标服务器，该装置包括：
实例状态检测模块801，用于通过预设的心跳进程对目标数据库实例进行实例状态检测，得到实例状态检测结果；
通信状态检测模块802，用于通过预设的通信进程对目标服务节点与服务节点集群中各个服务节点的通信进行通信状态检测，得到通信状态检测结果；
故障转移模块803，用于基于实例状态检测结果和通信状态检测结果对目标数据库实例进行故障转移。
该数据库的高可用管理装置的具体实施方式与上述数据库的高可用管理方法的具体实施例基本相同，在此不再赘述。
本申请实施例还提供了一种电子设备，电子设备包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述数据库的高可用管理方法。该电子设备可以为包括个人电脑、虚拟机、云主机等任意智能终端。
请参阅图9，图9示意了另一实施例的电子设备的硬件结构，电子设备包括：
处理器901，可以采用通用的CPU(CentralProcessingUnit，中央处理器)、微处理器、应用专用集成电路(ApplicationSpecificIntegratedCircuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请实施例所提供的技术方案；
存储器902，可以采用只读存储器（ReadOnlyMemory，ROM）、静态存储设备、动态存储设备或者随机存取存储器(RandomAccessMemory，RAM)等形式实现。存储器902可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器902中，并由处理器901来调用执行本申请实施例的数据库的高可用管理方法；
输入/输出接口903，用于实现信息输入及输出；
通信接口904，用于实现本设备与其他设备的通信交互，可以通过有线方式（例如USB、网线等）实现通信，也可以通过无线方式（例如移动网络、WIFI、蓝牙等）实现通信；
总线905，在设备的各个组件（例如处理器901、存储器902、输入/输出接口903和通信接口904）之间传输信息；
其中处理器901、存储器902、输入/输出接口903和通信接口904通过总线905实现彼此之间在设备内部的通信连接。
本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述数据库的高可用管理方法。
存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
本申请实施例提供的数据库的高可用管理方法、数据库的高可用管理装置、电子设备及存储介质，其通过预设的心跳进程对目标数据库实例进行实例状态检测，得到实例状态检测结果。然后通过预设的通信进程对目标服务节点与服务节点集群中各个服务节点的通信进行通信状态检测，得到通信状态检测结果，最后基于实例状态检测结果和通信状态检测结果对目标数据库实例进行故障转移。由于每个高可用服务节点和数据库实例部署在同一个服务器上，并在高可用服务节点内部通过通信进程和心跳进程实现故障检查和元数据同步，不依赖外部服务。并且高可用服务独立于数据库进程运行，当高可用服务服于不可控的故障导致进程退出后，数据库的服务依旧是可以持续提供服务的，高可用服务退出不会导致数据库服务进程退出。因此，本申请实施例能够提高数据库管理系统的可用性的同时，减少了对第三方服务的依赖并且实现了高可用服务和数据库服务解耦，高可用服务故障无法波及数据库服务。
本申请实施例描述的实施例是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
本领域技术人员可以理解的是，图中示出的技术方案并不构成对本申请实施例的限定，可以包括比图示更多或更少的步骤，或者组合某些步骤，或者不同的步骤。
以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。
本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“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.一种数据库的高可用管理方法，其特征在于，所述数据库的高可用管理方法应用于服务节点集群的多个服务节点中的目标服务节点，所述目标服务节点与目标数据库实例部署在同一个目标服务器，所述数据库的高可用管理方法包括：
通过预设的心跳进程对所述目标数据库实例进行实例状态检测，得到实例状态检测结果；
通过预设的通信进程对所述目标服务节点与所述服务节点集群中各个所述服务节点的通信进行通信状态检测，得到通信状态检测结果；
基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移。
2.根据权利要求1所述的方法，其特征在于，在所述基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移之后，所述数据库的高可用管理方法，还包括：
通过预设的看护进程对所述心跳进程进行心跳进程状态检测，得到心跳进程状态；
通过预设的看护进程对所述通信进程进行通信进程状态检测，得到通信进程状态；
若所述心跳进程状态为非运行状态，则重启所述心跳进程，若所述通信进程状态为非运行状态，则重启所述通信进程。
3.根据权利要求1所述的方法，其特征在于，所述通过预设的通信进程对所述目标服务节点与所述服务节点集群中各个所述服务节点的通信进行通信状态检测，得到通信状态检测结果，包括：
通过所述通信进程向所述服务节点集群中各个所述服务节点发送消息请求；
通过所述通信进程接收各个所述服务节点响应于所述消息请求发送的反馈信息；
如果接收到的所述反馈信息的第一数目大于未接收到的所述反馈信息的第二数目，则通信状态检测结果为通信成功；
如果接收到的所述反馈信息的第一数目小于或等于未接收到的所述反馈信息的第二数目，则通信状态检测结果为通信失败。
4.根据权利要求3所述的方法，其特征在于，多个服务节点为两个服务节点，所述基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移，包括：
若所述通信状态检测结果为通信失败，则对所述目标服务节点与网关之间的通信进行网路延迟状态检测，得到网络延迟状态检测结果；
基于所述实例状态检测结果和所述网络延迟状态检测结果对所述目标数据库实例进行故障转移。
5.根据权利要求1至4任一项所述的方法，其特征在于，所述通过预设的心跳进程对所述目标数据库实例进行实例状态检测，得到实例状态检测结果，包括：
获取所述目标数据库实例的心跳监测数据；
根据所述心跳监测数据和预设的故障检测逻辑规则进行故障检测，得到所述实例状态检测结果。
6.根据权利要求1至4任一项所述的方法，其特征在于，所述基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移，包括：
若所述实例状态检测结果为非运行状态、或所述通信状态检测结果为通信失败，确定所述目标数据库实例的角色；
若所述目标数据库实例的角色为主数据库实例，则解除所述目标数据库实例绑定的虚拟地址，重启或切换所述目标数据库实例。
7.根据权利要求6所述的方法，其特征在于，所述重启或切换所述目标数据库实例，包括：
确定所述数据库实例对应的磁盘的状态，得到磁盘状态；
若所述磁盘状态为磁盘故障，则切换所述目标数据库实例。
8.一种数据库的高可用管理装置，其特征在于，所述数据库的高可用管理装置应用于服务节点集群的多个服务节点中的目标服务节点，所述目标服务节点与目标数据库实例部署在同一个目标服务器，所述数据库的高可用管理装置包括：
实例状态检测模块，用于通过预设的心跳进程对所述目标数据库实例进行实例状态检测，得到实例状态检测结果；
通信状态检测模块，用于通过预设的通信进程对所述目标服务节点与所述服务节点集群中各个所述服务节点的通信进行通信状态检测，得到通信状态检测结果；
故障转移模块，用于基于所述实例状态检测结果和所述通信状态检测结果对所述目标数据库实例进行故障转移。
9.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的数据库的高可用管理方法。
10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的数据库的高可用管理方法。
CN202311668063.XA 2023-12-07 2023-12-07 数据库的高可用管理方法和装置、电子设备及存储介质 Pending CN117370316A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311668063.XA CN117370316A (zh) 2023-12-07 2023-12-07 数据库的高可用管理方法和装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311668063.XA CN117370316A (zh) 2023-12-07 2023-12-07 数据库的高可用管理方法和装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
CN117370316A true CN117370316A (zh) 2024-01-09

Family

ID=89393293

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311668063.XA Pending CN117370316A (zh) 2023-12-07 2023-12-07 数据库的高可用管理方法和装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN117370316A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117609194A (zh) * 2024-01-19 2024-02-27 中科泓泰电子有限公司 云数据库的处理方法、装置、电子设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112181660A (zh) * 2020-10-12 2021-01-05 北京计算机技术及应用研究所 一种基于服务器集群的高可用方法
US20210349795A1 (en) * 2020-05-05 2021-11-11 Capital One Services, Llc Automating the failover of a relational database in a cloud computing environment
CN115408370A (zh) * 2022-10-26 2022-11-29 本原数据(北京)信息技术有限公司 数据库迁移评估方法和系统、计算机设备、存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210349795A1 (en) * 2020-05-05 2021-11-11 Capital One Services, Llc Automating the failover of a relational database in a cloud computing environment
CN112181660A (zh) * 2020-10-12 2021-01-05 北京计算机技术及应用研究所 一种基于服务器集群的高可用方法
CN115408370A (zh) * 2022-10-26 2022-11-29 本原数据(北京)信息技术有限公司 数据库迁移评估方法和系统、计算机设备、存储介质

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
东城绝神: "MySQL高可用工具heartbeat简介_mysql 配置heartbeat 实现故障转移", pages 1 - 5, Retrieved from the Internet <URL:https://blog.csdn.net/m0_37814112/article/details/78652722> *
张莹;肖练刚;张继生;田丰;周华;: "一种航天光纤总线的交换单元热备份方法", 兵器装备工程学报, no. 01 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117609194A (zh) * 2024-01-19 2024-02-27 中科泓泰电子有限公司 云数据库的处理方法、装置、电子设备及存储介质

Similar Documents

Publication Publication Date Title
US10983880B2 (en) Role designation in a high availability node
CN106330475B (zh) 一种通信系统中管理主备节点的方法和装置及高可用集群
CN102355369B (zh) 虚拟化集群系统及其处理方法和设备
CN107480014B (zh) 一种高可用设备切换方法及装置
US9348706B2 (en) Maintaining a cluster of virtual machines
CN105933407B (zh) 一种实现Redis集群高可用的方法及系统
CN104408071A (zh) 一种基于集群管理器的分布式数据库高可用方法及系统
CN105229613A (zh) 协调分布式系统中的故障恢复
CN102360324B (zh) 故障恢复方法和用于故障恢复的设备
CN102394914A (zh) 集群脑裂处理方法和装置
CN117370316A (zh) 数据库的高可用管理方法和装置、电子设备及存储介质
WO2016180005A1 (zh) 处理虚拟机集群的方法和计算机系统
CN105554130A (zh) 基于分布式存储系统的NameNode切换方法和切换装置
CN103036719A (zh) 一种基于主备集群服务器的跨地区服务容灾方法及装置
WO2017071384A1 (zh) 报文处理的方法及装置
CN105824571A (zh) 一种实现数据无缝迁移的方法及装置
CN113377702B (zh) 两节点集群启动的方法及装置、电子设备和存储介质
CN113794765A (zh) 基于文件传输的网闸负载均衡方法及装置
CN115794769B (zh) 高可用数据库管理的方法、电子设备及存储介质
CN110351122B (zh) 容灾方法、装置、系统与电子设备
CN113596195B (zh) 公共ip地址管理方法、装置、主节点及存储介质
CN113890817A (zh) 一种通信优化方法和装置
CN115033428A (zh) 分布式数据库的管理方法、系统及管理服务器
CN112367386A (zh) 基于Ignite的自动化运维方法、装置及计算机设备
CN111064609A (zh) 消息系统的主从切换方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20240109