CN117785568A - 一种双主双机热备方法及装置 - Google Patents
一种双主双机热备方法及装置 Download PDFInfo
- Publication number
- CN117785568A CN117785568A CN202410211880.0A CN202410211880A CN117785568A CN 117785568 A CN117785568 A CN 117785568A CN 202410211880 A CN202410211880 A CN 202410211880A CN 117785568 A CN117785568 A CN 117785568A
- Authority
- CN
- China
- Prior art keywords
- node
- fault
- standby
- main
- master
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 36
- 238000013515 script Methods 0.000 claims description 101
- 238000001514 detection method Methods 0.000 claims description 85
- 230000001360 synchronised effect Effects 0.000 claims description 50
- 230000005540 biological transmission Effects 0.000 claims description 30
- 230000008439 repair process Effects 0.000 claims description 27
- 230000002159 abnormal effect Effects 0.000 claims description 11
- 238000012544 monitoring process Methods 0.000 claims description 11
- 230000009977 dual effect Effects 0.000 claims description 9
- 230000008859 change Effects 0.000 claims description 7
- 238000011084 recovery Methods 0.000 abstract description 14
- 230000007246 mechanism Effects 0.000 abstract description 9
- 230000002829 reductive effect Effects 0.000 abstract description 8
- 230000010076 replication Effects 0.000 description 17
- 230000008569 process Effects 0.000 description 13
- 238000012423 maintenance Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000036961 partial effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 230000033001 locomotion Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Landscapes
- Hardware Redundancy (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种双主双机热备方法及装置，通过实时检测所有主节点的故障状态，可以及时发现主节点的故障，并进行故障切换。当主节点出现故障时，将其切换为备用节点，从而保证系统的持续可用性。这种方法可以极大地减少系统的宕机时间，提高系统的可靠性。且可以检测到多种机制检测节点的状态，识别出主节点可能出现的多种故障，并采用对应的解决方案来排除主节点的故障。从而减少系统的停机时间，提高故障恢复的速度，可以有效的保证数据同步的稳定性。
Description
技术领域
本发明涉及数据同步领域，尤其涉及一种双主双机热备方法及装置。
背景技术
MySQL双主数据库技术，也称为MySQL双主复制（MySQL Dual MasterReplication），是一种常用的高可用性和负载均衡解决方案。它允许两个MySQL数据库服务器都可以独立地处理读写请求，同时确保数据的实时同步，从而提供了数据的备份和故障切换机制。
现有技术常通过使用VRRP（虚拟路由器冗余协议）来实现自动故障切换，其中Keepalived是一种用于实现高可用性和负载均衡的开源软件。Keepalived可以检测到故障并在故障发生时自动将虚拟IP地址分配给另一个可用的服务器，从而确保系统的持续可用性。
但是在现有技术的双机热备份中仅依赖单一机制检测服务器的状态，在复杂的故障情况下，可能会导致服务器的故障识别不准确，从而导致数据同步出现错误。
发明内容
本发明提供了一种双主双机热备方法及装置，以解决现有技术中无法准确的识别服务器节点的故障导致数据同步出现错误的问题。
第一方面，本申请提供了一种双主双机热备方法，包括：
实时检测所有主节点的故障状态，当存在主节点出现故障时，判断出现故障节点的故障类型；
当所述故障类型为服务请求状态故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
当所述故障类型为节点数据传输故障时，则通过预设的修复命令进行连通性修复；
当所述故障类型为同步延迟故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，直至数据同步完成。
这样通过实时检测所有主节点的故障状态，可以及时发现主节点的故障，并进行故障切换。当主节点出现故障时，将其切换为备用节点，从而保证系统的持续可用性。这种方法可以极大地减少系统的宕机时间，提高系统的可靠性。且可以检测到多种机制检测节点的状态，识别出主节点可能出现的多种故障，并采用对应的解决方案来排除主节点的故障。从而减少系统的停机时间，提高故障恢复的速度，可以有效的保证数据同步的稳定性。
进一步地，所述实时检测所有主节点的故障状态，当存在主节点出现故障时，判断出现故障节点的故障类型，包括：
设置若干检测脚本和各个检测脚本对应的轮询间隔，每隔相应的轮询间隔执行对应的检测脚本；
当存在检测脚本检测到存在主节点出现故障时，根据对应的检测脚本确定故障节点的故障类型。
这样通过设置若干检测脚本和相应的轮询间隔，可以实时监测主节点的状态。当某个检测脚本检测到主节点出现故障时，可以立即进行处理，从而及时发现故障并采取相应的措施。这样可以减少故障的持续时间，提高系统的可用性。且每个检测脚本都对应一个特定的故障类型，当检测脚本检测到主节点故障时，可以根据对应的检测脚本确定故障节点的故障类型。这样可以精确地识别故障类型，为后续的故障处理提供指导和依据。同时设置若干检测脚本和轮询间隔，并根据检测脚本确定故障类型，可以实现故障检测和处理的自动化。系统可以根据预设的规则和脚本自动进行故障判断和处理，减少人工干预的需求，提高运维效率。
进一步地，所述将出现故障的主节点切换为备用节点，之后包括：
当将出现故障的主节点切换为备用节点时，停止所述故障的主节点向所有备用节点的数据同步；
其中，所述从所有备用节点选取无故障的节点切换为主节点后，通过切换后的主节点向所有备用节点进行数据同步。
这样当主节点发生故障时，切换为备用节点可以将故障隔离，防止故障影响整个系统的正常运行。停止故障主节点向备用节点的数据同步，可以避免故障数据被复制到备用节点，从而保证备用节点上的数据的完整性和一致性。同时选择一个无故障的备用节点切换为主节点后，可以快速恢复系统的正常运行。通过切换后的主节点向所有备用节点进行数据同步，可以确保备用节点上的数据与主节点保持同步，避免数据的不一致性。进一步地，通过切换后的主节点向所有备用节点进行数据同步，可以保证数据的一致性。当备用节点切换为主节点后，它会继续接收来自其他备用节点的数据同步请求，从而保持数据的实时同步。这样可以确保整个系统中的数据保持一致，避免数据的丢失或损坏。且通过切换后的主节点向所有备用节点进行数据同步，可以在故障恢复过程中及时恢复备用节点上的数据。一旦故障主节点恢复正常，它可以重新加入到数据同步的流程中，从而实现故障主节点的数据恢复。
进一步地，所述当所述故障类型为节点数据传输故障时，则通过预设的修复命令进行连通性修复，具体为：
实时向主节点发送检测命令，获得所述主节点数据反馈，并根据所述数据反馈判断所述主节点与备用节点之间的文件同步是否正常；
当所述主节点与备用节点之间的文件同步不正常时，通过预设的修复命令对主节点进行连通性修复，并同时对当前主节点的数据库进行备份。
这样通过实时向主节点发送检测命令并获取主节点数据反馈，可以判断主节点与备用节点之间的文件同步是否正常。如果文件同步不正常，预设的修复命令可以修复主节点与备用节点之间的连通性问题，从而恢复数据的传输。这样可以确保数据在主节点和备用节点之间的正常流动，避免数据的滞后或丢失。且通过实时向主节点发送检测命令并获取主节点数据反馈，可以判断主节点与备用节点之间的文件同步是否正常。如果文件同步不正常，可以确保数据在主节点和备用节点之间的正常流动，避免数据的滞后或丢失。进一步地，通过对主节点数据库进行备份，可以保护数据免受潜在的风险和损失。即使在修复过程中出现意外情况，备份的数据库可以作为数据的保护层，确保数据的安全性和可用性。
进一步地，所述当所述故障类型为同步延迟故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，直至数据同步完成，具体为：
通过预设的检测脚本，获取当前主节点向备用节点之间数据库同步的延迟时间，当所述延迟时间超过预设值时，确定所述主节点出现同步延迟故障，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
当所述数据库同步完成时，原主节点从备用节点切换为主节点，并将当前主节点切换为备用节点。
这样可以保证数据在主节点和备用节点之间的实时同步，避免数据的滞后和不一致。并且通过预设的检测脚本和切换规则，可以实现主备切换的自动化。系统可以根据预设的检测脚本判断同步延迟故障，并自动进行主备切换操作。这样可以减少人工干预的需求，提高故障恢复的速度和效率。
进一步地，所述将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，具体为：
当主节点出现故障时，释放当前主节点中预设的非抢占参数，将当前主节点切换为备用节点，并从所有备用节点中选取无故障的节点获取所述非抢占参数，将获得非抢占参数的备用节点设置为主节点。
这样将出现故障的主节点切换为备用节点可以隔离故障，防止故障影响整个系统的正常运行。通过释放当前主节点的非抢占参数，可以确保当前主节点不再参与主节点的选举过程，从而避免故障主节点再次被选为主节点。且从所有备用节点中选取无故障的节点获取非抢占参数，并将该节点设置为新的主节点，可以确保选举出的主节点是可靠的。这样可以避免故障主节点再次被选为主节点，保证系统的稳定性和可靠性。
进一步地，所述实时检测所有主节点的故障状态，之前包括：
利用inotify.sh脚本监控目标主节点中的数据变化，由rsync同步文件命令获取当前主节点向备用节点同步的同步数据，通过预设的命令排除所述同步数据中的数据库数据。
可以理解的是，通过预设的命令排除同步数据中的数据库数据，可以避免数据库数据在同步过程中被误传输或覆盖。这样可以保证数据库的完整性和可恢复性，避免数据的丢失或损坏。
第二方面，本申请提供了一种双主双机热备装置，包括：故障判断模块、服务请求模块、传输故障模块和延迟故障模块；
所述故障判断模块用于实时检测所有主节点的故障状态，当存在主节点出现故障时，判断出现故障节点的故障类型；
所述服务请求模块用于当所述故障类型为服务请求状态故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
所述传输故障模块用于当所述故障类型为节点数据传输故障时，则通过预设的修复命令进行连通性修复；
所述延迟故障模块用于当所述故障类型为同步延迟故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，直至数据同步完成。
进一步地，所述故障判断模块，包括：脚本单元和检测单元；
所述脚本单元用于设置若干检测脚本和各个检测脚本对应的轮询间隔，每隔相应的轮询间隔执行对应的检测脚本；
所述检测单元用于当存在检测脚本检测到存在主节点出现故障时，根据对应的检测脚本确定故障节点的故障类型。
进一步地，所述服务请求模块包括：数据同步单元；
所述数据同步单元用于当将出现故障的主节点切换为备用节点时，停止所述故障的主节点向所有备用节点的数据同步；
其中，所述从所有备用节点选取无故障的节点切换为主节点后，通过切换后的主节点向所有备用节点进行数据同步。
进一步地，所述传输故障模块包括：修复单元和备份单元；
所述修复单元用于实时向主节点发送检测命令，获得所述主节点数据反馈，并根据所述数据反馈判断所述主节点与备用节点之间的文件同步是否正常；
所述备份单元用于当所述主节点与备用节点之间的文件同步不正常时，通过预设的修复命令对主节点进行连通性修复，并同时对当前主节点的数据库进行备份。
进一步地，所述延迟故障模块包括：延迟单元和同步切换单元；
所述延迟单元用于通过预设的检测脚本，获取当前主节点向备用节点之间数据库同步的延迟时间，当所述延迟时间超过预设值时，确定所述主节点出现同步延迟故障，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
所述同步切换单元用于当所述数据库同步完成时，原主节点从备用节点切换为主节点，并将当前主节点切换为备用节点。
进一步地，所述服务请求模块包括：非抢占单元；
所述非抢占单元用于当主节点出现故障时，释放当前主节点中预设的非抢占参数，将当前主节点切换为备用节点，并从所有备用节点中选取无故障的节点获取所述非抢占参数，将获得非抢占参数的备用节点设置为主节点。
进一步地，所述故障判断模块之前包括：监控模块；
所述监控模块用于利用inotify.sh脚本监控目标主节点中的数据变化，由rsync同步文件命令获取当前主节点向备用节点同步的同步数据，通过预设的命令排除所述同步数据中的数据库数据。
这样通过实时检测所有主节点的故障状态，可以及时发现主节点的故障，并进行故障切换。当主节点出现故障时，将其切换为备用节点，从而保证系统的持续可用性。这种方法可以极大地减少系统的宕机时间，提高系统的可靠性。且可以检测到多种机制检测节点的状态，识别出主节点可能出现的多种故障，并采用对应的解决方案来排除主节点的故障。从而减少系统的停机时间，提高故障恢复的速度，可以有效的保证数据同步的稳定性。
附图说明
图1 ： 为本发明提供的一种双主双机热备方法的一种实施例的流程示意图；
图2： 为本发明提供的一种双主双机热备方法的一种具体流程示意图；
图3： 为本发明提供的一种双主双机热备装置的一种实施例的模块结构图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备（如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统）使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，“计算机可读介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。
可以理解的是，VRRP协议，全称Virtual Router Redundancy Protocol，中文名为虚拟路由冗余协议，VRRP的出现是为了解决静态路由的单点故障；VRRP是通过一种竞选协议机制来讲路由任务交给某台VRRP路由器的；VRRP是用过IP多播的方式（默认多播地址（224.0.0.18））实现高可用对之间通信的；工作时主节点发包，备用节点接包，当备用节点接收不到主节点发的数据包的时候，就启动接管程序接管主节点的资源。备用节点可以有多个，通过优先级竞选，但一般Keepalived系统运维工作中都是一对；VRRP使用了加密协议加密数据，但keepalived官方目前还是推荐使用铭文的方式配置认证类型和密码。
所述inotify是Linux操作系统内核中的一个子系统，用于监视文件系统事件。它可以追踪文件或目录的变化，例如文件的创建、修改、删除、移动等操作。inotify的主要作用是允许应用程序在文件系统事件发生时自动响应，而不需要定期地轮询文件状态。
所述rsync是一个用于文件同步和备份的开源工具。它可以在本地系统之间或本地和远程系统之间同步文件和目录。rsync通过比较源和目标文件的差异，只传输发生变化的部分，从而实现高效的文件同步和备份。
所述MTTR为系统故障发生后，系统恢复正常运行所需的平均时间。它是衡量系统可靠性和故障恢复能力的重要指标。MTTR包括了故障的发现时间、诊断时间、修复时间等，用于评估系统在发生故障后能够多快地恢复到正常工作状态。
所述keepalived的VIP是一种在网络环境中使用的特殊IP地址，为虚拟节点。与普通IP地址不同，VIP并不直接关联到任何具体的网络设备，而是可以动态地分配给网络中的多个设备中的一个，用于负载均衡、故障切换等应用场景。网页可持续通过VIP使用系统服务，而不是通过真实的服务器IP。在Keepalived中，VIP通常用于高可用性（HighAvailability）集群中，用于确保在集群中的主服务器（Master）发生故障时，能够快速切换到备用服务器（Backup）上，以实现服务的持续可用性。
实施例一
请参照图1，为本发明实施例提供的一种双主双机热备方法，包括步骤S1至步骤S4，各步骤具体如下：
在一实施例中，在步骤S1之前先进行数据库的双机构建和服务器的初始化步骤，所述数据库的双机构建和服务器的初始化步骤，包括但不限于：
在双机上搭建keepalived高可用组件集群，确定唯一的网络集群ID与虚拟节点VIP；
并在在双机上安装inotifywait用于监控项目文件变化，同时搭建rsync用于同步项目文件数据。
此处的双机为两个数据库，所述数据库数据采用MySQL的双机热备方案，对于文件同步采用rsync文件同步。
进一步地，搭建数据库双主集群，下载半同步复制插件，配置集群启用半同步复制。
其中，所述半同步复制为数据库集群增强型同步的一种方式，这种方式相较于异步复制（MySQL默认的复制方式）能够提高数据的可靠性。
半同步复制介于异步复制和同步复制之间。主库在提交事务时先等待，必须确认至少一个从库收到了事件（从库将事件写入relaylog，不需要重放和提交，并向主库发送一个确认信息ACK），主库收到确认信息后才会正式提交。
与同步复制相比，半同步复制速度快很多，因为半同步复制只需要至少1个从库确认写入中继日志（relaylog），并不需要完成在从库上的事务提交，同时又比异步复制更安全，因为主库在提交时，事务至少已经存在2个地方（主库的逻辑日志（binlog）和从库的relaylog）。
进一步地，为保持数据库双主集群的高一致性以及在异常宕机后数据能够恢复，设置写二进制日志的方式和策略，并同步集群服务器节点时间。
具体的，所述二进制日志的方式和策略的脚本代码为：sync_binlog=1，innodb_flush_log_at_trx_commit=1；
防火墙开放集群tcp端口号，并在hosts文件配置好另一台服务器节点IP与对应的主机名，保证集群节点之间可利用主机名解析从而绕过DNS解析进行网络加速访问通信。
优选地，检查并确认主备节点之间可以通信，比如在主节点使用ping命令去链接备用节点测试是否可以连接。
在本实施例中，修改双机Keepalived的配置文件，配置各个节点相同的优先级，并添加配置非抢占参数nopreempt，在双主模式中非抢占可以避免由于主备优先级地变化或另一台服务器地恢复导致的主备频繁切换。
在一可选的实施例中，当用户启用双机热备功能时，系统依赖VRRP协议，选择具有最高优先级的节点作为主节点，并在主节点上激活虚拟节点（VIP），以提供用户引用访问。需要特别注意的是，所有节点都必须配置为非抢占模式，即便在优先级高的节点完全恢复服务后，也不会抢占优先级较低节点上正在使用的资源，例如VIP。这种配置保障了用户体验的连续性和稳定性。
进一步地，设置rsync和keepalived开机自启。并重启服务器，保证双机热备服务正常运行。如图2为本实施例的具体流程示意图。
步骤S1：实时检测所有主节点的故障状态，当存在主节点出现故障时，判断出现故障节点的故障类型；
进一步地，所述实时检测所有主节点的故障状态，之前包括：
利用inotify.sh脚本监控目标主节点中的数据变化，由rsync同步文件命令获取当前主节点向备用节点同步的同步数据，通过预设的命令排除所述同步数据中的数据库数据。
优选地，在同步过程开始前，先行判断当前系统相关服务故障状态，可以降低当前节点向目标节点感染错误数据的概率。同时配置好一个rc-local.service系统服务用于在后台运行持续调用inotify.sh脚本。
其中所述持续调用inotify.sh脚本，在一实施例中的实现方式为：
根据rc-local.service这个服务，会在后台执行inotify.sh的特性，在后台一直运行inotify.sh脚本，并且inotify.sh脚本会一直卡在/usr/local/inotify/bin/inotifywait -mrq --timefmt'%d/%m/%y %H:%M'--format'%T %w%f%e'-e close_write,modify,delete,create,attrib,move $src_dir \ while read file 这个语句，这个语句会不停的循环检测$src_dir所指明的文件夹中是不是有修改，如果检测到有变动就会调用一次我们所写的rsync命令行，这个命令可以向另一台主机指定的文件夹同步文件，保证双机此文件夹文件完全一致。
在本实施例中，所述数据库数据采用双主同步，且采用MySQL的双机热备方案，通常是通过主从复制（Master-Slave Replication）来实现的，其中一个MySQL服务器充当主服务器支持数据的读写操作，另一个充当从服务器支持数据的读操作。
其中，所述数据库数据的同步方式包括主从同步和双主同步。
所述主从同步为主节点可读可写，从节点只读，同步方向是单向的，从主节点到从节点，这种方式简单可靠。
所述双主同步为同步方向是双向的，当一个主节点宕机的时候，另外一个主节点可以立即提供读写服务，保证服务不中断。
在文件同步方面，通过keepalived的notify通知主备执行特定脚本机制来自动控制主节点服务器对备用节点服务器的业务文件通过rsync单向同步。
其中，所述rsync的同步应用于本方法可以做到以下特点：
增量传输： rsync只传输文件的变化部分，而不是整个文件。这意味着在连续的同步过程中，只有文件的修改部分被传输，大大节省了带宽和时间。
部分传输和断点续传： rsync支持部分文件传输和断点续传，即使传输中断，也可以在中断处继续传输。
支持复制链接和设备文件： rsync能够正确地复制符号链接、硬链接和设备文件，保持目录结构的一致性。
支持匿名传输和加密传输： rsync支持匿名传输（无需身份验证）和加密传输，确保数据在传输过程中的安全性。
可以理解的是，这样通过预设的命令排除同步数据中的数据库数据，可以避免数据库数据在同步过程中被误传输或覆盖。这样可以保证数据库的完整性和可恢复性，避免数据的丢失或损坏。
进一步地，所述实时检测所有主节点的故障状态，当存在主节点出现故障时，判断出现故障节点的故障类型，包括：
设置若干检测脚本和各个检测脚本对应的轮询间隔，每隔相应的轮询间隔执行对应的检测脚本；
当存在检测脚本检测到存在主节点出现故障时，根据对应的检测脚本确定故障节点的故障类型。
其中，所述检测脚本包括服务请求状态检测脚本，节点数据传输检测脚本和同步延迟检测脚本。
这样通过设置若干检测脚本和相应的轮询间隔，可以实时监测主节点的状态。当某个检测脚本检测到主节点出现故障时，可以立即进行处理，从而及时发现故障并采取相应的措施。这样可以减少故障的持续时间，提高系统的可用性。且每个检测脚本都对应一个特定的故障类型，当检测脚本检测到主节点故障时，可以根据对应的检测脚本确定故障节点的故障类型。这样可以精确地识别故障类型，为后续的故障处理提供指导和依据。同时设置若干检测脚本和轮询间隔，并根据检测脚本确定故障类型，可以实现故障检测和处理的自动化。系统可以根据预设的规则和脚本自动进行故障判断和处理，减少人工干预的需求，提高运维效率。
步骤S2：当所述故障类型为服务请求状态故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
在本实施例中，采用所述服务请求状态检测脚本检测系统http服务请求状态是否健康的脚本(check_http.sh)，并配置相应轮询执行间隔。当服务请求状态检测脚本多次检测到失败的接口请求，则视为主节点的出现了服务请求状态故障，会调用exit 1异常退出，keepalived获得到所述异常退出会使得当前主节点抛弃掉虚拟节点和/或非抢占参数，完成主备的切换。且每次调用接口传递双机文件同步服务、双主集群连通性和keepalived服务的节点的故障数据，将所述故障数据保存到数据库双主集群，可提供web服务器前台运维人员实时查看的双机热备运行情况，并快速响应。
进一步地，所述将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，具体为：
当主节点出现故障时，释放当前主节点中预设的非抢占参数，将当前主节点切换为备用节点，并从所有备用节点中选取无故障的节点获取所述非抢占参数，将获得非抢占参数的备用节点设置为主节点。
进一步地，所述将出现故障的主节点切换为备用节点，之后包括：
当将出现故障的主节点切换为备用节点时，停止所述故障的主节点向所有备用节点的数据同步；
其中，所述从所有备用节点选取无故障的节点切换为主节点后，通过切换后的主节点向所有备用节点进行数据同步。
这样将出现故障的主节点切换为备用节点可以隔离故障，防止故障影响整个系统的正常运行。通过释放当前主节点的非抢占参数，可以确保当前主节点不再参与主节点的选举过程，从而避免故障主节点再次被选为主节点。且从所有备用节点中选取无故障的节点获取非抢占参数，并将该节点设置为新的主节点，可以确保选举出的主节点是可靠的。这样可以避免故障主节点再次被选为主节点，保证系统的稳定性和可靠性。
在一可选的实施例中，编写一个当备用节点切换到主节点会执行的切换主脚本；
所述切换主脚本会查看本机网络接口信息，判断备用节点是否存在虚拟网络节点和非抢占参数。当所述备用节点抢到虚拟网络节点和/或非抢占参数，则表明所述备用节点目前被keepalived设置成了主节点，会启动rc-local服务调用inotify.sh脚本向所有备用节点同步文件。
优选地，把所述切换主脚本加入到keepalived中的inotify_master（通知主节点的指令）主节点切换监控，每次被keepalived切换到主节点会执行所述切换主脚本开启文件同步。
其中，keepalived配置文件中的配置项inotify_master（通知主节点的指令）：这个配置选项允许你指定在Keepalived集群中的当前主节点（Master）状态发生变化时执行的命令或脚本。
在一可选的实施例中，编写一个切换到备用节点会执行的切换备脚本(close_inotify.sh)；
所述切换备脚本可以查看本机网络接口信息，匹配判断各个节点是否已经抢到了虚拟网络节点和/或非抢占参数；
当存在节点没抢到虚拟网络节点和/或非抢占参数时，确定所述节点目前被keepalived设置成了备用节点；
关闭rc-local服务停止所述备用节点向主节点同步文件。
优选地，将切换备脚本加入到keepalived中的inotify_backup（通知备用节点的指令），每次存在主节点被keepalived切换到备用节点会执行该脚本关闭文件同步。
其中，keepalived配置文件中的配置项inotify_backup（通知备用节点的指令）：这个配置选项则允许你指定在Keepalived集群中的当前备用节点（Backup）状态发生变化时执行的命令或脚本。
可以理解的是，停止故障主节点向备用节点的数据同步，可以避免故障数据被复制到备用节点，从而保证备用节点上的数据的完整性和一致性。同时选择一个无故障的备用节点切换为主节点后，可以快速恢复系统的正常运行。通过切换后的主节点向所有备用节点进行数据同步，可以确保备用节点上的数据与主节点保持同步，避免数据的不一致性。进一步地，通过切换后的主节点向所有备用节点进行数据同步，可以保证数据的一致性。当备用节点切换为主节点后，它会继续接收来自其他备用节点的数据同步请求，从而保持数据的实时同步。这样可以确保整个系统中的数据保持一致，避免数据的丢失或损坏。且通过切换后的主节点向所有备用节点进行数据同步，可以在故障恢复过程中及时恢复备用节点上的数据。一旦故障主节点恢复正常，它可以重新加入到数据同步的流程中，从而实现故障主节点的数据恢复。
步骤S3：当所述故障类型为节点数据传输故障时，则通过预设的修复命令进行连通性修复；
在本实施例中，采用所述节点数据传输检测脚本检测双主集群的连通性并进行修复，其中，修复脚本为fix_database.sh，且为节点数据传输检测脚本配置相应轮询执行间隔和优先级权重。
在本实施例中，所述当所述故障类型为节点数据传输故障时，则通过预设的修复命令进行连通性修复，具体为：
实时向主节点发送检测命令，获得所述主节点数据反馈，并根据所述数据反馈判断所述主节点与备用节点之间的文件同步是否正常；
当所述主节点与备用节点之间的文件同步不正常时，通过预设的修复命令对主节点进行连通性修复，并同时对当前主节点的数据库进行备份。
在一具体实施例中，所述节点数据传输检测脚本每次运行会获取当前节点与另一个节点数据库双主集群的连通性，通过在数据库交互环境中输入show slave status\G命令，检查输出结果中的Slave_IO_Running和Slave_SQL_Running参数，如果均为YES则说明当前节点正在健康的同步另一台节点的数据库数据，否则会通过常规的双主修复命令(如日志刷新、跳过冲突事务、重置中继日志等命令)对连通性进行修复，同时会对当前数据库进行备份，保证了主备快速切换的过程中，数据库集群的连通性和可用性。
所述节点数据传输检测脚本为用于keepalived的vrrp_script健康检查脚本。
其中，所述预设的修复命令为常规的双主修复命令(如日志刷新、跳过冲突事务、重置中继日志等命令)。
优选地，若常规的双主修复命令无法对连通性进行修复，则进行主备节点的切换，同时通知运维人员实时查看的双机热备运行情况，并快速响应。
这样通过实时向主节点发送检测命令并获取主节点数据反馈，可以判断主节点与备用节点之间的文件同步是否正常。如果文件同步不正常，预设的修复命令可以修复主节点与备用节点之间的连通性问题，从而恢复数据的传输。这样可以确保数据在主节点和备用节点之间的正常流动，避免数据的滞后或丢失。且通过实时向主节点发送检测命令并获取主节点数据反馈，可以判断主节点与备用节点之间的文件同步是否正常。如果文件同步不正常，可以确保数据在主节点和备用节点之间的正常流动，避免数据的滞后或丢失。进一步地，通过对主节点数据库进行备份，可以保护数据免受潜在的风险和损失。即使在修复过程中出现意外情况，备份的数据库可以作为数据的保护层，确保数据的安全性和可用性。
步骤S4：当所述故障类型为同步延迟故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，直至数据同步完成。
进一步地，所述当所述故障类型为同步延迟故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，直至数据同步完成，具体为：
通过预设的检测脚本，获取当前主节点向备用节点之间数据库同步的延迟时间，当所述延迟时间超过预设值时，确定所述主节点出现同步延迟故障，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
在一具体实施例中，所述同步延迟检测脚本，检查主节点数据库与备用节点的同步延迟情况(delay_database.sh)，并配置同步延迟检测脚本相应轮询执行间隔和优先级权重。
所述同步延迟检测脚本每次运行会获取当前节点与另一个节点数据库同步延迟，通过在数据库交互环境中输入show slave status\G命令，检查输出结果中的Seconds_Behind_Master参数。
所述Seconds_Behind_Master参数会显示当前数据库还需要同步另一台节点数据库延迟秒数。
所述同步延迟检测脚本通过判断延迟秒数是否大于一定值，当所述延迟秒数大于一定值时，选择将主节点抛弃虚拟节点使得重新切换成备用节点。
需要说明的是，双主集群的延迟问题一直是双主比较难以解决的问题，在半同步复制下，当节点断电很久重启后需要同步另一台节点的数据库数据就会产生较大延迟时间，这个延迟时间用来大致显示还需要同步多久才能恢复断电时的数据，此时如果这个节点延迟很大再写入事务，就会阻塞事务的进行，从而导致事务的回滚，影响系统的使用。
当所述数据库同步完成时，原主节点从备用节点切换为主节点，并将当前主节点切换为备用节点。
这样可以保证数据在主节点和备用节点之间的实时同步，避免数据的滞后和不一致。并且通过预设的检测脚本和切换规则，可以实现主备切换的自动化。系统可以根据预设的检测脚本判断同步延迟故障，并自动进行主备切换操作。这样可以减少人工干预的需求，提高故障恢复的速度和效率。
在一可选的实施例中，当存在故障状态无法在预定时间内自动修复，系统会发出警告，等待人工介入，确保问题得到解决。
其中，所述预定时间根据MTTR标准确定。
这样通过实时检测所有主节点的故障状态，可以及时发现主节点的故障，并进行故障切换。当主节点出现故障时，将其切换为备用节点，从而保证系统的持续可用性。这种方法可以极大地减少系统的宕机时间，提高系统的可靠性。且可以检测到多种机制检测节点的状态，识别出主节点可能出现的多种故障，并采用对应的解决方案来排除主节点的故障。从而减少系统的停机时间，提高故障恢复的速度，可以有效的保证数据同步的稳定性。
实施例二
请参照图3，为本发明实施例提供的一种双主双机热备装置，包括：故障判断模块210、服务请求模块220、传输故障模块230和延迟故障模块240；
所述故障判断模块210用于实时检测所有主节点的故障状态，当存在主节点出现故障时，判断出现故障节点的故障类型；
所述服务请求模块220用于当所述故障类型为服务请求状态故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
所述传输故障模块230用于当所述故障类型为节点数据传输故障时，则通过预设的修复命令进行连通性修复；
所述延迟故障模块240用于当所述故障类型为同步延迟故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，直至数据同步完成。
进一步地，所述故障判断模块210，包括：脚本单元和检测单元；
所述脚本单元用于设置若干检测脚本和各个检测脚本对应的轮询间隔，每隔相应的轮询间隔执行对应的检测脚本；
所述检测单元用于当存在检测脚本检测到存在主节点出现故障时，根据对应的检测脚本确定故障节点的故障类型。
进一步地，所述服务请求模块220包括：数据同步单元；
所述数据同步单元用于当将出现故障的主节点切换为备用节点时，停止所述故障的主节点向所有备用节点的数据同步；
其中，所述从所有备用节点选取无故障的节点切换为主节点后，通过切换后的主节点向所有备用节点进行数据同步。
进一步地，所述传输故障模块230包括：修复单元和备份单元；
所述修复单元用于实时向主节点发送检测命令，获得所述主节点数据反馈，并根据所述数据反馈判断所述主节点与备用节点之间的文件同步是否正常；
所述备份单元用于当所述主节点与备用节点之间的文件同步不正常时，通过预设的修复命令对主节点进行连通性修复，并同时对当前主节点的数据库进行备份。
进一步地，所述延迟故障模块240包括：延迟单元和同步切换单元；
所述延迟单元用于通过预设的检测脚本，获取当前主节点向备用节点之间数据库同步的延迟时间，当所述延迟时间超过预设值时，确定所述主节点出现同步延迟故障，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
所述同步切换单元用于当所述数据库同步完成时，原主节点从备用节点切换为主节点，并将当前主节点切换为备用节点。
进一步地，所述服务请求模块220包括：非抢占单元；
所述非抢占单元用于当主节点出现故障时，释放当前主节点中预设的非抢占参数，将当前主节点切换为备用节点，并从所有备用节点中选取无故障的节点获取所述非抢占参数，将获得非抢占参数的备用节点设置为主节点。
进一步地，所述故障判断模块210之前包括：监控模块；
所述监控模块用于利用inotify.sh脚本监控目标主节点中的数据变化，由rsync同步文件命令获取当前主节点向备用节点同步的同步数据，通过预设的命令排除所述同步数据中的数据库数据。
这样通过实时检测所有主节点的故障状态，可以及时发现主节点的故障，并进行故障切换。当主节点出现故障时，将其切换为备用节点，从而保证系统的持续可用性。这种方法可以极大地减少系统的宕机时间，提高系统的可靠性。且可以检测到多种机制检测节点的状态，识别出主节点可能出现的多种故障，并采用对应的解决方案来排除主节点的故障。从而减少系统的停机时间，提高故障恢复的速度，可以有效的保证数据同步的稳定性。
本装置更详细的工作原理和步骤流程可以但不限于参见实施例一。
以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步的详细说明，应当理解，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围。特别指出，对于本领域技术人员来说，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (10)
1.一种双主双机热备方法，其特征在于，包括：
实时检测所有主节点的故障状态，当存在主节点出现故障时，判断出现故障节点的故障类型；
当所述故障类型为服务请求状态故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
当所述故障类型为节点数据传输故障时，则通过预设的修复命令进行连通性修复；
当所述故障类型为同步延迟故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，直至数据同步完成。
2.根据权利要求1所述双主双机热备方法，其特征在于，所述实时检测所有主节点的故障状态，当存在主节点出现故障时，判断出现故障节点的故障类型，包括：
设置若干检测脚本和各个检测脚本对应的轮询间隔，每隔相应的轮询间隔执行对应的检测脚本；
当存在检测脚本检测到存在主节点出现故障时，根据对应的检测脚本确定故障节点的故障类型。
3.根据权利要求1所述双主双机热备方法，其特征在于，所述将出现故障的主节点切换为备用节点，之后包括：
当将出现故障的主节点切换为备用节点时，停止所述故障的主节点向所有备用节点的数据同步；
其中，所述从所有备用节点选取无故障的节点切换为主节点后，通过切换后的主节点向所有备用节点进行数据同步。
4.根据权利要求1所述双主双机热备方法，其特征在于，所述当所述故障类型为节点数据传输故障时，则通过预设的修复命令进行连通性修复，具体为：
实时向主节点发送检测命令，获得所述主节点数据反馈，并根据所述数据反馈判断所述主节点与备用节点之间的文件同步是否正常；
当所述主节点与备用节点之间的文件同步不正常时，通过预设的修复命令对主节点进行连通性修复，并同时对当前主节点的数据库进行备份。
5.根据权利要求1所述双主双机热备方法，其特征在于，所述当所述故障类型为同步延迟故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，直至数据同步完成，具体为：
通过预设的检测脚本，获取当前主节点向备用节点之间数据库同步的延迟时间，当所述延迟时间超过预设值时，确定所述主节点出现同步延迟故障，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
当所述数据库同步完成时，原主节点从备用节点切换为主节点，并将当前主节点切换为备用节点。
6.根据权利要求1所述双主双机热备方法，其特征在于，所述将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，具体为：
当主节点出现故障时，释放当前主节点中预设的非抢占参数，将当前主节点切换为备用节点，并从所有备用节点中选取无故障的节点获取所述非抢占参数，将获得非抢占参数的备用节点设置为主节点。
7.根据权利要求1所述双主双机热备方法，其特征在于，所述实时检测所有主节点的故障状态，之前包括：
利用inotify.sh脚本监控目标主节点中的数据变化，由rsync同步文件命令获取当前主节点向备用节点同步的同步数据，通过预设的命令排除所述同步数据中的数据库数据。
8.一种双主双机热备装置，其特征在于，包括：故障判断模块、服务请求模块、传输故障模块和延迟故障模块；
所述故障判断模块用于实时检测所有主节点的故障状态，当存在主节点出现故障时，判断出现故障节点的故障类型；
所述服务请求模块用于当所述故障类型为服务请求状态故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点；
所述传输故障模块用于当所述故障类型为节点数据传输故障时，则通过预设的修复命令进行连通性修复；
所述延迟故障模块用于当所述故障类型为同步延迟故障时，将出现故障的主节点切换为备用节点，并从所有备用节点选取无故障的节点切换为主节点，直至数据同步完成。
9.根据权利要求8所述双主双机热备装置，其特征在于，所述故障判断模块，包括：脚本单元和检测单元；
所述脚本单元用于设置若干检测脚本和各个检测脚本对应的轮询间隔，每隔相应的轮询间隔执行对应的检测脚本；
所述检测单元用于当存在检测脚本检测到存在主节点出现故障时，根据对应的检测脚本确定故障节点的故障类型。
10.根据权利要求8所述双主双机热备装置，其特征在于，所述服务请求模块包括：数据同步单元；
所述数据同步单元用于当将出现故障的主节点切换为备用节点时，停止所述故障的主节点向所有备用节点的数据同步；
其中，所述从所有备用节点选取无故障的节点切换为主节点后，通过切换后的主节点向所有备用节点进行数据同步。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410211880.0A CN117785568B (zh) | 2024-02-27 | 2024-02-27 | 一种双主双机热备方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410211880.0A CN117785568B (zh) | 2024-02-27 | 2024-02-27 | 一种双主双机热备方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117785568A true CN117785568A (zh) | 2024-03-29 |
| CN117785568B CN117785568B (zh) | 2024-07-16 |
Family
ID=90380119
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410211880.0A Active CN117785568B (zh) | 2024-02-27 | 2024-02-27 | 一种双主双机热备方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117785568B (zh) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104679604A (zh) * | 2015-02-12 | 2015-06-03 | 大唐移动通信设备有限公司 | 一种主节点和备节点切换的方法和装置 |
| CN105338078A (zh) * | 2015-10-26 | 2016-02-17 | 北京百度网讯科技有限公司 | 用于存储系统的数据存储方法和装置 |
| CN105956207A (zh) * | 2016-07-01 | 2016-09-21 | 杭州帕拉迪网络科技有限公司 | 一种基于binlog的可配置的mysql数据库实时同步方法 |
| CN108809681A (zh) * | 2017-05-04 | 2018-11-13 | 华为技术有限公司 | 一种核查数据一致性的方法、设备和系统 |
| CN109271280A (zh) * | 2018-08-30 | 2019-01-25 | 重庆富民银行股份有限公司 | 存储故障快速切换处理方法 |
| CN110659158A (zh) * | 2019-09-04 | 2020-01-07 | 苏州浪潮智能科技有限公司 | 基于双机热备环境的Influx DB数据备份方法 |
| CN114297296A (zh) * | 2021-12-27 | 2022-04-08 | 广州市保伦电子有限公司 | 一种广播用的服务器主备切换系统 |
| CN115509812A (zh) * | 2022-09-27 | 2022-12-23 | 广州市保伦电子有限公司 | 一种基于Keepalive双机热备的数据备份方法及服务器 |
| CN117076196A (zh) * | 2023-08-14 | 2023-11-17 | 京东科技信息技术有限公司 | 一种数据库容灾的管控方法和装置 |
| CN117240694A (zh) * | 2023-11-01 | 2023-12-15 | 广东保伦电子股份有限公司 | 一种基于keepalived的双机热备主备切换方法、装置及系统 |
-
2024
- 2024-02-27 CN CN202410211880.0A patent/CN117785568B/zh active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104679604A (zh) * | 2015-02-12 | 2015-06-03 | 大唐移动通信设备有限公司 | 一种主节点和备节点切换的方法和装置 |
| CN105338078A (zh) * | 2015-10-26 | 2016-02-17 | 北京百度网讯科技有限公司 | 用于存储系统的数据存储方法和装置 |
| CN105956207A (zh) * | 2016-07-01 | 2016-09-21 | 杭州帕拉迪网络科技有限公司 | 一种基于binlog的可配置的mysql数据库实时同步方法 |
| CN108809681A (zh) * | 2017-05-04 | 2018-11-13 | 华为技术有限公司 | 一种核查数据一致性的方法、设备和系统 |
| CN109271280A (zh) * | 2018-08-30 | 2019-01-25 | 重庆富民银行股份有限公司 | 存储故障快速切换处理方法 |
| CN110659158A (zh) * | 2019-09-04 | 2020-01-07 | 苏州浪潮智能科技有限公司 | 基于双机热备环境的Influx DB数据备份方法 |
| CN114297296A (zh) * | 2021-12-27 | 2022-04-08 | 广州市保伦电子有限公司 | 一种广播用的服务器主备切换系统 |
| CN115509812A (zh) * | 2022-09-27 | 2022-12-23 | 广州市保伦电子有限公司 | 一种基于Keepalive双机热备的数据备份方法及服务器 |
| CN117076196A (zh) * | 2023-08-14 | 2023-11-17 | 京东科技信息技术有限公司 | 一种数据库容灾的管控方法和装置 |
| CN117240694A (zh) * | 2023-11-01 | 2023-12-15 | 广东保伦电子股份有限公司 | 一种基于keepalived的双机热备主备切换方法、装置及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117785568B (zh) | 2024-07-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11163653B2 (en) | Storage cluster failure detection | |
| EP3285168B1 (en) | Disaster tolerance method and apparatus in active-active cluster system | |
| US7788524B2 (en) | Fault-tolerant networks | |
| US8661286B2 (en) | QProcessor architecture in a cluster configuration | |
| US8984330B2 (en) | Fault-tolerant replication architecture | |
| US8856592B2 (en) | Mechanism to provide assured recovery for distributed application | |
| CN108628717A (zh) | 一种数据库系统及监控方法 | |
| CN111460039A (zh) | 关系型数据库处理系统、客户端、服务器及方法 | |
| CN112380062A (zh) | 一种基于系统备份点多次快速恢复系统的方法及系统 | |
| US20150195167A1 (en) | Availability device, storage area network system with availability device and methods for operation thereof | |
| JP5285045B2 (ja) | 仮想環境における故障復旧方法及びサーバ及びプログラム | |
| US20190303233A1 (en) | Automatically Detecting Time-Of-Fault Bugs in Cloud Systems | |
| US7437445B1 (en) | System and methods for host naming in a managed information environment | |
| CN117240694A (zh) | 一种基于keepalived的双机热备主备切换方法、装置及系统 | |
| JP2006072684A (ja) | ストレージネットワークシステム及び管理サーバ、ホストとストレージ装置 | |
| CN117785568B (zh) | 一种双主双机热备方法及装置 | |
| KR20140140719A (ko) | 가상 머신 동기화 장치 및 시스템과 이를 이용한 장애 처리 방법 | |
| JP2011054033A (ja) | 監視制御装置 | |
| JPH07183891A (ja) | 計算機システム | |
| JP2004272318A (ja) | 系切り替えシステムおよびその処理方法並びにその処理プログラム | |
| CN110618951A (zh) | 系统高可用存储控制方法、装置、通信设备及存储介质 | |
| KR102695840B1 (ko) | 서버 이중화 시스템 및 그 동작 방법 | |
| JP7422492B2 (ja) | 冗長システム及びデータ同期方法 | |
| JP5870174B1 (ja) | データ送信システム | |
| CN117389799A (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 | ||
| GR01 | Patent grant |