CN112486718A - 数据库故障自动切换方法、装置和计算机存储介质 - Google Patents

数据库故障自动切换方法、装置和计算机存储介质 Download PDF

Info

Publication number
CN112486718A
CN112486718A CN202011387011.1A CN202011387011A CN112486718A CN 112486718 A CN112486718 A CN 112486718A CN 202011387011 A CN202011387011 A CN 202011387011A CN 112486718 A CN112486718 A CN 112486718A
Authority
CN
China
Prior art keywords
library
server
database
slave
master library
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.)
Granted
Application number
CN202011387011.1A
Other languages
English (en)
Other versions
CN112486718B (zh
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.)
Shenzhen Yeahka Technology Co ltd
Original Assignee
Shenzhen Yeahka 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 Shenzhen Yeahka Technology Co ltd filed Critical Shenzhen Yeahka Technology Co ltd
Priority to CN202011387011.1A priority Critical patent/CN112486718B/zh
Priority claimed from CN202011387011.1A external-priority patent/CN112486718B/zh
Publication of CN112486718A publication Critical patent/CN112486718A/zh
Application granted granted Critical
Publication of CN112486718B publication Critical patent/CN112486718B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0775Content or structure details of the error report, e.g. specific table structure, specific error fields
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079Root cause analysis, i.e. error or fault diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Biomedical Technology (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Hardware Redundancy (AREA)

Abstract

本发明公开了一种数据库故障自动切换方法,包括以下步骤:当检测到主库所在的服务器出现故障时,进行故障切换;以及以下步骤的至少之一:在进行故障切换的同时调用关机API关闭主库服务器;对主库服务器中与写数据相关的操作进行阻止。本发明还公开了一种装置及计算机可读存储介质,解决了现有技术中还存在新旧主库同时存活时出现数据双写的情况,导致数据混乱的问题。

Description

数据库故障自动切换方法、装置和计算机存储介质
技术领域
本发明涉及数据库技术领域,尤其涉及一种数据库故障自动切换方法、装置和计算机存储介质。
背景技术
现有的MySQL数据库,有多种高可用管理方案,常用的主要有以下两种:
1、keepalive。该方案可以在主库宕机时切换到从库,但没法在数据库挂了而服务器正常存活的情况下进行切换。如果一个主库有多个从库,则没法把其它从库切换到新的主库进行主从复制。对于主从同步延迟所存在的数据不一致,也不会进行数据补全从而达到数据的一致性。
2、MHA。MHA是最常用的MySQL数据库高可用管理方案。MHA解决了keepalive的缺点,在数据库挂了而服务器存活的情况下可以切换,对有多个从库的情况也能把其它从库切换到新的主库进行主从同步,并补全数据,以使用数据保持一致性。MHA通常配合VIP(虚拟IP)来使用,以便切换后,应用无须修改主库地址配置重启便能把流量切换到新的主库。除了切换VIP,关机与发送通知等脚本需要自行开发外,MHA主要的缺点为,无法确保主库确实宕机了才切换。当判断错误时,就会出现新旧主库同时存活,出现了数据双写的情况,导致数据混乱。
因此,现有技术中还存在新旧主库同时存活时出现数据双写的情况,导致数据混乱的问题。
发明内容
本发明主要目的在于提供一种数据库故障自动切换方法、装置和计算机存储介质,旨在解决现有技术中还存在新旧主库同时存活时出现数据双写的情况,导致数据混乱的问题。
为实现上述目的,本发明提供一种数据库故障自动切换方法,所述数据库故障自动切换方法包括以下步骤:
当检测到主库所在的服务器出现故障时,进行故障切换;以及以下步骤的至少之一:
在进行故障切换的同时调用关机API关闭主库服务器;
对所述主库服务器中与写数据相关的操作进行阻止。
在一实施例中,检测主库所在的服务器是否出现故障,包括:
MHA管理节点实时检测主库服务器是否可达;
当检测到所述主库服务器不可达时,登录二次检查服务器再次检测所述主库服务器是否可达;
当所述二次检查服务器检测到所述主库服务器不可达时,则判定所述主库服务器出现故障。
在一实施例中,所述进行故障切换的步骤包括:
保存所述主库的二进制日志事件;
根据预设规则从预设数量的从库中选择出新主库;
从所述新主库中读取差异中继日志复制到剩余从库中;
将所述二进制日志事件复制到所述新主库中;
根据所述新主库中的数据对所述剩余从库进行补全数据操作,并切换为从新主库同步数据。
在一实施例中,根据预设规则从预设数量的从库中选择出新主库的步骤包括:
从预设数量的从库中选择含有最新数据的从库作为新主库。
在一实施例中,根据预设规则从预设数量的从库中选择出新主库的步骤包括:
预先从预设数量的从库中指定一个从库作为新主库。
在一实施例中,调用关机API关闭主库服务器的步骤包括:
MHA管理节点并发调用预设数量的关机API对所述主库服务器进行远程关机;
其中,多个关机API的关机操作是幂等的。
在一实施例中,所述对所述主库服务器中与写数据相关的操作进行阻止的步骤包括:
***进程根据预设时间间隔并发调用预设数量的健康检查服务的健康检查api进行通信健康检查;
当所述预设数量的健康检查服务的健康检查api在连续预设次数检查到所述***进程与外界通信失败时,则初步判定所述***进程处于网络孤岛的困境;
***进程断开所述主库服务器上所有数据库实例的连接,等待预设时间再检查是否有来自应用的连接;
当检查到没有来自应用的连接时,则最终判定所述***进程处于网络孤岛困境;
设置所述主库服务器上所有数据库实例为只读,不允许变更数据;
执行以下步骤,当某个动作执行失败则继续往下执行动作,直至有一个动作执行成功为止:
摘取所述主库服务器上的所有虚拟IP;
关闭所述主库服务器上所有数据库实例;
关闭所述主库服务器。
在一实施例中,还包括:
当所述故障切换完成后,发送故障切换结果通知。
为实现上述目的,本发明还提供一种装置,所述装置包括存储器、处理器以及存储在所述存储器并可在所述处理器上运行的数据库故障自动切换程序,所述数据库故障自动切换程序被所述处理器执行时实现如上所述的数据库故障自动切换方法的各个步骤。
为实现上述目的,本发明还提供一种计算机可读存储介质,所述计算机可读存储介质存储有数据库故障自动切换程序,所述数据库故障自动切换程序被处理器执行时实现如上所述的数据库故障自动切换方法的各个步骤。
本发明提供的数据库故障自动切换方法、装置和计算机存储介质,当MHA管理节点检测到主库服务器发生故障时,从从库中选择一个从库切换成新的主库,进行从新主从同步数据操作。在切换的同时MHA管理节点会调用关机API关闭原来的主库;同时还通过***进程对主库服务器的写数据相关的操作进行阻止;以上两个措施只要成功一个即可,当某一个措施失败但另一个措施成功时,还是能够达到目的,从而解决了现有技术中还存在新旧主库同时存活时出现数据双写的情况,导致数据混乱的问题。
附图说明
图1为本发明实施例涉及的装置结构示意图;
图2为本发明数据库故障自动切换方法的第一实施例的流程示意图;
图3为本发明数据库故障自动切换方法的第二实施例的流程示意图;
图4为本发明数据库故障自动切换方法的第三实施例的流程示意图;
图5为本发明数据库故障自动切换方法的第四实施例的流程示意图;
图6为本发明数据库故障自动切换方法的第五实施例的流程示意图。
具体实施方式
应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
本发明实施例的主要解决方案是:当检测到主库所在的服务器出现故障时,进行故障切换;以及以下步骤的至少之一:在进行故障切换的同时调用关机API关闭主库服务器;对主库服务器中与写数据相关的操作进行阻止。由于当MHA管理节点检测到主库服务器发生故障时,从从库中选择一个从库切换成新的主库,进行从新主从同步数据操作。在切换的同时MHA管理节点会调用关机API关闭原来的主库;同时还通过***进程对主库服务器的写数据相关的操作进行阻止;以上两个措施只要成功一个即可,当某一个措施失败但另一个措施成功时,还是能够达到目的,从而解决了现有技术中还存在新旧主库同时存活时出现数据双写的情况,导致数据混乱的问题。
作为一种实现方式,可以如图1所示,图1是本发明实施例方案涉及的装置结构示意图。
处理器1100可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器1100中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1100可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1200,处理器1100读取存储器1200中的信息,结合其硬件完成上述方法的步骤。
可以理解,本发明实施例中的存储器1200可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(Read Only Memory,ROM)、可编程只读存储器(Programmable ROM,PROM)、可擦除可编程只读存储器(Erasable PROM,EPROM)、电可擦除可编程只读存储器(Electrically EPROM,EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory,RAM),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用,例如静态随机存取存储器(Static RAM,SRAM)、动态随机存取存储器(Dynamic RAM,DRAM)、同步动态随机存取存储器(Synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(Double DataRate SDRAM,DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM,ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM,SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM,DRRAM)。本发明实施例描述的***和方法的存储器1200旨在包括但不限于这些和任意其它适合类型的存储器。
对于软件实现,可通过执行本发明实施例所述功能的模块(例如过程、函数等)来实现本发明实施例所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。
基于上述结构,提出本发明数据库故障自动切换方法的实施例。
参照图2,图2为本发明数据库故障自动切换方法的第一实施例,包括以下步骤:
步骤S110,当检测到主库所在的服务器出现故障时,进行故障切换。
在本实施例中,数据库故障自动切换主要是基于MHA的MySQL数据库高可用管理完成的,MHA(Master High Availability,主数据库高可用)是一款用于解决MySQL数据库故障切换的高可用解决方案,它由日本DeNA公司youshimaton开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。
MHA在应用时,其是由MHA Manager(管理节点)和MHA Node(数据节点)两个部分组成,其中MHA Manager管理节点作用是负责定期检测MySQL数据库集群中master(主库)节点的运行状态,在MHA应用中,master可以进行读和写数据操作,而slave(从库)只能进行读数据操作,MHA Manager只会监测master的运行情况。
MHA Manager:通常单独部署在一***立机器上管理多个master/salve集群,每个master/salve集群称为一个application(应用)。也可以部署在一台slave节点上。
MHA Node:运行在每台Mysql服务器之上/Master/slave/Manager,它通过监控具备解析和清理logs(日志)功能的脚本来加快故障转移。
所以当MHA Manager(管理节点)检测到主库所在的服务器出现故障时,故障包括主库服务器硬件发生故障和无法通过ssh(安全外壳协议)访问的网络故障。而网络故障又分为可恢复和不可恢复。则当MHA Manager(管理节点)检测到主库所在的服务器发生硬件故障和网络不可恢复故障时,MHA Manager(管理节点)会调用MHA主程序进行故障切换。
进行故障切换的步骤包括以下步骤:
步骤S111,保存所述主库的二进制日志事件。
在本实施中,MHA Node(数据节点)在主库服务器发生故障时即主库宕机时保存主库的二进制日志事件。
步骤S112,根据预设规则从预设数量的从库中选择出新主库。
在本实施例中,在MHA的应用中,可以从预设数量的从库中选择含有最新数据的从库作为新主库,例如,在MHA的应用中,包含一个主库和三个从库,主库的日志到102,而三个从库分别只收到了100、101、99时,主库出现了故障,MHA Node(数据节点)会识别每个从库的状态,选择日志最新的101对应的从库slave2作为新主库。还可以在预设数量的从库中预先指定一个从库作为新主库,例如,在MHA的应用中,包含一个主库和三个从库,预先指定第一个从库slave1作为新主库。
步骤S113,从所述新主库中读取差异中继日志复制到剩余从库中。
在本实施例中,从新主库中读取差异中继日志复制到剩余从库中,在此是优选将MHA与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志,MHA可以将最新的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节点的数据一致性。例如,根据上述slave2含有最新日志101,slave1为100,slave3日志为99,先将日志101复制到slave1中;将日志100、日志101复制到slave3中,保证了数据的一致性。
步骤S114,将所述二进制日志事件复制到所述新主库中。
在本实施例中,将从主库保存的二进制日志事件复制到新主库中,例如,根据上述主库服务器发生故障时主库的日志到102,当选择的新主库为slave2时,即将日志102复制到从库slave2中,当选择的新主库为slave1时,即将日志101、日志102复制到从库slave1中。
步骤S115,根据所述新主库中的数据对所述剩余从库进行补全数据操作,并切换为从新主库同步数据。
在本实施例中,根据新主库的数据对剩余从库进行补全数据操作,例如,将日志102复制到从库slave1和从库slave3中。将从库slave1和从库slave3指向新主库,进行从新主库同步数据操作。
以及以下步骤的至少之一:
步骤S120,在进行故障切换的同时调用关机API关闭主库服务器。
在本实施例中,在进行故障切换的同时MHA Manager(管理节点)通过mhafailover程序(故障切换程序)调用管理服务器中的关机API关闭主库服务器。
步骤S130,对所述主库服务器中与写数据相关的操作进行阻止。
在本实施例中,主库服务器中含有killmysql程序(***进程),当主库服务器发生故障时,killmysql程序会对主库服务器与写数据的相关操作进行阻止。
在本实施例提供的技术方案中,由于当MHA管理节点检测到主库服务器发生故障时,从从库中选择一个从库切换成新的主库,进行从新主从同步数据操作。在切换的同时MHA管理节点会调用关机API关闭原来的主库;同时还通过***进程对主库服务器的写数据相关的操作进行阻止;以上两个措施只要成功一个即可,当某一个措施失败但另一个措施成功时,还是能够达到目的,从而解决了现有技术中还存在新旧主库同时存活时出现数据双写的情况,导致数据混乱的问题。
参照图3,图3为本发明数据库故障自动切换方法的第二实施例,包括:
与第一实施例相比,第二实施例包含步骤S210,步骤S220,步骤S230,其他步骤与第一实施例相同,不再赘述。
步骤S210,MHA管理节点实时检测主库服务器是否可达。
在本实施例中,MHA管理节点实时检测主库服务器ssh(安全外壳协议)的数据是否可达,若主库服务器ssh的数据可达,则表明主库服务器正常工作;若主库服务器ssh的数据不可达,则可能的原因是主库服务器的硬件发生故障或者网络故障,造成主库宕机。
步骤S220,当检测到所述主库服务器不可达时,登录二次检查服务器再次检测所述主库服务器是否可达。
在本实施例中,当MHA管理节点检测到主库服务器ssh的数据不可达时,则通过MHA管理节点中的MHA主程序登录二次检查服务器再次检测主库服务器ssh的数据是否可达,若主库服务器ssh的数据可达,则第一次检测时出现了网络问题,现在已经恢复了;若主库服务器ssh的数据不可达,则可能的原因是主库服务器的硬件发生故障或者不可恢复的网络故障,造成主库宕机。
步骤S230,当所述二次检查服务器检测到所述主库服务器不可达时,则判定所述主库服务器出现故障,进行故障切换。
在本实施例中,当二次检查服务器检测到主库服务器ssh的数据不可达时,则判定主库服务器出现故障,造成主库宕机,进行故障切换。
以及以下步骤的至少之一:
步骤S240,在进行故障切换的同时调用关机API关闭主库服务器。
步骤S250,对所述主库服务器中与写数据相关的操作进行阻止。
在本实施例提供的技术方案中,通过MHA管理节点实时检测主库服务器是否可达,当第一次检测到主库服务器不可达时,则通过MHA管理节点中的MHA主程序登录二次检查服务器再次检测主库服务器是否可达,当二次检测到主库服务器不可达时,则判定主库服务器出现故障,造成主库宕机,进行故障切换。通过两次检测判断主库服务器是否可达,保证了判断的准确性,避免第一次检测判断错误时就直接进行故障切换。
参照图4,图4为本发明数据库故障自动切换方法的第三实施例,包括:
步骤S310,当检测到主库所在的服务器出现故障时,进行故障切换。
以及以下步骤的至少之一:
与第一实施例相比,第三实施例包含步骤S320,其他步骤与第一实施例相同,不再赘述。
步骤S320,MHA管理节点并发调用预设数量的关机API对所述主库服务器进行远程关机;其中,多个关机API的关机操作是幂等的。
在本实施例中,关机API服务(shutdownserver)提供以下功能:1、鉴权、检查用户密码是否正确,是否有权限查询管理IP,是否有权限关机;2、查询服务器的管理IP;3、远程关闭服务器。
每台数据库服务器都会部署getserverinfo程序(获取服务器的信息程序),该程序定时收集本机的IP与管理IP,查询CMDB数据库(配置管理数据库)中有没有存在本机IP与管理IP,如果不存在则***,如果存在则检查是否一致,不一致则更新CMDB中的记录。***与更新CMDB中的记录会发邮件与微信通知DBA(数据库管理员)。
关机API会定时全量拉取CMDB数据库服务器IP与管理IP对应关系,并缓存在本地。当收到查询管理IP或者关机请求时,会先从CMDB中查询管理IP,如失败则从本地缓存中取出管理IP。
收到查询管理IP或者关机请求时,会检验用户的密码与权限。检验成功,则执行请求,如收到关机请求,会取出管理IP,多个不同服务器分别部署关机API服务,通过MHA管理节点中的mhafailover程序(故障切换程序)同时并发调用所配置的所有关机API通过ipmi(智能管理平台接口)进行远程关机,其中,多个关机API的关机操作是幂等的。并且ipmi远程关机网络与数据库对外通信网络独立,数据库对外通信的网络故障时,ipmi的独立网络仍能与数据库所在服务器通信,从而能够远程关机。例如,优选含有3个关机API服务,防止单点故障关机不成功,只要三个中有一个API关机成功即可。
步骤S330,对所述主库服务器中与写数据相关的操作进行阻止。
在本实施例提供的技术方案中,通过MHA管理节点中的mhafailover程序(故障切换程序)同时并发调用所配置的所有关机API通过ipmi(智能管理平台接口)进行远程关机,其中,多个关机API的关机操作是幂等的。只要其中一个API关机成功就能达到关闭主库服务器的目的。
参照图5,图5为本发明数据库故障自动切换方法的第四实施例,包括:
步骤S410,当检测到主库所在的服务器出现故障时,进行故障切换。
步骤S420,在进行故障切换的同时调用关机API关闭主库服务器。
与第一实施例相比,第四实施例包含步骤S430,步骤S440,步骤S450,步骤S460,步骤S470,步骤S480,步骤S490,步骤S4100,其他步骤与第一实施例相同,不再赘述。
步骤S430,***进程根据预设时间间隔并发调用预设数量的健康检查服务的健康检查api进行通信健康检查。
在本实施例中,killmysql程序(***进程)提供以下功能:1、检查自己是否处于网络孤岛的困境;2、设置本机上所有MySQL为只读;3、摘取本机上所有的VIP(虚拟IP);4关闭本机上所有MySQL实例;5、shutdown(关闭)本机。
***进程killmysql根据预设时间间隔并发调用预设数量的健康检查服务(healthcheck服务)的健康检查api,每一轮都是并发请求所有的healthcheck服务的健康检查api,预设时间间隔可优选为3秒,预设数量可优选为3个,即配置3个healthcheck服务。
步骤S440,当所述预设数量的健康检查服务的健康检查api在连续预设次数检查到所述***进程与外界通信失败时,则初步判定所述***进程处于网络孤岛的困境。
在本实施例中,可优选为当3个健康检查服务的健康检查api在连续5次检查到killmysql程序(***进程)与外界通信失败时,则初步判定***进程处于网络孤岛的困境。
步骤S450,***进程断开所述主库服务器上所有数据库实例的连接,等待预设时间再检查是否有来自应用的连接。
在本实施例中,killmysql程序(***进程)断开主库服务器上所有数据库(MySQL)实例的连接,可优选为等待30秒再检查是否有来自应用的连接,如果有,则取消认定***进程处于网络孤岛的困境;如果没有,则最终认定自己处于网络孤岛的困境。
步骤S460,当检查到没有来自应用的连接时,则最终判定所述***进程处于网络孤岛困境。
在本实施例中,当预设时间内检查到***进程没有来自应用的连接时,则最终判定***进程处于网络孤岛的困境。
步骤S470,设置所述主库服务器上所有数据库实例为只读,不允许变更数据。
在本实施例中,MHA Manager(管理节点)设置主库服务器上所有数据库(MySQL)实例为只读,不允许变更数据。
执行以下步骤,当某个动作执行失败则继续往下执行动作,直至有一个动作执行成功为止:
步骤S480,摘取所述主库服务器上的所有虚拟IP。
在本实施例中,MHA Manager(管理节点)摘取主库服务器上的所有VIP(虚拟IP)。
步骤S490,关闭所述主库服务器上所有数据库实例。
在本实施例中,MHA Manager(管理节点)关闭主库服务器上所有数据库(MySQL)实例。
步骤S4100,关闭所述主库服务器。
在本实施例中,MHA Manager(管理节点)关闭主库服务器。
在本实施例提供的技术方案中,由于***进程根据预设时间间隔并发调用预设数量的健康检查服务的健康检查api进行通信健康检查;当预设数量的健康检查服务的健康检查api在连续预设次数检查到***进程与外界通信失败时,则初步判定***进程处于网络孤岛的困境;***进程断开主库服务器上所有数据库实例的连接,等待预设时间再检查是否有来自应用的连接;当检查到没有来自应用的连接时,则最终判定***进程处于网络孤岛困境;设置所述主库服务器上所有数据库实例为只读,不允许变更数据;执行以下步骤,当某个动作执行失败则继续往下执行动作,直至有一个动作执行成功为止:摘取主库服务器上的所有虚拟IP;关闭主库服务器上所有数据库实例;关闭主库服务器。通过以上步骤保证最大可能避免主库数据可写。
参照图6,图6为本发明数据库故障自动切换方法的第五实施例,包括:
步骤S510,当检测到主库所在的服务器出现故障时,进行故障切换。
步骤S520,在进行故障切换的同时调用关机API关闭主库服务器。
步骤S530,对所述主库服务器中与写数据相关的操作进行阻止。
与第一实施例相比,第五实施例包含步骤S540,其他步骤与第一实施例相同,不再赘述。
步骤S540,当所述故障切换完成后,发送故障切换结果通知。
在本实施例中,当故障切换步骤完成过后,可以通过邮件与微信等发送故障切换结果数据库管理员(DBA)。例如,根据上述,将从库slave2切换为新主库,从库slave1、从库slave3指向新主库slave2,将这个切换结果通过邮件与微信发送给数据库管理员。
在本实施例提供的技术方案中,当故障切换步骤完成过后,可以通过邮件与微信等发送故障切换结果数据库管理员(DBA)。数据库管理人员第一时间能够接收到故障切换结果,便于后续管理工作的进行。
本发明还提供一种装置,所述装置包括存储器、处理器以及存储在所述存储器并可在所述处理器上运行的数据库故障自动切换程序,所述数据库故障自动切换程序被所述处理器执行时实现如上所述的数据库故障自动切换方法的各个步骤。
本发明还提供一种计算机可读存储介质,所述计算机可读存储介质存储有数据库故障自动切换程序,所述数据库故障自动切换程序被处理器执行时实现如上所述的数据库故障自动切换方法的各个步骤。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
本领域内的技术人员应明白,本发明的实施例可提供为方法、***、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
应当注意的是,在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的部件或步骤。位于部件之前的单词“一”或“一个”不排除存在多个这样的部件。本发明可以借助于包括有若干不同部件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种数据库故障自动切换方法,其特征在于,所述数据库故障自动切换方法包括以下步骤:
当检测到主库所在的服务器出现故障时,进行故障切换;以及以下步骤的至少之一:
在进行故障切换的同时调用关机API关闭主库服务器;
对所述主库服务器中与写数据相关的操作进行阻止。
2.如权利要求1所述的数据库故障自动切换方法,其特征在于,检测主库所在的服务器是否出现故障,包括:
MHA管理节点实时检测主库服务器是否可达;
当检测到所述主库服务器不可达时,登录二次检查服务器再次检测所述主库服务器是否可达;
当所述二次检查服务器检测到所述主库服务器不可达时,则判定所述主库服务器出现故障。
3.如权利要求1所述的数据库故障自动切换方法,其特征在于,所述进行故障切换的步骤包括:
保存所述主库的二进制日志事件;
根据预设规则从预设数量的从库中选择出新主库;
从所述新主库中读取差异中继日志复制到剩余从库中;
将所述二进制日志事件复制到所述新主库中;
根据所述新主库中的数据对所述剩余从库进行补全数据操作,并切换为从新主库同步数据。
4.如权利要求3所述的数据库故障自动切换方法,其特征在于,根据预设规则从预设数量的从库中选择出新主库的步骤包括:
从预设数量的从库中选择含有最新数据的从库作为新主库。
5.如权利要求3所述的数据库故障自动切换方法,其特征在于,根据预设规则从预设数量的从库中选择出新主库的步骤包括:
预先从预设数量的从库中指定一个从库作为新主库。
6.如权利要求1所述的数据库故障自动切换方法,其特征在于,调用关机API关闭主库服务器的步骤包括:
MHA管理节点并发调用预设数量的关机API对所述主库服务器进行远程关机;
其中,多个关机API的关机操作是幂等的。
7.如权利要求1所述的数据库故障自动切换方法,其特征在于,所述对所述主库服务器中与写数据相关的操作进行阻止的步骤包括:
***进程根据预设时间间隔并发调用预设数量的健康检查服务的健康检查api进行通信健康检查;
当所述预设数量的健康检查服务的健康检查api在连续预设次数检查到所述***进程与外界通信失败时,则初步判定所述***进程处于网络孤岛的困境;
***进程断开所述主库服务器上所有数据库实例的连接,等待预设时间再检查是否有来自应用的连接;
当检查到没有来自应用的连接时,则最终判定所述***进程处于网络孤岛困境;
设置所述主库服务器上所有数据库实例为只读,不允许变更数据;
执行以下步骤,当某个动作执行失败则继续往下执行动作,直至有一个动作执行成功为止:
摘取所述主库服务器上的所有虚拟IP;
关闭所述主库服务器上所有数据库实例;
关闭所述主库服务器。
8.如权利要求1所述的数据库故障自动切换方法,其特征在于,还包括:
当所述故障切换完成后,发送故障切换结果通知。
9.一种装置,其特征在于,所述装置包括存储器、处理器以及存储在所述存储器并可在所述处理器上运行的数据库故障自动切换程序,所述数据库故障自动切换程序被所述处理器执行时实现如权利要求1-8任一项所述的数据库故障自动切换方法的各个步骤。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有数据库故障自动切换程序,所述数据库故障自动切换程序被处理器执行时实现如权利要求1-8任一项所述的数据库故障自动切换方法的各个步骤。
CN202011387011.1A 2020-11-30 数据库故障自动切换方法、装置和计算机存储介质 Active CN112486718B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011387011.1A CN112486718B (zh) 2020-11-30 数据库故障自动切换方法、装置和计算机存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011387011.1A CN112486718B (zh) 2020-11-30 数据库故障自动切换方法、装置和计算机存储介质

Publications (2)

Publication Number Publication Date
CN112486718A true CN112486718A (zh) 2021-03-12
CN112486718B CN112486718B (zh) 2024-07-30

Family

ID=

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114785762A (zh) * 2022-03-23 2022-07-22 深圳市飞泉云数据服务有限公司 云计算***的实现方法、装置、终端设备以及存储介质
CN117874145A (zh) * 2024-03-13 2024-04-12 连连(杭州)信息技术有限公司 一种主从数据库的强一致方法、装置、设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102194009A (zh) * 2011-06-09 2011-09-21 北京新媒传信科技有限公司 一种数据库托管方法和一种数据库托管平台***
CN103064860A (zh) * 2011-10-21 2013-04-24 阿里巴巴集团控股有限公司 数据库高可用实现方法及其装置
CN104036043A (zh) * 2014-07-01 2014-09-10 浪潮(北京)电子信息产业有限公司 一种mysql高可用的方法及管理节点
US9984140B1 (en) * 2015-02-05 2018-05-29 Amazon Technologies, Inc. Lease based leader election system
CN109871369A (zh) * 2018-12-24 2019-06-11 天翼电子商务有限公司 数据库切换方法、***、介质和装置
CN111400285A (zh) * 2020-03-25 2020-07-10 杭州浮云网络科技有限公司 mySQL数据分片处理方法、装置、计算机设备和可读存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102194009A (zh) * 2011-06-09 2011-09-21 北京新媒传信科技有限公司 一种数据库托管方法和一种数据库托管平台***
CN103064860A (zh) * 2011-10-21 2013-04-24 阿里巴巴集团控股有限公司 数据库高可用实现方法及其装置
CN104036043A (zh) * 2014-07-01 2014-09-10 浪潮(北京)电子信息产业有限公司 一种mysql高可用的方法及管理节点
US9984140B1 (en) * 2015-02-05 2018-05-29 Amazon Technologies, Inc. Lease based leader election system
CN109871369A (zh) * 2018-12-24 2019-06-11 天翼电子商务有限公司 数据库切换方法、***、介质和装置
CN111400285A (zh) * 2020-03-25 2020-07-10 杭州浮云网络科技有限公司 mySQL数据分片处理方法、装置、计算机设备和可读存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
刘钊等: "MySQL数据库故障转移工具MHA的研究与应用", 广西民族大学学报(自然科学版), vol. 18, no. 03, 30 September 2012 (2012-09-30), pages 62 - 65 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114785762A (zh) * 2022-03-23 2022-07-22 深圳市飞泉云数据服务有限公司 云计算***的实现方法、装置、终端设备以及存储介质
CN117874145A (zh) * 2024-03-13 2024-04-12 连连(杭州)信息技术有限公司 一种主从数据库的强一致方法、装置、设备及存储介质
CN117874145B (zh) * 2024-03-13 2024-05-28 连连(杭州)信息技术有限公司 一种主从数据库的强一致方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
RU2751551C1 (ru) Способ и устройство для восстановления нарушенной работоспособности узла, электронное устройство и носитель данных
US11194679B2 (en) Method and apparatus for redundancy in active-active cluster system
KR102145136B1 (ko) 데이터 처리 방법 및 장치
CN108958970B (zh) 一种数据恢复方法、服务器和计算机可读介质
CN104679611B (zh) 数据资源复制方法以及装置
CN109308227B (zh) 故障检测控制方法及相关设备
CN110807064A (zh) Rac分布式数据库集群***中的数据恢复装置
CN104036043A (zh) 一种mysql高可用的方法及管理节点
CN111355600B (zh) 一种主节点确定方法和装置
CN108600284B (zh) 一种基于Ceph的虚拟机高可用实现方法及***
CN110635941A (zh) 一种数据库节点集群故障迁移方法与装置
CN106021030A (zh) 一种数据库的***、一种处理数据库故障的方法及装置
CN111342986B (zh) 分布式节点管理方法及装置、分布式***、存储介质
CN108509296B (zh) 一种处理设备故障的方法和***
CN104184614B (zh) 一种配置回滚方法及装置
CN110858168A (zh) 集群节点故障处理方法、装置及集群节点
CN107291575B (zh) 一种数据中心故障时的处理方法和设备
CN112486718A (zh) 数据库故障自动切换方法、装置和计算机存储介质
CN108156203B (zh) 一种存储***及存储节点管理方法
CN112486718B (zh) 数据库故障自动切换方法、装置和计算机存储介质
CN113596195B (zh) 公共ip地址管理方法、装置、主节点及存储介质
CN115604088A (zh) 组件集群***的主备切换方法、装置、设备及存储介质
CN108628701B (zh) 缓存数据的保护方法及装置
CN114297182A (zh) 一种工业模型数据管理方法、装置、设备及可读存储介质
CN115686951A (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
GR01 Patent grant