数据库高可用实现方法及其装置.pdf

本申请涉及一种数据库高可用实现方法及其装置，该方法包括以下步骤：S1、设置心跳表子线程来判断主库的心跳表是否更新失败，设置备库子线程来判断备库是否可用，设置网关子线程来判断主库和备库分别所在服务器的网关是否可用；S2、设置主线程对心跳表子线程、备库子线程和网关子线程的判断结果进行循环检测，在心跳表子线程、备库子线程和网关子线程的判断结果均为是时继续步骤S3；S3、执行从主库到备库的切换。本申请将心跳表更新的成功与否作为判断数据库是否可用的标准；通过备库是否可用(备库延时是否满足要求，备库是否可以访问等等)作为备库是否可以用来切换的标准；通过对切换条件的灵活配置有效地控制主库和备库之间的切换。

权利要求书一种数据库高可用实现方法，应用于包括主库和备库的数据库中，该方法包括以下步骤：
S1、设置心跳表子线程来判断所述主库的心跳表是否更新失败，设置备库子线程来判断所述备库是否可用，设置网关子线程来判断所述主库和所述备库分别所在服务器的网关是否可用；
S2、设置主线程对所述心跳表子线程、所述备库子线程和所述网关子线程的判断结果进行循环检测，在所述心跳表子线程、所述备库子线程和所述网关子线程的判断结果均为是时继续步骤S3；
S3、执行从所述主库到所述备库的切换。
根据权利要求1所述的数据库高可用实现方法，所述步骤S1中判断所述主库的心跳表是否更新失败具体包括：
S111.检测所述主库是否可以访问，如果是则继续步骤S112，否则转步骤S114；
S112.按预设的心跳表更新时间间隔对所述主库的心跳表进行更新，如果在所述心跳表更新时间间隔内完成更新则转步骤S115，否则继续步骤S113；
S113.判断所述心跳表更新时间间隔内未完成更新的累积连续失败次数是否超过预设的心跳表更新连续失败次数，如果是则继续步骤S114，否则返回步骤S112；
S114.判断所述主库的心跳表更新失败；
S115.判断所述主库的心跳表更新成功。
根据权利要求1所述的数据库高可用实现方法，所述步骤S1中判断所述备库是否可用具体包括：
S121.检测所述备库是否可以访问，如果是则继续步骤S122，否则转步骤S124；
S122.检测所述备库中的数据是否与所述主库中的数据一致，如果是则继续步骤S123，否则转步骤S124；
S123.判断所述备库可用；
S124.判断所述备库不可用。
根据权利要求3所述的数据库高可用实现方法，所述步骤S124之后还包括：
S125.将所述备库中的数据与所述主库中的数据进行同步，之后返回步骤S122继续检测。
根据权利要求1所述的数据库高可用实现方法，所述步骤S1中判断所述主库和所述备库分别所在服务器的网关是否可用具体包括：
S131.按预设的检测网关时间间隔，分别对所述主库和所述备库所在服务器的网关是否可连通进行检测，如果是则继续步骤S132，否则转步骤S134；
S132.判断检测网关时间间隔内所述网关不可用的累积连续失败次数是否超过预设的网关不可用连续失败次数，如果否则继续步骤S133，否则转步骤S134；
S133.判断所述网关可用；
S134.判断所述网关不可用。
根据权利要求1所述的数据库高可用实现方法，所述步骤S1中还包括：设置外部命令子线程来判断是否接收到指示直接执行切换的外部命令；
所述步骤S2中还包括：所述主线程对所述外部命令子线程的判断结果进行循环检测，并在所述外部命令子线程的判断结果为是时继续所述步骤S3。
根据权利要求1所述的数据库高可用实现方法，所述步骤S3具体包括：
S311.关闭所述主库并启动所述备库；
S312.将所述主库所在服务器的IP赋给所述备库所在服务器。
一种数据库高可用实现装置，应用于包括主库和备库的数据库中，该装置包括主线程模块及切换模块，还包括：
心跳表子线程模块，用于判断所述主库的心跳表是否更新失败；
备库子线程模块，用于判断所述备库是否可用；
网关子线程模块，用于判断所述主库和所述备库分别所在服务器的网关是否可用；
所述主线程模块对所述心跳表子线程模块、所述备库子线程模块和所述网关子线程模块的判断结果进行循环检测，并且在所述心跳表子线程模块、所述备库子线程模块和所述网关子线程模块的判断结果均为是时通知所述切换模块执行从所述主库到所述备库的切换。
根据权利要求8所述的数据库高可用实现装置，其中，所述心跳表子线程模块包括：
主库访问检测单元，用于检测所述主库是否可以访问，如果不能访问则直接判断所述主库的心跳表更新失败；
主库更新单元，用于在所述主库访问检测单元检测到所述主库可以访问时，按预设的心跳表更新时间间隔对所述主库的心跳表进行更新，如果能够在所述心跳表更新时间间隔内完成更新，则判断所述主库的心跳表更新成功；以及
主库更新判断单元，用于判断所述心跳表更新时间间隔内未完成更新的累积连续失败次数是否超过预设的心跳表更新连续失败次数，如果是则判断所述主库的心跳表更新失败，否则通知所述主库更新单元继续进行更新。
根据权利要求8所述的数据库高可用实现装置，其中，所述备库子线程模块包括：
备库访问检测单元，用于检测所述备库是否可以访问，如果可以访问则判断所述备库可用，如果不可以访问则判断所述备库不可用；以及
备库数据判断单元，用于判断所述备库中的数据是否与所述主库中的数据一致，如果是则判断所述备库可用，如果否则判断所述备库不可用。
根据权利要求10所述的数据库高可用实现装置，其中，所述备库子线程模块还包括：
数据同步单元，用于将所述备库中的数据与所述主库中的数据进行同步，之后返回所述备库数据判断单元继续检测。
根据权利要求8所述的数据库高可用实现装置，其中，所述网关子线程模块还包括：
网关检测单元，用于按预设的检测网关时间间隔，分别对所述主库和所述备库所在服务器的网关是否可连通进行检测，如果是则判断所述网关可用，如果否则判断所述网关不可用；以及
网关更新判断单元，用于判断检测网关时间间隔内所述网关不可用的累积连续失败次数是否超过预设的网关不可用连续失败次数，如果否则判断所述网关可用，如果是则判断所述网关不可用。
根据权利要求8所述的数据库高可用实现装置，其中，所述装置还包括：外部命令子线程模块，用于判断是否接收到指示直接执行切换的外部命令；
所述主线程模块在所述循环检测中加入对所述外部命令子线程模块的判断结果的检测，并在所述外部命令子线程模块的判断结果为是时执行从所述主库到所述备库的切换。
根据权利要求8所述的数据库高可用实现装置，其中，所述切换模块包括：
上电下电单元模块，用于关闭所述主库并启动所述备库；以及
IP赋值单元，用于将所述主库所在服务器的IP赋给所述备库所在服务器。

