CN114116912A - 一种基于Keepalived实现数据库高可用的方法 - Google Patents
一种基于Keepalived实现数据库高可用的方法 Download PDFInfo
- Publication number
- CN114116912A CN114116912A CN202210083118.XA CN202210083118A CN114116912A CN 114116912 A CN114116912 A CN 114116912A CN 202210083118 A CN202210083118 A CN 202210083118A CN 114116912 A CN114116912 A CN 114116912A
- Authority
- CN
- China
- Prior art keywords
- database
- keepalived
- configuration
- service
- high availability
- 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
Images
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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/273—Asynchronous replication or reconciliation
-
- 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
- G06F16/275—Synchronous replication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
Abstract
本发明公开了一种基于Keepalived实现数据库高可用的方法,所述实现数据库高可用的方法包括以下步骤:S1、对Postgres进行异步流复制配置,配置完成后启动Postgresql服务;S2、执行Postgres的主从数据同步策略,主数据库同步数据到多个从数据库,用于主从数据库数据之间的并发读取;S3、进行Keepalived的全局配置、VRRPD配置和VRRP脚本配置,并对Keepalived进行初始化;S4、配置探活脚本实时监测主数据库的服务状态,当主数据库状态存在异常时,执行主备切换策略。本发明在保证主备主机实时同步数据的情况下,通过实时检测机制提高了主备切换时同步数据的完整性。
Description
技术领域
本发明涉及网络通信技术领域,具体为一种基于Keepalived实现数据库高可用的方法。
背景技术
Keepalived起初是为LVS设计的,专门用来监控集群系统中各个服务节点的状态,它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态,如果某个服务器节点出现异常,或者工作出现故障,Keepalived将检测到,并将出现的故障的服务器节点从集群系统中剔除,这些工作全部是自动完成的,不需要人工干涉,需要人工完成的只是修复出现故障的服务节点。后来Keepalived又加入了VRRP的功能,VRRP(VritrualRouterRedundancyProtocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题,通过VRRP可以实现网络不间断稳定运行。所以,Keepalived 一方面具有配置管理LVS 的功能,同时还具有对LVS 下面节点进行健康检查的功能,另一方面也可以实现系统网络服务的高可用功能。
现有技术中,有关于KeepAlived高可用的方案记载,比如网址“https://blog.csdn.net/enmotech/article/details/120984252”中公开了用Keepalived实现PostgreSQL高可用,还有网址“https://www.cnblogs.com/f-ck-need-u/p/8483807.html”公开了,高可用之KeepAlived(一):基本概念和配置文件分析,但是上述两种方案记载的配置复杂,且不能保证主备切换时同步数据的完整性。
目前对于Postgres的高可用方案,市面上多为使用中间件Pgpoll-II来完成。Pgpool-II支持了丰富的功能,像连接池,负载均衡,高可用,复制等,基本符合了Postgres集群的要求,但在实际使用中也存在很多问题,常常令使用者不知所措。首先就是Pgpool的安装部署,Pgpool的安装需要修改大量的配置文件,稍有不慎就导致程序启动失败,这对于一个新手来说十分不友好,有时我们甚至不知道是哪出了问题。其次在使用过程中,发现Pgpoll-II在进行主备切换的逻辑并不严谨,在备库切换成主库前没有对主备延迟做判断,导致同步数据的不一致。
发明内容
本发明的目的在于提供了一种基于Keepalived实现数据库高可用的方法,通过使用Keepalived以及配置相应的探活脚本,配合Postgres的异步流复制方案来实现高可用,配置简单且提高了主备切换时同步数据的完整性。
为实现上述目的,本发明提供如下技术方案:一种基于Keepalived实现数据库高可用的方法,所述实现数据库高可用的方法包括以下步骤:
S1、对Postgres进行异步流复制配置,配置完成后启动Postgresql服务;
S2、执行Postgres的主从数据同步策略,主数据库同步数据到多个从数据库,用于主从数据库数据之间的并发读取;
S3、进行Keepalived的全局配置、VRRPD配置和VRRP脚本配置,并对Keepalived进行初始化;
S4、配置探活脚本实时监测主数据库的服务状态,当主数据库状态存在异常时,执行主备切换策略。
优选的,在所述步骤S1中,对Postgres进行异步流复制配置时,将主数据库和从数据库的数据库流复制时间粒度设定为最低频次,使主从数据库同步时间接近实时。
优选的,在所述步骤S2中,主从数据同步策略包括配置MergeData脚本,读取主数据库的执行日志合并到从数据库。
优选的,在所述步骤S3中,进行Keepalived的全局配置包括指定一个本网络中未被占用的虚拟ip,并使接口名配置一致。
优选的,所述步骤S4包括配置Keepalived的检测时间小于数据库同步时间。
优选的,配置主节点254.128上Keepalived的vrrp_script项中interval值为2,即每2s检测一次主数据库的服务状态,并将数据库同步时间设定为3秒。
优选的,所述步骤S4中配置探活脚本实时监测主数据库的服务状态检测失败次数、失败超时时间来认定服务失败结果。
优选的,所述步骤S4包括周期性检测主数据库服务的状态,当状态返回为Failed/Stopped时,满足切换条件,执行主备切换策略,主备切换策略包括首先主动关闭主数据库服务,关闭成功后虚拟ip漂移,用户访问第三方接口或web服务访问时会自动映射到从数据库,切换完成后退出整体流程,若关闭失败或者不满足切换条件,则退出检测程序,等待下个周期进行检测。
优选的,所述步骤S3包括在Keepalived生命周期的各个阶段均预留相应接口,用于供用户按照相应规范实现数据加载或信息通知。
优选的,所述步骤S3包括对LVS四层负载均衡进行统一配置。
与现有技术相比,本发明的有益效果是:
本发明部署安装过程操作简单,通过全局配置,VRRPD配置,VRRP脚本等少量的配置,即可实现Postgres的高可用。
本发明在保证主备主机实时同步数据的情况下,通过实时检测机制提高了主备切换时同步数据的完整性。通过使用Keepalived以及配置相应的探活脚本,配合Postgres的异步流复制方案来实现高可用,配置简单且提高了主备切换时同步数据的完整性。
本发明支持对KeepAvlied进行深度扩展,即对LVS四层负载均衡进行统一快速配置管理,极大简化LVS集群节点的冗余配置,给使用者提供通俗化的说明。
附图说明
图1为本发明一种基于Keepalived实现数据库高可用的方法的流程框图;
图2为本发明一种基于Keepalived实现数据库高可用的方法的架构图;
图3为本发明一种基于Keepalived实现数据库高可用的方法中部署Keepalived加postgres环境的拓扑图;
图4为本发明一种基于Keepalived实现数据库高可用的方法中主备切换的架构图;
图5为本发明一种基于Keepalived实现数据库高可用的方法中探活脚本执行流程图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
如图1和图2所示,本发明提供的一种实施例,一种基于Keepalived实现数据库高可用的方法,所述实现数据库高可用的方法包括以下步骤:
S1、对Postgres进行异步流复制配置,配置完成后启动Postgresql服务。
S2、执行Postgres的主从数据同步策略,主数据库同步数据到多个从数据库,用于主从数据库数据之间的并发读取;
S3、进行Keepalived的全局配置、VRRPD配置和VRRP脚本配置,并对Keepalived进行初始化;具体的,打开Keepalived.conf文件,根据当前部署环境按照注释提示进行修改,修改完成后通过启动程序检验配置的正确性。
S4、配置探活脚本实时监测主数据库的服务状态,当主数据库状态存在异常时,执行主备切换策略。探活脚本主要检测当前主机上的数据库服务的运行状态是否正常,当出现运行异常,会主动发生切换流程,此时由于主节点发生变更,那么从节点的同步数据来源也会发生相应的改变。周期性检测的目的就是判定数据库服务的可用性。
探活脚本监测机制即从服务器周期性通过发送多播报文来检测主服务器状态(内部使用VRRP协议);主服务器自身通过探活脚本周期性判定数据库服务的状态;服务器状态检测是通过Keepalived来完成,数据库服务状态通过探活脚本完成。
具体的,探活脚本配置有ICMP请求策略、端口监测策略和日志监测策略;所述ICMP请求策略包含向主数据库发送ICMP请求,并根据服务状态反馈请求结果来判断主数据库是否异常,但是出于安全考虑,某些应用环境主数据库有时会设置成禁止接收ICMP请求状态,所以就需要配置端口监测策略机制,端口监测策略用户监测数据库服务的端口进程状态,通过主数据库的端口服务器进程可以判断主数据库端口是否发生异常现象,但是有些端口的进程会出现假死现象,导致主数据库检测结果并不完全可靠,这是就需要日志检测策略用于查询主数据库日志最近的更新时间,根据主数据库日志更新周期来判断主数据库的异常与否,通过上面三种检测策略,可以有效的保证主数据库服务状态获取的可靠性、完整性,避免因禁ping或端口异常产生的误告警现象。
通过使用Keepalived以及配置相应的探活脚本,配合Postgres的异步流复制方案来实现高可用,配置简单且提高了主备切换时同步数据的完整性。
在所述步骤S1中,对Postgres进行异步流复制配置时,将主数据库和从数据库的数据库流复制时间粒度设定为最低频次,使主从数据库同步时间接近实时;在所述步骤S2中,主从数据同步策略包括配置MergeData脚本,读取主数据库的执行日志合并到从数据库;所述步骤S4包括配置Keepalived的检测时间小于数据库同步时间。具体的,配置主节点254.128上Keepalived的vrrp_script项中interval值为2,即每2s检测一次主数据库的服务状态,并将数据库同步时间设定为3秒。
综上,为了保证Postgres数据库数据的同步实时性,在配置Postgres数据库异步流复制时延时,一方面选择一个低延迟的时间,每3s同步复制一次的频次,另一方面设置Keepalived的检测时间配置小于数据库同步时间。我们配置主节点254.128上Keepalived的vrrp_script项中interval值为2,即每2s检测一次主数据库的服务状态。这样的时间设计,将尽可能保证检测的及时性与数据同步的完整性。
如图2所示,所述步骤S4包括周期性检测主数据库服务的状态,当状态返回为Failed/Stopped时,满足切换条件,执行主备切换策略,主备切换策略包括首先主动关闭主数据库服务,关闭成功后虚拟ip漂移,用户访问第三方接口或web服务访问时会自动映射到从数据库,切换完成后退出整体流程,若关闭失败或者不满足切换条件,则退出检测程序,等待下个周期进行检测。
如图3所示,为部署Keepalived+postgres环境的拓扑图,结合附图3,对本发明Keepalived+postgres中的技术方案进行清楚、完整地描述,显然,所描述的Keepalived+postgres仅仅是本发明应用的一部分,而不是全部的应用功能。基于本发明中Keepalived+postgres,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他Keepalived+postgres高可用方案,都属于本发明保护的范围。
在该实施例下,运行环境为Linux Centos7+ 64bit系统,首先需要对Postgres进行异步流复制配置,配置完成后启动Postgresql服务,服务开启后就开始进行Postgres的主从数据同步机制,主数据库同步数据到多个从数据库,支持主从数据库数据的并发读取。其次配置Keepalived的全局配置,VRRPD配置,VRRP脚本配置,配置完成后进行初始化Keepalived,通过配置探活脚本来实时监测主数据库的服务状态,并配置失败尝试次数、失败超时时间等参数认定服务失败结果。最后完成上述Postgres,Keepalived的参数配置并启动服务后,数据库的主备库正常进行数据的同步,同时Keepalived配置的探活脚本能够周期性检测主、从数据库的状态是否存活,当主数据库状态存在异常时,开始进入探活脚本的主备切换环节。
如图4和图5所示,在该实施例下,主数据库部署在254.128上,从数据库部署在254.129上,创建的虚拟ip为254.11并映射到254.128主机上。在254.128主机的Keepalived的vrrp_script配置中,配有checkAlived.sh探活脚本,周期性检测主数据库服务的状态,当状态返回为Failed/Stopped时,也就是checkAlived.sh脚本返回值为1,此时满足切换条件,将会触发切换流程;如果返回0,则不满切换条件。首先主动关闭主数据库服务,关闭成功后,开始发生ip漂移,虚拟ip将会从254.238主机上漂移到254.129主机,用户访问第三方接口或web服务访问时会自动映射到254.239主机的从数据库,切换完成后退出整体流程;如果关闭失败或者不满足切换条件,都会退出检测程序,待下个周期再进行检测。
优选的,在所述步骤S3中,进行Keepalived的全局配置包括指定一个本网络中未被占用的虚拟ip,并使接口名配置一致。所述步骤S4中配置探活脚本实时监测主数据库的服务状态配置失败尝试次数、失败超时时间等参数来认定服务失败结果。对于检测的周期定义的更加丰富,包括从秒级,分钟级,小时级,周级,月级等;对于检测失败的判定更加丰富,包括连续失败几次判定为失败,失败过程中的一次成功会重置失败计数,并增加了对超时时间的定义,因此更加适配特定的场景。
本发明基于Keepalived的网络服务高可用功能,Keepalived 可以实现任意两台主机之间,例如 Master 和 Backup 主机之间的故障转移和自动切换,这个主机可以是普通的不能停机的业务服务器,也可以是 LVS 负载均衡、Nginx 反向代理这样的服务器。同时我们又添加了探活脚本,可以周期性检测各个服务的运行状态,当状态发生改变,立刻采取相应的切换措施,来达到服务接近不间断的运行。本发明部署安装过程操作简单,通过全局配置,VRRPD配置,VRRP脚本等少量的配置,即可实现Postgres的高可用。本发明在保证主备主机实时同步数据的情况下,通过实时检测机制提高了主备切换时同步数据的完整性。本发明还提供了在Keepalived运行生命周期内的可扩展性功能,针对探活脚本可以加入一些额外的特色功能。例如:自定义日志记录、同步数据告警监测等。本发明除了实现Postgres高可用,还可用于实现web服务、Nginx中间件、Tomcat、Glassfish等应用服务器的高可用定制开发。本发明还支持对KeepAvlied进行深度扩展,即对LVS四层负载均衡进行统一快速配置管理,极大简化LVS集群节点的冗余配置,给使用者提供通俗化的说明。具体的,根据不同的项目需要来增加日志记录模块,告警监测模块。首先需要自己开发日志记录,告警监测功能,开发完成需要注册到系统中,这时将作为监听者开始监听,当探活脚本运行过程对于关键内容的触发,将会把内容发送给监听者,这时由监听者具体来处理。至于模块的具体实现很自由,依靠不同项目组的技术栈,项目特点来完成,本申请的处理相对具体,系统定义了一系列规范性接口,按照接口开发更为方便。
工作原理:本发明基于Keepalived的网络服务高可用功能,Keepalived 可以实现任意两台主机之间的故障转移和自动切换,同时我们又添加了探活脚本,可以周期性检测各个服务的运行状态,当状态发生改变,立刻采取相应的切换措施,来达到服务接近不间断的运行。并且在Keepalived生命周期的各个阶段均预留相应接口,用于供用户按照相应规范实现数据加载或信息通知。对已有的LVS负载均衡配置进行包装,按照约定配置方式,简化配置,暴露给使用者更加简单的配置。本发明部署安装过程操作简单,通过全局配置,VRRPD配置,VRRP脚本等少量的配置,即可实现Postgres的高可用。在保证主备主机实时同步数据的情况下,通过实时检测机制提高了主备切换时同步数据的完整性。通过使用Keepalived以及配置相应的探活脚本,配合Postgres的异步流复制方案来实现高可用,配置简单且提高了主备切换时同步数据的完整性。还支持对KeepAvlied进行深度扩展,即对LVS四层负载均衡进行统一快速配置管理,极大简化LVS集群节点的冗余配置,给使用者提供通俗化的说明。
对于本领域技术人员而言,显然本发明不限于上述示范性实施例的细节,而且在不背离本发明的精神或基本特征的情况下,能够以其他的具体形式实现本发明。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本发明的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
Claims (10)
1.一种基于Keepalived实现数据库高可用的方法,其特征在于,所述实现数据库高可用的方法包括以下步骤:
S1、对Postgres进行异步流复制配置,配置完成后启动Postgresql服务;
S2、执行Postgres的主从数据同步策略,主数据库同步数据到多个从数据库,用于主从数据库数据之间的并发读取;
S3、进行Keepalived的全局配置、VRRPD配置和VRRP脚本配置,并对Keepalived进行初始化;
S4、配置探活脚本实时监测主数据库的服务状态,当主数据库状态存在异常时,执行主备切换策略。
2.根据权利要求1所述的基于Keepalived实现数据库高可用的方法,其特征在于,在所述步骤S1中,对Postgres进行异步流复制配置时,将主数据库和从数据库的数据库流复制时间粒度设定为最低频次,使主从数据库同步时间接近实时。
3.根据权利要求2所述的基于Keepalived实现数据库高可用的方法,其特征在于,在所述步骤S2中,主从数据同步策略包括配置MergeData脚本,读取主数据库的执行日志合并到从数据库。
4.根据权利要求3所述的基于Keepalived实现数据库高可用的方法,其特征在于,在所述步骤S3中,进行Keepalived的全局配置包括指定一个本网络中未被占用的虚拟ip,并使接口名配置一致。
5.根据权利要求4所述的基于Keepalived实现数据库高可用的方法,其特征在于,所述步骤S4包括配置Keepalived的检测时间小于数据库同步时间。
6.根据权利要求5所述的基于Keepalived实现数据库高可用的方法,其特征在于,配置主节点上Keepalived的vrrp_script项中interval值为2,即每2s检测一次主数据库的服务状态,并将数据库同步时间设定为3秒。
7.根据权利要求6所述的基于Keepalived实现数据库高可用的方法,其特征在于,所述步骤S4中配置探活脚本实时监测主数据库的服务状态配置失败次数和失败超时时间参数来认定服务失败结果。
8.根据权利要求7所述的基于Keepalived实现数据库高可用的方法,其特征在于,所述步骤S4包括周期性检测主数据库服务的状态,当状态返回为Failed/Stopped时,满足切换条件,执行主备切换策略,主备切换策略包括首先主动关闭主数据库服务,关闭成功后虚拟ip漂移,用户访问第三方接口或web服务访问时会自动映射到从数据库,切换完成后退出流程,若关闭失败或者不满足切换条件,则退出检测程序,等待下个周期进行检测。
9.根据权利要求7所述的基于Keepalived实现数据库高可用的方法,其特征在于,所述步骤S3包括在Keepalived生命周期的各个阶段均预留相应接口,用于供用户按照相应规范实现数据加载或信息通知。
10.根据权利要求7所述的基于Keepalived实现数据库高可用的方法,其特征在于,所述步骤S3包括对LVS四层负载均衡进行统一配置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210083118.XA CN114116912A (zh) | 2022-01-25 | 2022-01-25 | 一种基于Keepalived实现数据库高可用的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210083118.XA CN114116912A (zh) | 2022-01-25 | 2022-01-25 | 一种基于Keepalived实现数据库高可用的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114116912A true CN114116912A (zh) | 2022-03-01 |
Family
ID=80361130
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210083118.XA Pending CN114116912A (zh) | 2022-01-25 | 2022-01-25 | 一种基于Keepalived实现数据库高可用的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114116912A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114785789A (zh) * | 2022-04-26 | 2022-07-22 | 平安普惠企业管理有限公司 | 数据库故障管理方法、装置、电子设备及存储介质 |
CN115658078A (zh) * | 2022-12-27 | 2023-01-31 | 金篆信科有限责任公司 | 数据库的预编译处理方法、装置、设备及介质 |
CN115941686A (zh) * | 2022-11-15 | 2023-04-07 | 浪潮云信息技术股份公司 | 一种实现云原生应用高可用服务的方法及系统 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104503965A (zh) * | 2014-10-16 | 2015-04-08 | 杭州斯凯网络科技有限公司 | PostgreSQL高弹性的高可用及负载均衡实现方法 |
CN113360579A (zh) * | 2021-06-30 | 2021-09-07 | 平安普惠企业管理有限公司 | 数据库高可用处理方法、装置、电子设备及存储介质 |
-
2022
- 2022-01-25 CN CN202210083118.XA patent/CN114116912A/zh active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104503965A (zh) * | 2014-10-16 | 2015-04-08 | 杭州斯凯网络科技有限公司 | PostgreSQL高弹性的高可用及负载均衡实现方法 |
CN113360579A (zh) * | 2021-06-30 | 2021-09-07 | 平安普惠企业管理有限公司 | 数据库高可用处理方法、装置、电子设备及存储介质 |
Non-Patent Citations (2)
Title |
---|
将臣三代: "使用 keepalived 实现 PostgreSQL主从异步流复制的高可用", 《HTTPS://BLOG.CSDN.NET/YAOQIANCUO3276/ARTICLE/DETAILS/80797620》 * |
阿莲-ALIANA: "Postgresql+Keepalived高可用方案", 《HTTPS://BLOG.CSDN.NET/WEIXIN_45428187/ARTICLE/DETAILS/120924949》 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114785789A (zh) * | 2022-04-26 | 2022-07-22 | 平安普惠企业管理有限公司 | 数据库故障管理方法、装置、电子设备及存储介质 |
CN114785789B (zh) * | 2022-04-26 | 2024-01-16 | 永诚恒易网络科技股份有限公司 | 数据库故障管理方法、装置、电子设备及存储介质 |
CN115941686A (zh) * | 2022-11-15 | 2023-04-07 | 浪潮云信息技术股份公司 | 一种实现云原生应用高可用服务的方法及系统 |
CN115658078A (zh) * | 2022-12-27 | 2023-01-31 | 金篆信科有限责任公司 | 数据库的预编译处理方法、装置、设备及介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9037899B2 (en) | Automated node fencing integrated within a quorum service of a cluster infrastructure | |
CN114116912A (zh) | 一种基于Keepalived实现数据库高可用的方法 | |
US9348706B2 (en) | Maintaining a cluster of virtual machines | |
KR100658913B1 (ko) | 광범위한 클러스터들에서의 노드 장애에 대비하여 원격액세스가능 자원들을 계속적으로 모니터링하는 확장 방법 | |
JP4457184B2 (ja) | ストレージシステムにおけるフェイルオーバー処理 | |
EP3210367B1 (en) | System and method for disaster recovery of cloud applications | |
CN108270726B (zh) | 应用实例部署方法及装置 | |
CN106341454A (zh) | 跨机房多活分布式数据库管理系统和方法 | |
CN108234191A (zh) | 云计算平台的管理方法和装置 | |
JP2005512190A (ja) | ネットワーク化システムにおけるリソースの高可用性をもたらす実複合オブジェクト | |
CN102394914A (zh) | 集群脑裂处理方法和装置 | |
CN103546914A (zh) | 一种hss主备管理的方法及装置 | |
CN106452836B (zh) | 主节点设置方法及装置 | |
CN113515316A (zh) | 一种新型边缘云操作系统 | |
CN112887367B (zh) | 实现分布式集群高可用的方法、系统及计算机可读介质 | |
CN107357800A (zh) | 一种数据库高可用零丢失解决方法 | |
CN105824571A (zh) | 一种实现数据无缝迁移的方法及装置 | |
Mitrović et al. | Improving fault-tolerance of distributed multi-agent systems with mobile network-management agents | |
CN112187523A (zh) | 一种网络高可用实现方法及超融合系统 | |
CN105468446A (zh) | 一种基于Linux的HPC作业调度实现高可用的方法 | |
CN116723077A (zh) | 一种分布式it自动化运维系统 | |
Kitamura et al. | Development of File Management System for a Peer-to-Peer Method Server Management System | |
Li et al. | Challenges to error diagnosis in hadoop ecosystems | |
CN110266795A (zh) | 一种基于Openstack平台控制方法 | |
CN115549751A (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: 20220301 |