CN111124757A - 一种分布式事务数据库的数据节点心跳检测算法 - Google Patents
一种分布式事务数据库的数据节点心跳检测算法 Download PDFInfo
- Publication number
- CN111124757A CN111124757A CN201911361034.2A CN201911361034A CN111124757A CN 111124757 A CN111124757 A CN 111124757A CN 201911361034 A CN201911361034 A CN 201911361034A CN 111124757 A CN111124757 A CN 111124757A
- Authority
- CN
- China
- Prior art keywords
- library
- main
- storage node
- node
- distributed transaction
- 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
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 27
- 238000004422 calculation algorithm Methods 0.000 title claims abstract description 20
- 238000011084 recovery Methods 0.000 claims abstract description 13
- 238000004364 calculation method Methods 0.000 claims abstract description 4
- 230000007246 mechanism Effects 0.000 claims description 21
- 230000000593 degrading effect Effects 0.000 claims description 3
- 230000001960 triggered effect Effects 0.000 claims description 3
- 238000012423 maintenance Methods 0.000 claims description 2
- 238000012544 monitoring process Methods 0.000 claims description 2
- 239000012634 fragment Substances 0.000 description 5
- 238000000034 method Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000010076 replication Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000003339 best practice Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
Images
Classifications
-
- 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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
-
- 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/23—Updating
- G06F16/2308—Concurrency control
-
- 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/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- 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/24—Querying
- G06F16/242—Query formulation
- G06F16/2433—Query languages
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Computational Linguistics (AREA)
- Mathematical Physics (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种分布式事务数据库的数据节点心跳检测算法,步骤如下:步骤1、分布式事务数据库计算节点的存储节点主库和存储节点备库上有一张心跳检测表heartbeat;步骤2、分布式事务数据库计算节点的计算节点主服务,默认设置每隔1秒钟向存储节点主库发送一条UPDATE操作判断是否能正常数据访问服务;步骤3、当分布式事务数据库计算节点的计算节点主服务发送给存储节点主库的第一条UPDATE操作在默认设置的间隔1秒内未得到返回结果;步骤4、分布式事务数据库计算节点的计算节点主服务降级当下的存储节点主库为故障状态;步骤5、存储节点主库和存储节点备库之间的故障恢复完毕。本发明能够保障数据服务的可用性以及保障数据安全的可靠性得到较大的提高。
Description
技术领域
本发明涉及信息技术领域,特别涉及一种分布式事务数据库的数据节点心跳检测算法。
背景技术
随着信息技术的快速发展,信息系统数据库中的数据量越来越大。为了满足大数据量的存储需求,在多台服务器上运行的分布式存储系统得到了广泛的应用。在分布式存储系统中,多台服务器上分别运行了多个数据库系统。数据进行存储时,需要先将数据进行分片(sharding),再将不同的数据分片交由不同的服务器进行存储。分片是一种水平扩展(horizontal scaling)的方式,把一个大的数据集分散到多个数据节点上,所有的数据节点将组成一个逻辑上的数据库来存储这个大的数据集。分片对用户(应用层)是透明的,用户不会知道数据很被存放到哪个片服务器上。采用数据分片进行数据存储,可以突破单节点服务器的I/O能力限制,解决数据库拓展性的问题。
同时,为了保证数据和服务的高可用性,往往需要为分布式数据库提供必要的容错机制,对各个数据分片进行冗余备份。通过将同一数据分片的多个副本存储在不同的服务器上,可以避免由于单个服务器不可用时造成的数据分片丢失。
但是目前的数据服务的可用性以及数据安全的可靠性较低,难以满足使用的要求。
发明内容
本发明的目的在于提供一种分布式事务数据库的数据节点心跳检测算法,保障数据服务的可用性达到99.99%,保障数据安全的可靠性达到99.99%及以上,以解决上述背景技术中提出的问题。
为实现上述目的,本发明提供如下技术方案:
一种分布式事务数据库的数据节点心跳检测算法,包括如下步骤:
步骤1、分布式事务数据库计算节点的存储节点主库和存储节点备库上有一张心跳检测表heartbeat,各自有一条数据代表主库和备库;
步骤2、分布式事务数据库计算节点的计算节点主服务,默认设置每隔1秒钟(可根据网络环境自定义时间)向存储节点主库发送一条UPDATE操作判断是否能正常数据访问服务;
步骤3、当分布式事务数据库计算节点的计算节点主服务发送给存储节点主库的第一条UPDATE操作在默认设置的间隔1秒内未得到返回结果;
步骤4、分布式事务数据库计算节点的计算节点主服务降级当下的存储节点主库为故障状态,提升当下的存储节点备库为主库,确保存储节点备库上的中继日志全部解析执行完毕后,解除存储节点数据访问的HOLD住功能,将数据访问操作发往新的存储节点主库;
步骤5、至此,存储节点主库和存储节点备库之间的故障恢复完毕,待故障的存储节点主库服务恢复正常后,分布式事务数据库计算节点的计算节点主服务会自动检测到和降级曾经故障的存储节点主库为备库。
进一步地,步骤3包括如下步骤:
第一步:计算节点主服务发送第二条UPDATE操作给存储节点主库,在默认设置的间隔500毫秒内未得到返回结果,则触发计算节点主服务对该存储节点主库的数据访问请求HOLD住机制;
第二步:计算节点主服务同时向存储节点主库和存储节点备库发送UPDATE操作,在默认设置的间隔10毫秒内未得到存储节点主库返回结果,且存储节点备库返回结果,则触发存储节点主库和存储节点备库见的数据服务切换机制。
进一步地,用户可根据自身网络状态进行监测时间配置,适应自身网络环境不产生误判情况。
进一步地,单个存储节点的服务故障及恢复过程对应用程序端透明。
进一步地,分布式事务数据库计算节点的内置算法检测、判断和决策。
进一步地,中间件的主备库常规部署方式为双主在线热备,中间件服务的运行状态由KEEPALIVED软件自动检测,采用特殊定制的脚本以固定频率进行检测和判断是否存在故障,无需引入外部程序进行控制,减少运维风险。
与现有技术相比,本发明的有益效果是:本发明HotDB具有中间件服务、数据源、配置库的高可用及切换机制。有完善的心跳检测机制、故障切换对数据源同步追平判断机制、全局自增序列在故障时自动跳号机制、且可以通过Hold住功能避免业务在数据切换过程中受到影响,MySQL数据库服务多采用在线双主或双主多从架构部署,中间件服务程序实施MySQL数据库服务的高可用检测算法控制,数据节点的数据源故障对应用程序端透明,故障判断及切换服务恢复的总时长小于3秒,故障发生至切换成功(含数据追平)实测在1.8秒-2.2秒之间,保障数据服务的可用性达到99.99%,保障数据安全的可靠性达到99.99%及以上。
附图说明
图1为本发明的集群概览图;
图2为本发明的相应的架构演示效果图;
图3为本发明的详细架构演示效果图;
图4为本发明的HotDB数据节点心跳逻辑图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
一种分布式事务数据库的数据节点心跳检测算法,包括如下步骤:
步骤1、分布式事务数据库计算节点的存储节点主库和存储节点备库上有一张心跳检测表heartbeat,各自有一条数据代表主库和备库;
步骤2、分布式事务数据库计算节点的计算节点主服务,默认设置每隔1秒钟向存储节点主库发送一条UPDATE操作判断是否能正常数据访问服务;
步骤3、当分布式事务数据库计算节点的计算节点主服务发送给存储节点主库的第一条UPDATE操作在默认设置的间隔1秒内未得到返回结果。第一步:计算节点主服务发送第二条UPDATE操作给存储节点主库,在默认设置的间隔500毫秒内未得到返回结果,则触发计算节点主服务对该存储节点主库的数据访问请求HOLD住机制;第二步:计算节点主服务同时向存储节点主库和存储节点备库发送UPDATE操作,在默认设置的间隔10毫秒内未得到存储节点主库返回结果,且存储节点备库返回结果,则触发存储节点主库和存储节点备库见的数据服务切换机制;
步骤4、分布式事务数据库计算节点的计算节点主服务降级当下的存储节点主库为故障状态,提升当下的存储节点备库为主库,确保存储节点备库上的中继日志全部解析执行完毕后,解除存储节点数据访问的HOLD住功能,将数据访问操作发往新的存储节点主库;
步骤5、至此,存储节点主库和存储节点备库之间的故障恢复完毕,待故障的存储节点主库服务恢复正常后,分布式事务数据库计算节点的计算节点主服务会自动检测到和降级曾经故障的存储节点主库为备库。
HotDB采用keepalived检测技术保证HotDB-Server服务的高可用,并控制主备之间故障切换。可通过管理平台对已经搭建完成的HotDB高可用集群进行主备切换,也可以在HotDB高可用发生故障切换之后,重建高可用关系,保证下次故障可正常切换。经测试HotDB的故障判断及切换服务恢复总时长小于7秒,最佳实践是5秒左右。
HotDB具有中间件服务、数据源、配置库的高可用及切换机制。有完善的心跳检测机制、故障切换对数据源同步追平判断机制、全局自增序列在故障时自动跳号机制、且可以通过Hold住功能保障数据一致性。
HotDB-Server提供数据节点内的MySQL高可用,当主数据源不可用时,HotDB将自动切换到优先级最高的备数据源上,且保证主从数据同步追平;若要使用数据节点高可用,必须在数据节点内配置主从数据源与故障切换,并在HotDB-Server中开启心跳功能。MySQL同步模式上HotDB支持普通Replication与MGR(MySQL Group Replication)模式。
HotDB支持配置库高可用功能,防止配置库实例出现故障,HotDB无法正常提供服务且故障信息也无法记入配置库的问题,同时辅助提升HotDB的高可靠性。同时,HotDB管理平台首页大屏中可以直观看到集群的年度故障恢复时间,当前可用性为100%。集群概览如图1。
HotDB提供底层数据源和配置库的高可用。
底层数据源通常配置双主热备模式,通过中间件高可用实现主备高可用,当主数据库出现异常,自动切换到备数据库,支持MGR(MySQL Group Replication)高可用。
配置库数据实现主备高可用,防止配置库不可用时,整个HotDB-Server配置的参数无法获取而无法正常提供服务。
HotDB具备前端连接限制和后端并发限制,对前端连接数总数和用户连接数进行限制,当连接数超过限制时拒绝连接操作并给出错误提示;对后端执行的DML\DDL\COMMIT\ROLLBACK\SHOW\PROCESSLIST\STATUS\SELECT\INFORMATION_SCHEMA等SQL语句进行并发控制;控制HotDB发往数据源执行的SQL并发量,保护数据源之间负载平衡,防止某一个数据源因压力过大而宕机。
HotDB支持自动重连等机制,当出现例如网络中断时MySQL连接断开时,HotDB会通过自动重连MySQL数据库进行故障自动恢复,且重连时间非常短,对业务无影响。
HotDB提供中间件的主备故障自动切换和底层数据库的主备故障自动切换。中间件的主备库常规部署方式为双主在线热备,中间件服务的运行状态由KEEPALIVED软件自动检测,采用特殊定制的脚本以固定频率进行检测和判断是否存在故障。脚本内设置的时间间隔、检测方法、判断逻辑等,可自动控制从检测到故障、确认故障、服务切换和服务恢复,时间长度在3秒到7秒之间。实测时长为5秒以内。业务系统的应用程序服务有重连机制的情况下,可较易地保障数据服务的可用性达到99.99%。相应的架构演示如图2。MySQL数据库服务采用在线双主或双主多从架构部署,中间件服务程序实施MySQL数据库服务的高可用检测算法控制,数据节点的数据源故障对应用程序端透明,故障判断及切换服务恢复的总时长小于3秒,故障发生至切换成功(含数据追平)实测在1.8秒-2.2秒之间,保障数据服务的可用性达到99.99%,保障数据安全的可靠性达到99.99%及以上。详细架构演示如图3。
数据分片采用两副本的存储节点,则为双主半同步归档日志复制。
单个存储节点的服务故障及恢复过程对应用程序端透明,故障判断及切换服务恢复的总时长在秒级。
分布式事务数据库计算节点的内置算法检测、判断和决策。
中间件的主备库常规部署方式为双主在线热备,中间件服务的运行状态由KEEPALIVED软件自动检测,采用特殊定制的脚本以固定频率进行检测和判断是否存在故障。
HotDB数据节点心跳逻辑图如图4所示。
本发明HotDB具有中间件服务、数据源、配置库的高可用及切换机制。有完善的心跳检测机制、故障切换对数据源同步追平判断机制、全局自增序列在故障时自动跳号机制、且可以通过Hold住功能保障数据一致性,MySQL数据库服务采用在线双主或双主多从架构部署,中间件服务程序实施MySQL数据库服务的高可用检测算法控制,数据节点的数据源故障对应用程序端透明,故障判断及切换服务恢复的总时长小于3秒,故障发生至切换成功(含数据追平)实测在1.8秒-2.2秒之间,保障数据服务的可用性达到99.99%,保障数据安全的可靠性达到99.99%及以上。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明披露的技术范围内,根据本发明的技术方案及其发明构思加以等同替换或改变,都应涵盖在本发明的保护范围之内。
Claims (6)
1.一种分布式事务数据库的数据节点心跳检测算法,其特征在于,包括如下步骤:
步骤1、分布式事务数据库计算节点的存储节点主库和存储节点备库上有一张心跳检测表heartbeat,各自有一条数据代表主库和备库;
步骤2、分布式事务数据库计算节点的计算节点主服务,默认设置每隔1秒钟(可根据网络环境自定义时间)向存储节点主库发送一条UPDATE操作判断是否能正常数据访问服务;
步骤3、当分布式事务数据库计算节点的计算节点主服务发送给存储节点主库的第一条UPDATE操作在默认设置的间隔1秒内未得到返回结果;
步骤4、分布式事务数据库计算节点的计算节点主服务降级当下的存储节点主库为故障状态,提升当下的存储节点备库为主库,确保存储节点备库上的中继日志全部解析执行完毕后,解除存储节点数据访问的HOLD住功能,将数据访问操作发往新的存储节点主库;
步骤5、至此,存储节点主库和存储节点备库之间的故障恢复完毕,待故障的存储节点主库服务恢复正常后,分布式事务数据库计算节点的计算节点主服务会自动检测到和降级曾经故障的存储节点主库为备库。
2.根据权利要求1所述的一种分布式事务数据库的数据节点心跳检测算法,其特征在于,步骤3包括如下步骤:
第一步:计算节点主服务发送第二条UPDATE操作给存储节点主库,在默认设置的间隔500毫秒内未得到返回结果,则触发计算节点主服务对该存储节点主库的数据访问请求HOLD住机制;
第二步:计算节点主服务同时向存储节点主库和存储节点备库发送UPDATE操作,在默认设置的间隔10毫秒内未得到存储节点主库返回结果,且存储节点备库返回结果,则触发存储节点主库和存储节点备库见的数据服务切换机制。
3.根据权利要求1所述的一种分布式事务数据库的数据节点心跳检测算法,其特征在于,用户可根据自身网络状态进行监测时间配置,适应自身网络环境不产生误判情况。
4.根据权利要求3所述的一种分布式事务数据库的数据节点心跳检测算法,其特征在于,单个存储节点的服务故障及恢复过程对应用程序端透明。
5.根据权利要求1所述的一种分布式事务数据库的数据节点心跳检测算法,其特征在于,分布式事务数据库计算节点的内置算法检测、判断和决策。
6.根据权利要求1所述的一种分布式事务数据库的数据节点心跳检测算法,其特征在于,中间件的主备库常规部署方式为双主在线热备,中间件服务的运行状态由KEEPALIVED软件自动检测,采用特殊定制的脚本以固定频率进行检测和判断是否存在故障,无需引入外部程序进行控制,减少运维风险。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911361034.2A CN111124757A (zh) | 2019-12-16 | 2019-12-16 | 一种分布式事务数据库的数据节点心跳检测算法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911361034.2A CN111124757A (zh) | 2019-12-16 | 2019-12-16 | 一种分布式事务数据库的数据节点心跳检测算法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111124757A true CN111124757A (zh) | 2020-05-08 |
Family
ID=70502530
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911361034.2A Pending CN111124757A (zh) | 2019-12-16 | 2019-12-16 | 一种分布式事务数据库的数据节点心跳检测算法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111124757A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112367214A (zh) * | 2020-10-12 | 2021-02-12 | 成都精灵云科技有限公司 | 基于etcd的主节点快速检测和切换方法 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103064860A (zh) * | 2011-10-21 | 2013-04-24 | 阿里巴巴集团控股有限公司 | 数据库高可用实现方法及其装置 |
WO2017101731A1 (zh) * | 2015-12-18 | 2017-06-22 | 阿里巴巴集团控股有限公司 | 数据库的服务提供方法和系统 |
CN106982259A (zh) * | 2017-04-19 | 2017-07-25 | 聚好看科技股份有限公司 | 服务器集群的故障解决方法 |
CN107016087A (zh) * | 2017-04-05 | 2017-08-04 | 杭州铭师堂教育科技发展有限公司 | 基于哨兵模型的层级数据库高可用系统 |
CN108009045A (zh) * | 2016-10-31 | 2018-05-08 | 杭州海康威视数字技术股份有限公司 | 一种主备数据库故障处理方法及装置 |
-
2019
- 2019-12-16 CN CN201911361034.2A patent/CN111124757A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103064860A (zh) * | 2011-10-21 | 2013-04-24 | 阿里巴巴集团控股有限公司 | 数据库高可用实现方法及其装置 |
WO2017101731A1 (zh) * | 2015-12-18 | 2017-06-22 | 阿里巴巴集团控股有限公司 | 数据库的服务提供方法和系统 |
CN108009045A (zh) * | 2016-10-31 | 2018-05-08 | 杭州海康威视数字技术股份有限公司 | 一种主备数据库故障处理方法及装置 |
CN107016087A (zh) * | 2017-04-05 | 2017-08-04 | 杭州铭师堂教育科技发展有限公司 | 基于哨兵模型的层级数据库高可用系统 |
CN106982259A (zh) * | 2017-04-19 | 2017-07-25 | 聚好看科技股份有限公司 | 服务器集群的故障解决方法 |
Non-Patent Citations (1)
Title |
---|
PRO_CHENG: "基于Keepalived的Mysql双主单活故障自动切换方案(三)", 《华为云,HTTPS://BBS.HUAWEICLOUD.COM/BLOGS/106010》 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112367214A (zh) * | 2020-10-12 | 2021-02-12 | 成都精灵云科技有限公司 | 基于etcd的主节点快速检测和切换方法 |
CN112367214B (zh) * | 2020-10-12 | 2022-06-14 | 成都精灵云科技有限公司 | 基于etcd的主节点快速检测和切换方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11360854B2 (en) | Storage cluster configuration change method, storage cluster, and computer system | |
CN105406980B (zh) | 一种多节点备份方法及装置 | |
CN109726046B (zh) | 机房切换方法及切换装置 | |
US20070220059A1 (en) | Data processing node | |
US7730029B2 (en) | System and method of fault tolerant reconciliation for control card redundancy | |
WO2021103499A1 (zh) | 一种基于多活数据中心的流量切换方法及装置 | |
CN101079896B (zh) | 一种构建并行存储系统多可用性机制并存架构的方法 | |
US11892922B2 (en) | State management methods, methods for switching between master application server and backup application server, and electronic devices | |
US20070168711A1 (en) | Computer-clustering system failback control method and system | |
CN104536971A (zh) | 一种具备高可用性的数据库 | |
CN104717077B (zh) | 一种管理数据中心的方法、装置及系统 | |
US20230004465A1 (en) | Distributed database system and data disaster backup drilling method | |
US20040153704A1 (en) | Automatic startup of a cluster system after occurrence of a recoverable error | |
CN105959145B (zh) | 一种适用高可用性集群的并行管理服务器的方法及系统 | |
CN111124757A (zh) | 一种分布式事务数据库的数据节点心跳检测算法 | |
CN117421158A (zh) | 数据库故障处理方法、系统及存储介质 | |
CN105323271B (zh) | 一种云计算系统以及云计算系统的处理方法和装置 | |
CN117851514A (zh) | 一种跨多个Hive集群实现数据和任务容灾方法及系统 | |
CN117435405A (zh) | 双机热备和故障切换系统和方法 | |
CN113326251A (zh) | 数据管理方法、系统、设备和存储介质 | |
CN108009045B (zh) | 一种主备数据库故障处理方法及装置 | |
CN117667523A (zh) | 提升Oracle DG高可用性的数据库集群维护方法及系统 | |
CN117271227A (zh) | 数据库集群主节点切换方法、系统及管控平台 | |
KR20140140719A (ko) | 가상 머신 동기화 장치 및 시스템과 이를 이용한 장애 처리 방법 | |
CN111404737A (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 | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200508 |