说明书数据库高可用实现方法及其装置
技术领域
本申请涉及信息技术领域，尤其涉及一种数据库高可用实现方法及其装置。
背景技术
近年来，各行各业都利用计算机系统来提供及时可靠的信息和服务；但是，计算机硬件和软件都不可避免地会发生故障。一旦系统发生故障，便需要人工认定以及错误分析、测试和系统恢复。因此，系统故障可能导致系统较长时间的停顿，甚至整个服务的终止、网络的瘫痪，给企业带来难以估计的经济损失。由此可见，对一些行业(例如：网络服务商、金融机构、超市的POS系统服务器等)来说，系统的容错性和不间断性显得尤为重要。因此，必须采取适当的措施来确保计算机系统的不间断运行，即系统的高可用，这里，高可用性(High Availability)指的是通过尽量缩短因日常维护操作(计划)和突发的系统崩溃(非计划)所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。高可用性系统是目前企业防止核心计算机系统因故障停机的最有效手段。例如，当其中某一台服务器出现故障时，可将访问请求转移到其它可以正常工作的服务器上，这就保证了公司和企业的核心业务系统安全、高效的运行。
目前，行业内的高可用性软件主要有IBM的hacmp(高可用性集群多重处理)，HP的service guard，Veritas vcs等，从技术上来说，它们监控的层面都是主机；另外，这些传统的高可用工具也不会检测备库针对主库的延时。以hacmp为例，要判断其oracle是否可用，仅仅是查看一下oracle的进程是否存在，然而，这样的判断方式是不准确的，当oracle处于夯住(hang)状态时，hacmp是无法侦测到的。
发明内容
鉴于上述现有技术的缺陷，本申请的主要目的在于提供一种数据库高可用实现方法及其装置，以解决现有技术存在的上述问题。
为实现上述目的，本申请的实施例提供了一种数据库高可用实现方法，应用于包括主库和备库的数据库中，该方法包括以下步骤：S1、设置心跳表子线程来判断所述主库的心跳表是否更新失败，设置备库子线程来判断所述备库是否可用，设置网关子线程来判断所述主库和所述备库分别所在服务器的网关是否可用；S2、设置主线程对所述心跳表子线程、所述备库子线程和所述网关子线程的判断结果进行循环检测，在所述心跳表子线程、所述备库子线程和所述网关子线程的判断结果均为是时继续步骤S3；S3、执行从所述主库到所述备库的切换。
本申请的实施例还提供了一种数据库高可用实现装置，应用于包括主库和备库的数据库中，该装置包括主线程模块及切换模块，还包括：心跳表子线程模块，用于判断所述主库的心跳表是否更新失败；备库子线程模块，用于判断所述备库是否可用；网关子线程模块，用于判断所述主库和所述备库分别所在服务器的网关是否可用；所述主线程模块对所述心跳表子线程模块、所述备库子线程模块和所述网关子线程模块的判断结果进行循环检测，并且在所述心跳表子线程模块、所述备库子线程模块和所述网关子线程模块的判断结果均为是时通知所述切换模块执行从所述主库到所述备库的切换。
由上述技术方案可知，本申请将心跳表的更新的成功与否作为判断数据库是否可用的标准，使得在判断上更加准确；通过对切换条件的灵活配置可以有效地控制主库和备库之间切换的时间。
附图说明
图1为本申请数据库高可用实现方法的实施例流程图；
图2为本申请数据库高可用实现装置的实施例结构框图。
具体实施方式
下面将详细描述本申请的具体实施例。应当注意，这里描述的实施例只用于举例说明，并不用于限制本申请。
图1为本申请数据库高可用实现方法的实施例流程图。本实施例的数据库高可用实现方法用于实现主用数据库(下文中简称为主库)和备用数据库(下文中简称为备库)之间的切换，如图所示，所述方法包括以下步骤S1、S2和S3。
S1、设置心跳表子线程来判断所述主库的心跳表是否更新失败，设置备库子线程来判断所述备库是否可用，设置网关子线程来判断所述主库和所述备库分别所在服务器的网关是否可用。
之前提到的高可用程序(HA，例如：hacmp、service guard等)主要针对的是主机层面(例如：存储不可用、网络不可用等)，它具有通用性，但是对于数据库的高可用又缺乏针对性，例如，它判断主库是否健康的方式只是简单的查看oracle进程是否存在，如果oracle的进程夯住(即进程存在，但数据库无法提供服务)，hacmp将不能发起切换，所以，数据库的高可用软件需要有如下功能：
1.以数据库是否能够提供服务作为数据库是否健康的唯一标准；
2.切换之前需要检测备库是否具备可切换的条件；
3.能够第一时间发现高可用软件是否在健康工作。
在一个实施例中，本方法可以通过一个包括主线程及多个子线程的计算机程序来实现，其中，主线程和多个子线程均运行在监控机上，所述监控机可以为第三方服务器，所述主线程生成多个子线程，多个子线程分别完成对主库、备库、网关的对应检查后，主线程再通过获得每个子线程返回值来判断是否需要进行数据库主备切换；对应于本步骤，首先，判断主库的心跳表是否更新失败。
这里，心跳表即为数据库里的一张表，用于通过更新里面的某个字段来判断数据库监听器是否可用、数据库是否可用、是否有访问超时等。
在一个实施例中，主线程每隔一定的心跳表更新时间间隔update_interval会对心跳表检测子线程进行循环检测，并根据检测到的update_flag的值来判断主库是否可用；需要注意的是，判断主库可用的前提条件有两个，一是数据库可访问，二是心跳表可更新且更新未超时；这里，还需要特殊说明一下，若心跳表更新失败则需要根据配置文件来判断是否将update_flag的值置为“false”；当update_flag＝false时，表示主库不可用，此时可以进行切换；反之，当update_flag＝true时，则表示主库可用，此时不可以进行切换；在一个实施例中，心跳表更新时间间隔update_interval的值可以根据情况进行灵活配置，例如：可设置为2秒、10秒或30秒等等；在一个实施例中，当主库心跳表的更新超时update_timeout的值超过预设的心跳表更新时间间隔update_interval的值而不返回结果时则表示超时，认为更新主库心跳表的操作失败一次。
在一个实施例中，由于网络的抖动等原因，可能导致心跳表的某一次更新失败或者超时，然而，若仅凭这一次的失败就进行切换势必会导致在数据库状态的判断上的不准确；因此，可通过对心跳表的累积连续失败次数的判断来对数据库状态进行更加准确的判断；例如，当心跳表更新时间间隔内更新失败的累积连续失败次数超过update_error_alarm_count的值后会通过短信、邮件等方式开始报警；当累积连续失败次数超过update_error_count的值之后，再将update_flag的值置为“false”，即update_flag＝false，此时认为主库不可用；因此，通过这样的操作来对于数据库状态进行判断才是更加准确的；在一个实施例中，update_error_alarm_count的值和update_error_count的值可根据情况进行灵活配置的，例如：update_error_alarm_count的值可设置为3次、4次或6次等，update_error_count的值可设置为10次、16次或20次等；优选地，将update_error_alarm_count的值设置为小于update_error_count的值。
其次，判断备库是否可用。
在一个实施例中，主线程每隔一定的检测备库时间间隔check_standby_interval会对备库检测子线程进行循环检测，并根据检测到的check_standby_flag的值来判断备库是否可用；需要注意的是，判断备库可用的前提条件有两个，一是备库可访问，二是备库针对主库的延时没有超过检测备库阈值check_standby_threshold；这里所说的延时是指备库中的数据相对于主库中的数据所落后时间的长短，若备库落后主库太久，则说明备库的数据是陈旧的，那么在切换完成之后用户就访问不到自己所需的最新数据，也就是说，在切换完成之后相对用户而言，数据库还是不可用的，由于备库中的数据没有及时被更新，因此，用户不可能从备库中得到所需的最新数据；这里，还需要特殊说明一下，若检测备库可用，则将check_standby_flag的值置为“true”；进一步而言，当check_standby_flag＝true时，表示备库可用，此时可以进行切换；反之，当check_standby_flag＝false时，则表示备库不可用，此时不可以进行切换；在一个实施例中，检测备库时间间隔check_standby_interval的值可根据情况进行灵活配置，例如：可设置为2秒、10秒或30秒等等；在一个实施例中，若检测备库超时check_sandby_timeout的值超过预设的检测备库时间间隔check_sandby_interval的值而不返回结果则表示超时，认为检测备库是否可用的操作失败一次；需要注意的是，备库针对主库的延时不能超过检测备库阈值check_standby_threshold。
在一个实施例中，由于网络的抖动等原因，可能导致某一次的备库检测失败，然而，若仅凭这一次的失败就进行切换势必会导致在数据库状态的判断上的不准确；因此，可通过对检测备库的累积连续失败次数的判断来对数据库状态进行更加准确的判断；例如，当检测备库时间间隔内检测失败的累积连续失败次数超过check_standby_error_alarm_count的值后会通过短信、邮件等方式开始报警；当累积连续失败次数超过check_standby_error_count的值之后，再将check_standby_flag的值置为“false”，即check_standby_flag＝false，此时认为备库不可用；在一个实施例中，check_standby_error_alarm_count的值和check_standby_error_count的值可根据情况进行灵活配置的，例如：check_standby_error_alarm_count的值可设置为3次、4次或6次等，check_standby_error_count的值可设置为10次、16次或20次等；优选地，将check_standby_error_alarm_count的值设为小于check_standby_error_count的值。
在一个实施例中，如果检测到备库中的数据与主库中的数据不一致，则先要将备库中的数据与主库中的数据进行同步，之后再继续进行如上所述的检测，如果检测到备库中的数据与主库中的数据一致，则表示备库可用。
再次，判断主库和备库所在服务器的网关是否可用。
在一个实施例中，主线程每隔一定的检测网关时间间隔check_gateway_interval会对网关检测子线程进行循环检测，并根据检测到的ping_standby_flag的值来判断主库和备库所在服务器的网关是否可用；需要注意的是，判断网关可用的前提条件有两个，一是网关可连通，二是网关不可用的累积连续失败次数未超过预设的网关不可用连续失败次数；这里，还需要特殊说明一下，若检测网关可用，则将ping_standby_flag的值设置为“true”；具体而言，当ping_standby_flag＝false时，表示网关不可用，此时不可以进行切换；反之，当ping_standby_flag＝true时，则表示网关可用，此时可以进行切换；在一个实施例中，检测网关时间间隔check_gateway_interval的值可根据情况进行灵活配置，例如：可设置为5秒、10秒或30秒等等。
在一个实施例中，ping命令为DOS命令，可以检测任何一个用户是否与同一网段的其他用户连通，是否与其他网段的用户连接正常，同时还可以检测自己的IP地址是否与其他用户的IP地址发生冲突等等。
在一个实施例中，由于网络的抖动等原因，可能导致某一次的检测网关失败，然而，若仅凭这一次的失败就进行切换势必会导致在数据库状态的判断上的不准确；因此，可以通过对检测网关的累积连续失败次数的判断来对数据库状态进行更加准确的判断；例如，当检测网关时间间隔内检测失败的累积连续失败次数超过check_gateway_error_alarm_count的值之后会通过短信、邮件等方式开始报警；当累积连续失败次数超过check_gateway_error_count的值之后，再将ping_standby_flag的值置为“false”，即ping_standby_flag＝false，此时认为网关不可用；在一个实施例中，check_gateway_error_alarm_count的值和check_gateway_error_count的值可根据情况进行灵活配置，例如：check_gateway_error_alarm_count的值可设置为10次、18次或25次等，update_error_count的值可设置为50次、60次或70次等；优选地，将check_gateway_error_alarm_count的值设置为小于check_gateway_error_count的值。
S2、设置主线程对所述心跳表子线程、所述备库子线程和所述网关子线程的判断结果进行循环检测，在所述心跳表子线程、所述备库子线程和所述网关子线程的判断结果均为是时继续步骤S3。
在一个实施例中，主线程会循环获取各子线程的判断结果；当判断结果均为是时，则表示当前状态下主库不可用且备库可用、网关可访问，即，当满足update_flag＝false且check_standby_flag＝true、ping_standby_flag＝true的条件时会执行切换。
在一个实施例中，切换的前置条件(例如：备库是否可用、备库与主库的延时等)可以根据需要来进行灵活配置，从而有效地控制主库和备库之间切换的时间。
S3、执行从所述主库到所述备库的切换。
在一个实施例中，若满足上述切换条件，则会执行从所述主库到所述备库的切换，即将主库关闭备库打开。
在一个实施例中，上述切换也可以由程序员手动进行。
在一个实施例中，在切换完成后主线程还需对新主库的心跳表进行验证，并通过例如短信、邮件或日志等方式返回验证结果以告知程序员更新成功与否，若更新失败则需要通过程序员手动来进行检测；这里的更新验证方法也是可以根据实际情况来灵活配置的。
此外，上述步骤S1中还包括：通过sockect客户端直接和smartcluster(智能集群)主线程进行通讯，直接执行切换。在一个实施例中，对应于本步骤，需要判断从外部接收的命令是否为停止，如果是则根据接收到的指示直接执行切换的外部命令；表示用户已经从外部发送了switch(切换)命令给主线程，此时，主线程会直接停止每个子线程，待所有子线程推出后，主线程执行主库到备库的切换操作，即将主库关闭备库打开。
接续，上述步骤S2中还包括：所述主线程对所述socket监听子线程(用于接收外部命令)的返回进行循环检测，并在所述socket监听子线程的返回内容是“switch”时继续上述步骤S3。
接续，上述步骤S3具体包括：
首先，关闭所述主库并启动所述备库。
主线程会根据服务标签(service tag，这是服务器的一个唯一标识)获取主库所在服务器的带外管理IP，通过带外管理IP可以调用ipmi协议直接对主库下电，从而保证主库资源(例如：服务IP、共享存储等)全部被释放(通过ipmi协议可确认主库所在主机是否下电成功)即表示关闭主库操作成功。
在一个实施例中，通过运行ha_script脚本来启用备库，使其成为新主库；具体而言，首先，根据smartcluster配置文件中的standby_cmd配置项生成切换脚本，在原备库中运行例如recover、failover over等操作；其次，根据primary_cmd生成在新主库中运行的脚本。经过上述步骤，已经成功实现了从主库到备库的切换，也就是说，用户已经可以使用新主库(原备库)来读取数据等。
其次，将所述原主库所在服务器的服务IP赋给所述原备库(即新主库)所在服务器。
这里，服务IP是指在线上环境，应用会通过服务IP访问数据库，例如：主库服务器A的IP为192.168.0.1，备库服务器B的IP为192.168.0.2，服务IP为192.168.0.3；当主库是好的时候，服务IP在服务器A上，应用会通过服务IP192.168.0.3访问数据库，当发生问题切换之后，数据库切换到服务器B，为了做到对应用透明切换，需要把服务IP192.168.0.3赋到服务器B上，这样应用依然通过服务IP192.168.0.3访问数据库，但是实际上数据库已经切换到服务器B了。
在一个实施例中，当主库被关闭而备库被启动后，主线程会将原主库所在服务器的服务IP赋给备库所在服务器，赋值成功后，主线程会再发起一次对新主库的更新操作，如果更新操作成功，则表示切换成功，新主库可用，也就是说，用户可以从备库中读取所需的数据。
此外，在一个实施例中，当对心跳表和备库进行更新时可能存在某一时间间隔内更新成功，而另一时间间隔内更新失败或被夯住，但在下一时间间隔内又更新成功的情况，为了及时准确的监控数据库状态，需要对心跳表和备库更新中是否有夯住的僵尸数组进行判断；具体而言，例如，预先设置主线程每隔预定时间间隔(如30秒)会对主库心跳表发起一次更新检测，当检测失败的累积连续失败次数超过预设值后(如4次)开始报警，当累积连续失败次数超过极限值(如16次)后，将update_flag的值置为“false”，此时认为主库不可用；假设当预定时间间隔内检测失败的累积连续失败次数在第6次和第7次时均检测超时，此时由于进程处于夯住状态因而没有返回值；若当预定时间间隔内检测失败的累积连续失败次数在第8次时检测成功，则表示主库可用，此时会按照如上所述的步骤继续执行；因此，在预设值(如4次)到极限值(如16次)之间可能会有很多数组(即僵尸数组)被夯住，尽管这些被夯住的僵尸数组可能不会影响进程的执行，但对程序员来说还需要对这些僵尸数组进行监控，如果有被夯住的僵尸数组，则需执行下一步操作。
接续，在一个实施例中，如上所述，当有僵尸数组被夯住时需要对夯住的僵尸数组(例如：夯住数量等)进行存储及监控，并以日志的方式进行记录；当僵尸数组的数量达到或超过一定阈值时，系统便会通过短信、邮件、日志等方式进行报警，从而使程序员可以第一时间了解程序运行的情况，并根据日志记载的内容来及时对系统进行维护。
综上所述，本实施例的集群系统应用方法将心跳表的更新的成功与否作为判断数据库是否可用的标准，使得在判断上更加准确；通过对切换条件的灵活配置，例如提供多个配置项或根据需要设置多种切换的前置条件(例如：备用库是否可用、与主数据库的延时等)，可以有效地控制主库和备库之间切换的时间；在切换完成后还会对新主库进行更新操作，以判断切换是否成功；此外，本申请是采用Python语言来实现的，因此，不存在任何许可的问题。
图2为本申请数据库高可用实现装置的实施例结构框图。如图所示，本实施例的一种数据库高可用实现装置，应用于包括主库和备库的数据库中，该装置包括主线程模块11及切换模块12，还包括：心跳表子线程模块111，用于判断主库的心跳表是否更新失败；备库子线程模块112，用于判断备库是否可用；网关子线程模块113，用于判断主库和备库分别所在服务器的网关是否可用；主线程模块11对心跳表子线程模块111、备库子线程模块112和网关子线程模块113的判断结果进行循环检测，并且在心跳表子线程模块111、备库子线程模块112和网关子线程模块113的判断结果均为是时通知切换模块12执行从主库到备库的切换。
在一个实施例中，数据库高可用实现装置主要通过对心跳表子线程模块111、备库子线程模块112及网关子线程模块113的判断结果进行循环检测，并在判断结果均为是时通知切换模块12执行从主库到备库的切换。
具体而言，在一个实施例中，心跳表子线程模块111包括：主库访问检测单元1111，用于检测主库是否可以访问，如果不能访问则直接判断主库的心跳表更新失败；主库更新单元1112，用于在主库访问检测单元1111检测到主库可以访问时，按预设的心跳表更新时间间隔对主库的心跳表进行更新，如果能够在心跳表更新时间间隔内完成更新，则判断主库的心跳表更新成功；以及主库更新判断单元1113，用于判断心跳表更新时间间隔内未完成更新的累积次数是否超过预设的心跳表更新连续失败次数，如果是则判断主库的心跳表更新失败，否则通知主库更新单元1112继续进行更新。
在一个实施例中，心跳表子线程模块111每隔一定的心跳表更新时间间隔update_interval会对主库访问检测单元1111进行循环检测，并根据检测到的update_flag的值来判断主库是否可用；若心跳表更新失败则将update_flag的值置为“false”；当update_flag＝false时，表示主库不可用，此时可以进行切换；反之，当update_flag＝true时，则表示主库可用，此时不可以进行切换；在一个实施例中，心跳表更新时间间隔update_interval的值可以根据情况进行灵活配置，例如：可设置为2秒、10秒或30秒等等。
在一个实施例中，当判断主库可用时，主库更新单元1112会按预设的心跳表更新时间间隔对主库的心跳表进行更新。
在一个实施例中，由于网络的抖动等原因，可能导致心跳表的某一次更新失败或者超时，因此，需要通过主库更新判断单元1113来对在心跳表更新时间间隔内更新失败的累积次数是否超过预设的心跳表更新连续失败次数进行判断。例如，当心跳表更新时间间隔内更新失败的累积次数超过update_error_alarm_count的值后会通过短信、邮件等方式开始报警；当累积连续失败次数超过update_error_count的值之后，再将update_flag的值置为“false”，即update_flag＝false，此时认为主库不可用；在一个实施例中，update_error_alarm_count的值和update_error_count的值可根据情况进行灵活配置的，例如：update_error_alarm_count的值可设置为3次、4次或6次等，update_error_count的值可设置为10次、16次或20次等；优选地，将update_error_alarm_count的值设置为小于update_error_count的值。
接续，在一个实施例中，备库子线程模块112还包括：备库访问检测单元1121，用于检测备库是否可以访问，如果可以访问则判断备库可用，如果不可以访问则判断备库不可用；备库数据判断单元1122，用于判断备库中的数据是否与主库中的数据一致，如果是则判断备库可用，如果否则判断备库不可用。
在一个实施例中，备库访问检测单元1121每隔一定的检测备库时间间隔check_standby_interval会对备库进行循环检测，并根据检测到的check_standby_flag的值来判断备库是否可用；若检测备库可用，则将check_standby_flag的值置为“true”；进一步而言，当check_standby_flag＝true时，表示备库可用，此时可以进行切换；反之，当check_standby_flag＝false时，则表示备库不可用，此时不可以进行切换；在一个实施例中，检测备库时间间隔check_standby_interval的值可根据情况进行灵活配置，例如：可设置为2秒、10秒或30秒等等；在一个实施例中，若检测备库超时check_sandby_timeout的值超过预设的检测备库时间间隔check_sandby_interval的值而不返回结果则表示超时，认为检测备库是否可用的操作失败一次；需要注意的是，备库针对主库的延时不能超过检测备库阈值check_standby_threshold。
在一个实施例中，由于网络的抖动等原因，可能导致某一次的备库检测失败，因此，需要通过备库数据判断单元1122来对在检测备库时间间隔内更新失败的累积次数是否超过预设的备库更新连续失败次数进行判断；例如，当检测备库时间间隔内检测失败的累积连续失败次数超过check_standby_error_alarm_count的值后会通过短信、邮件等方式开始报警；当累积连续失败次数超过check_standby_error_count的值之后，再将check_standby_flag的值置为“false”，即check_standby_flag＝false，此时认为备库不可用；在一个实施例中，check_standby_error_alarm_count的值和check_standby_error_count的值可根据情况进行灵活配置的，例如：check_standby_error_alarm_count的值可设置为3次、4次或6次等，check_standby_error_count的值可设置为10次、16次或20次等；优选地，将check_standby_error_alarm_count的值设为小于check_standby_error_count的值。
在一个实施例中，备库子线程模块112还包括数据同步单元1123，用于将备库中的数据与主库中的数据进行同步，之后返回备库数据判断单元1122继续检测。
接续，在一个实施例中，网关子线程模块113还包括：网关检测单元1131，用于按预设的检测网关时间间隔，分别对主库和备库所在服务器的网关是否可连通进行检测，如果是则判断网关可用，如果否则判断网关不可用；以及网关更新判断单元1132，用于判断检测网关时间间隔内网关不可用的累积次数是否超过预设的网关不可用连续失败次数，如果否则判断网关可用，如果是则判断网关不可用。
在一个实施例中，网关检测单元1131每隔一定的检测网关时间间隔check_gateway_interval会对网关进行循环检测，并根据检测到的ping_standby_flag的值来判断主库和备库所在服务器的网关是否可用；若检测网关可用，则将ping_standby_flag的值设置为“true”；具体而言，当ping_standby_flag＝false时，表示网关不可用，此时不可以进行切换；反之，当ping_standby_flag＝true时，则表示网关可用，此时可以进行切换；在一个实施例中，检测网关时间间隔check_gateway_interval的值可根据情况进行灵活配置，例如：可设置为5秒、10秒或30秒等等。
在一个实施例中，由于网络的抖动等原因，可能导致某一次的检测网关失败，因此，需要通过网关更新判断单元1132来对在检测网关时间间隔内网关不可用的累积次数是否超过预设的网关不可用连续失败次数进行判断；例如，当检测网关时间间隔内检测失败的累积连续失败次数超过check_gateway_error_alarm_count的值之后会通过短信、邮件等方式开始报警；当累积连续失败次数超过check_gateway_error_count的值之后，再将ping_standby_flag的值置为“false”，即ping_standby_flag＝false，此时认为网关不可用；在一个实施例中，check_gateway_error_alarm_count的值和check_gateway_error_count的值可根据情况进行灵活配置，例如：check_gateway_error_alarm_count的值可设置为10次、18次或25次等，update_error_count的值可设置为50次、60次或70次等；优选地，将check_gateway_error_alarm_count的值设置为小于check_gateway_error_count的值。
接续，在一个实施例中，数据库高可用实现装置还包括：外部命令子线程模块13，用于判断是否接收到指示直接执行切换的外部命令；主线程模块11在循环检测中加入对外部命令子线程模块13的判断结果的检测，并在外部命令子线程模块13的判断结果为是时执行从主库到备库的切换。
在一个实施例中，外部命令子线程模块13主要有以下两个作用，一是在预设的时间间隔对判断结果进行循环检测，若接收到来自外部的命令(例如：停止、中止循环等)时，外部命令子线程模块13会进行判断，若判断从外部接收的命令为“停止”命令，则外部命令子线程模块13会将判断结果的值设置为“false”，此时，外部命令子线程模块13停止数据库高可用实现装置对其他子模块的检测，而直接执行从主库到备库的切换，即将主库关闭备库打开；二是实现进程通讯，即通过连接(socket)端口和外部进程进行通讯以实现远程管理。
接续，在一个实施例中，切换模块12包括：上电下电单元模块121，用于关闭主库并启动备库；以及IP赋值单元122，用于将主库所在服务器的IP赋给备库所在服务器。
在一个实施例中，由于并未给新主库(即原备库)分配相应的IP，因此主线程仍无法访问到新主库，故此时打开的备库是不可用的。为了真正实现从主库到备库的切换，接下来，上电下电单元模块121会对原主库是否真正被关闭进行检测，根据服务标签(service tag，这是服务器的一个唯一标识)获取主库所在服务器的带外管理IP，通过带外管理IP可以调用ipmi协议直接对主库下电，从而保证主库资源(例如：服务IP、共享存储等)全部被释放，当确认主库已经下电后，即表示关闭主库操作成功。
此外，在一个实施例中，上电下电单元模块121还会通过运行ha_script脚本来启用备库，使其成为新主库；具体而言，首先，根据sandby_cmd生成脚本，在原备库中运行例如recover、switch over等操作；其次，根据primary_cmd生成在新主库中运行的脚本。经过上述步骤，已经成功实现了从主库到备库的切换，也就是说，用户已经可以使用新主库(原备库)来读取数据等。
在一个实施例中，当确定主库被关闭而备库被启动后，IP赋值单元122会将原主库所在服务器的服务IP赋给备库所在服务器。
接续，在一个实施例中，数据库高可用实现装置还包括：僵尸数组判断模块(未示出)，用于判断在心跳表和备库更新中是否有夯住的僵尸数组；以及僵尸数组监控模块(未示出)，用于存储并监控在心跳表和备库更新中夯住的僵尸数组的数量。
在一个实施例中，僵尸数组判断模块会对心跳表和备库更新中夯住的僵尸数组进行判断；具体而言，例如，预先设置主线程模块11每隔预定时间间隔(如30秒)会对主库心跳表发起一次更新检测，当检测失败的累积连续失败次数超过预设值后(如4次)开始报警，当累积连续失败次数超过极限值(如16次)后，将update_flag的值置为“false”，此时认为主库不可用；假设当预定时间间隔内检测失败的累积连续失败次数在第6次和第7次时均检测超时，此时由于进程处于夯住状态因而没有返回值；若当预定时间间隔内检测失败的累积连续失败次数在第8次时检测成功，则表示主库可用，此时会按照如上所述的步骤继续执行；因此，在预设值(如4次)到极限值(如16次)之间可能会有很多数组(即僵尸数组)被夯住，尽管这些被夯住的僵尸数组可能不会影响进程的执行，但对程序员来说还需要对这些僵尸数组进行监控作。
接续，在一个实施例中，当有僵尸数组被夯住时，通过僵尸数组监控模块对夯住的僵尸数组(例如：夯住数量等)进行存储及监控，并以日志的方式进行记录；当僵尸数组的数量达到或超过一定阈值时，系统便会通过短信、邮件、日志等方式进行报警，从而使程序员可以第一时间了解程序运行的情况，并根据日志记载的内容来及时对系统进行维护。
由上述技术方案可知，本实施例的数据库装置相对于现有技术的集群系统具有结构简单、配置灵活等特点，通过各个模块之间的巧妙结合能够很容易地实现从主库到备库的自动切换。
虽然已参照典型实施例描述了本申请，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本申请能够以多种形式具体实施而不脱离发明的精神或实质，所以应当理解，上述实施例不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。