CN104866556B - 数据库的故障处理方法、装置和数据库系统 - Google Patents

数据库的故障处理方法、装置和数据库系统 Download PDF

Info

Publication number
CN104866556B
CN104866556B CN201510250730.1A CN201510250730A CN104866556B CN 104866556 B CN104866556 B CN 104866556B CN 201510250730 A CN201510250730 A CN 201510250730A CN 104866556 B CN104866556 B CN 104866556B
Authority
CN
China
Prior art keywords
database
server
data
primary
primary database
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.)
Expired - Fee Related
Application number
CN201510250730.1A
Other languages
English (en)
Other versions
CN104866556A (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.)
Beijing Qihoo Technology Co Ltd
Original Assignee
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing 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 Beijing Qihoo Technology Co Ltd, Qizhi Software Beijing Co Ltd filed Critical Beijing Qihoo Technology Co Ltd
Priority to CN201510250730.1A priority Critical patent/CN104866556B/zh
Publication of CN104866556A publication Critical patent/CN104866556A/zh
Application granted granted Critical
Publication of CN104866556B publication Critical patent/CN104866556B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提供了一种数据库的故障处理方法、装置和数据库系统,涉及计算机领域。本发明实施例通过在主数据库发生故障时,收集其从数据库所在服务器的使用状态信息,并通过使用状态信息确定各个从数据库所在服务器的可用业务承载能力,选择其中可用业务承载能力最好的服务器对应的从数据库作为新的主数据库。通过本发明,当主数据库发生故障无法提供服务时,可以选择业务承载能力最好服务器对应的从数据库作为新的主数据库,从而避免了由于新的主数据库选择不当造成服务中断或者运行效率低下的问题。

Description

数据库的故障处理方法、装置和数据库系统
技术领域
本发明涉及计算机领域,特别涉及一种数据库的故障处理方法、装置和数据库系统。
背景技术
Redis是一种内存型数据库,其特点是读取、写入速度快,是一种由开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。Redis支持主从同步。
Redis数据库支持主从式架构,可以从主数据库向任意数量的从数据库同步数据。在Redis数据库的运行过程中,主数据库发生故障时,为了保证Redis数据库的正常运行,会从当前的从数据库中选择一个从数据库作为新的主数据库。
但是,在现有技术中,Redis数据库在从数据库中选择新的主数据库时,是通过随机选择的方式进行选择。这样的缺陷是,在每个从数据库的实例具有差别,若选择到了一个业务承载能力较差的服务器上的从数据库作为新的主数据库,会影响Redis数据库的运行效率和服务提供品质。
发明内容
鉴于上述问题,提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种数据库的故障处理方法、相应的装置和数据库系统。
依据本发明的一个方面,提供一种数据库的故障处理方法,应用于具备主从结构的数据库集群,包括:
检测到内存访问的主数据库发生故障时,收集所述主数据库对应的至少一个从数据库所在服务器的使用状态信息;
对各从数据库所在服务器的使用状态信息进行分析,确定出各从数据库所在服务器的可用业务承载能力;
对各从数据库所在服务器的可用业务承载能力进行比较,选择出其中可用业务承载能力最大的服务器对应的从数据库;以及
使用选择出的从数据库替换发生故障的主数据库,以作为新的主数据库。
可选地,所述使用选择出的从数据库替换发生故障的主数据库,以作为新的主数据库之后,还包括:将所述新的主数据库中的数据同步至剩余的其他从数据库中。
可选地,将所述新的主数据库中的数据同步至剩余的其他从数据库中,包括:
确定所述新的主数据库中存储的数据量,以及所述新的主数据库与剩余的其他从数据库间的网络状态;
根据所述新的主数据库的数据量,以及所述网络状态,确定每次可挂载的从数据库的数量;以及
根据确定的从数据库的数量,分批次实现所述新的主数据库到剩余的其他从数据库的数据同步。
可选地,所述网络状态至少包括网卡的数据传输速率。
可选地,根据所述新的主数据库的数据量,以及所述网络状态,确定每次可挂载的从数据库的数量,包括:
利用所述新的主数据库的数据量除以所述网卡的数据传输速率,得到所述新的主数据库的数据量同步一次的所需时间;
根据所述新的主数据库数据同步至所有从数据库的时间限制以及上述所需时间,确定完成所有同步操作所需同步总次数;以及
根据所述同步总次数对所有从数据库进行分批处理,确定每次可挂载的从数据库的数量。
可选地,所述从数据库所在服务器的使用状态信息包括以下参数至少之一:
从数据库所在服务器的当前负载;
从数据库所在服务器的内存剩余量;
从数据库所在服务器上的业务数;
从数据库所在服务器上不同业务的互相影响性;
从数据库所在服务器支持的数据读写速率;以及
从数据库所在服务器支持的网卡数据传输速率。
可选地,所述对各从数据库所在服务器的使用状态信息进行分析,确定出各从数据库所在服务器的可用业务承载能力,包括:
为所述使用状态信息中的各参数设置不同权值以及权值比重;
计算得到各从数据库所在服务器的使用状态信息中各参数的权值总值,将其作为各从数据库所在服务器的可用业务承载能力指标。
可选地,对各从数据库所在服务器的可用业务承载能力进行比较,选择出其中可用业务承载能力最大的服务器对应的从数据库,包括:比较各从数据库所在服务器的使用状态信息中各参数的权值总和,选择出其中最大权值总和对应的从数据库。
可选地,所述主数据库和从数据库皆为内存型数据库。
可选地,所述主数据库和从数据库皆为Redis数据库。
依据本发明的另一个方面,提供一种数据库的故障处理装置,应用于具有主从结构的数据库集群,包括:
信息收集模块,适于检测到主数据库发生故障时,收集所述主数据库对应的至少一个从数据库所在服务器的使用状态信息;
信息分析模块,适于对各从数据库所在服务器的使用状态信息进行分析,确定出各从数据库所在服务器的可用业务承载能力;
从数据库选择模块,适于对各从数据库所在服务器的可用业务承载能力进行比较,选择出其中可用业务承载能力最大的服务器对应的从数据库;
替换模块,适于使用选择出的从数据库替换发生故障的主数据库,以作为新的主数据库。
可选地,上述装置还包括:
数据同步模块,适于将所述新的主数据库中的数据同步至剩余的其他从数据库中。
可选地,所述数据同步模块还适于:
确定所述新的主数据库中存储的数据量,以及所述新的主数据库与剩余的其他从数据库间的网络状态;
根据所述新的主数据库的数据量,以及所述网络状态,确定每次可挂载的从数据库的数量;以及
根据确定的从数据库的数量,分批次实现所述新的主数据库到剩余的其他从数据库的数据同步。
可选地,所述网络状态至少包括网卡的数据传输速率。
可选地,所述数据同步模块还适于:
利用所述新的主数据库的数据量除以所述网卡的数据传输速率,得到所述新的主数据库的数据量同步一次的所需时间;
根据所述新的主数据库数据同步至所有从数据库的时间限制以及上述所需时间,确定完成所有同步操作所需同步总次数;以及
根据所述同步总次数对所有从数据库进行分批处理,确定每次可挂载的从数据库的数量。
可选地,所述从数据库所在服务器的使用状态信息包括以下参数至少之一:
从数据库所在服务器的当前负载;
从数据库所在服务器的内存剩余量;
从数据库所在服务器上的业务数;
从数据库所在服务器上不同业务的互相影响性;
从数据库所在服务器支持的数据读写速率;以及
从数据库所在服务器支持的网卡数据传输速率。
可选地,所述信息分析模块还适于:
为所述使用状态信息中的各参数设置不同权值以及权值比重;
计算得到各从数据库所在服务器的使用状态信息中各参数的权值总值,将其作为各从数据库所在服务器的可用业务承载能力指标。
可选地,所述信息分析模块还适于:
比较各从数据库所在服务器的使用状态信息中各参数的权值总和,选择出其中最大权值总和对应的从数据库。
可选地,所述主数据库和从数据库皆为内存型数据库。
可选地,所述主数据库和从数据库皆为Redis数据库。
依据本发明的又一个方面,提供一种数据库系统,包括一个主数据库,多个从数据库,还包括:上述的任一种数据库的故障处理装置。
本发明实施例提供了一种数据库的故障处理方法、装置和系统,通过在主数据库发生故障时,收集其从数据库所在服务器的使用状态信息,并通过使用状态信息确定各个从数据库的所在服务器的可用业务承载能力,选择其中可用业务承载能力最好的服务器对应的从数据库作为新的主数据库。通过本发明实施例所提供的方法,当主数据库发生故障无法提供服务时,可以选择业务承载能力最好的服务器上的从数据库作为新的主数据库,从而避免了由于新的主数据库选择不当造成服务中断或者运行效率低下的问题。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
根据下文结合附图对本发明具体实施例的详细描述,本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1是本发明一个实施例提供的一种数据库的故障处理方法流程图;
图2是本发明一个实施例提供的一种Redis数据库的架构示意图;
图3是本发明一个实施例提供的一种数据库的故障处理具体方法流程图;
图4是本发明一个实施例提供的一种切换主数据库后的Redis数据库的架构示意图;
图5是本发明一个实施例提供的一种数据库的故障处理装置的结构框图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
实施例一
本发明实施例提供了一种数据库的故障处理方法,其可以实现在数据库集群中,当主数据库发生故障无法提供服务时,可以选择一业务承载能力较强的服务器上的从数据库作为新的主数据库,保证提供正常的服务。
图1是本实施例提供的一种数据库的故障处理方法的流程示意图,该方法应用于具有主从结构的数据库集群,包括步骤S102至步骤S108。
S102:检测到主数据库发生故障时,收集主数据库对应的至少一个从数据库所在服务器的使用状态信息。
S104:对各从数据库所在服务器的使用状态信息进行分析,确定出各从数据库所在服务器的可用业务承载能力。
S106:对各从数据库所在服务器的可用业务承载能力进行比较,选择出其中可用业务承载能力最大的服务器对应的从数据库。
S108:使用选择出的从数据库替换发生故障的主数据库,以作为新的主数据库。
本发明实施例提供了一种数据库的故障处理方法、装置和系统,通过在主数据库发生故障时,收集其从数据库所在服务器的使用状态信息,并通过使用状态信息确定各个从数据库的所在服务器的可用业务承载能力,选择其中可用业务承载能力最好的服务器对应的从数据库作为新的主数据库。通过本发明实施例所提供的方法,当主数据库发生故障无法提供服务时,可以选择业务承载能力最好的服务器上的从数据库作为新的主数据库,从而避免了由于新的主数据库选择不当造成服务中断或者运行效率低下的问题。
实施例二
本实施例为上述实施例一的一种具体应用场景,通过本实施例,能够更加清楚、具体地阐述本发明所提供的方法。
应可理解,本发明并不限定数据库的类型,只要可以应用本发明下述方案以达到切换从数据库的目的的数据库都适用于此。本领域技术人员在阅读本发明的基础上,亦可以通过简单的步骤组合和步骤之间的变换实现主从数据库的切换,其皆应涵盖在本发明的范围内。
本实施例中,将以Redis数据库为例说明本发明的技术方案:
为了能够对本发明实施例所提供的方法进行更清楚的说明,在本实施例二中,以图2所示的一种Redis数据库的架构为例进行说明。其中,在图2所示的Redis数据库中,包括一个主数据库,以及从数据库A、从数据库B和从数据库C。本实施例以当主数据库发生故障无法正常运行时,在从数据库A、从数据库B和从数据库C选取新的主数据库为例进行说明。
图3为本发明实施例提供的一种数据库的故障处理具体方法流程图,该方法共包括步骤S301至S307。
首先,执行步骤S301,当Redis数据库集群的主数据库发生故障时,收集全部从数据库所在服务器的使用状态信息。
其中,在本实施例中,从数据库所在服务器的使用状态信息包括但不限于如下参数的信息:
从数据库所在服务器的当前负载、从数据库所在服务器的内存剩余量、从数据库所在服务器上的业务数、从数据库所在服务器上不同业务的互相影响性、从数据库所在服务器支持的数据读写速率、从数据库所在服务器支持的网卡数据传输速率等。
需要说明的是,本实施例中,为了能够收集各个从数据库所在服务器的使用状态信息,可以设置一脚本在各个从数据库所在的服务器上,在脚本中写入用于获取以上各状态信息的代码。当需要获取各个从数据库所在服务器的使用状态信息时,在各个从数据库所在的服务器则运行该脚本,并将通过运行脚本获取得到的使用状态信息发送给数据库的管理装置,以完成对各个从数据库所在服务器的使用状态信息进行收集。
在收集得到全部从数据库所在服务器的使用状态信息后,执行步骤S302,对各个从数据库所在服务器的使用状态信息进行分析,确定出各个从数据库所在服务器的可用业务承载能力。
本发明实施例具体可以通过如下方式收集到各个从数据库所在服务器的使用状态信息,确定出其中业务承载能力最好的服务器上的从数据库作为新的主数据库:
首先,为各从数据库所在服务器的使用状态信息中的各参数设置不同权值以及权值比重。
然后,计算得到各从数据库所在服务器的使用状态信息中各参数的权值总和,将其作为各从数据库所在服务器的可用业务承载能力指标。
其中,从数据库所在服务器的使用状态信息中的不同参数对于服务器的承载能力的影响不同,因此,需要对每种参数设置不同的权重值,例如:
可用内存相对于网卡的可用带宽更加重要,则将内存剩余量的权重设置较高,而将网卡数据传输速率设置的权重较低。
在收集得到从数据库所在服务器的使用状态信息的各参数后,结合各个参数对应的权重,即可计算得到每个从数据库所在服务器的可用性评分,用于表述每个服务器的可用业务承载能力,得分越高,则表示该服务器的业务承载能力越强,相反,则表示该服务器的业务承载能力越弱。
在得到每个从数据库所在服务器的可用业务承载能力后,执行步骤S303,对各从数据库所在服务器的可用业务承载能力进行比较,选择出其中可用业务承载能力最大的服务器对应的从数据库。
需要说明的是,对于每个从数据库,由于在其上的数据量的不同,也会导致每个从数据库对应的服务器的压力不同,例如:
某些从数据库所在的服务器可能当前内存已经使用90%,其就不再适合作为新的主数据库,由于主数据库对于服务器的业务承载能力要求较高,若将该种从数据库被设置为新的主数据库,很有可能刚刚切换完成就会因为业务过载而导致服务中断,这时,仍需继续切换主数据库,操作繁琐,而且效率较低。因而,选择业务承载能力最大的服务器对应的从数据库作为新的主数据库,能够减少从数据库切换次数,以保证正常的访问。
在本实施例中,如果对从数据库A、从数据库B和从数据库C所在服务器分别计算得到的可用性评分为:80分、70分、60分。在执行本步骤时,则选取分值最高的服务器上的从数据库A作为新的主数据库。
需要说明地是,在各从数据库所在服务器的可用业务承载能力的确定过程中,作为选择依据的使用状态信息中各参数的种类、数量均可根据实际情况调整。例如,使用前文提及的所有参数综合考虑进行从数据库的选择时,发现不存在这样的从数据库,那么可以通过利用部分参数退而选择较优的从数据库。
在选定新的主数据库后,执行步骤S304,使用选择出的从数据库替换发生故障的主数据库,以作为新的主数据库。
本步骤仍以选定从数据库A作为新的主数据库为例,为了更加清楚地体现主数据库切换前、后的不同,还提供了图4,图4为切换主数据库后的Redis数据库的架构示意图。其中,原从数据库A切换后作为新的主数据库A,从数据库B和C由于可用业务承载能力不足,仍然作为从数据库使用。
上述步骤S301至步骤S304的描述,体现了当主数据库发生故障时,选取一从数据库作为新的主数据库的过程。在选取了新的主数据库之后,为了确保数据的良好衔接,继续执行步骤S305,确定新的主数据库中存储的数据量,以及新的主数据库与从数据库间的网络状态。
由于在Redis数据库中,要求所有从数据库的数据与主数据库的数据相同,因此,在切换至新的主数据库后,还需执行数据的同步操作,以保证数据的完整。但是,存在如下情况,在进行同步时会导致主数据库的处理压力较大:
从数据库的数量较多时;
主数据库的数据存储量较大时;
主数据库与从数据库间的网络状态不佳时。
例如,当主数据库中存储有30G数据,且具有6个从数据库时,需要向这6个从数据库中的每一个从数据库同步这30G数据,由于数据存储量较大,在数据同步时就会造成主数据库处理其他业务的能力下降,影响用户体验,尤其是在网络状态不佳的情况下。
若主数据库中存储的数据只有2G,且只具有2个从数据库时,则对于主数据库而言,其向从数据库同步数据的压力就小得多。
因此,在本发明实施例中,可根据新的主数据库中存储的数据量,以及新的主数据库与从数据库间的网络状态动态调整当前的数据同步方式,以保证其他数据处理操作的正常运行。
为了确保主数据库数据同步时的处理压力过大,接着执行步骤S306,在步骤S306中,根据新的主数据库的数据量,以及网络状态,确定每次可挂载的从数据库的数量。
其中,网络状态至少包括网卡的数据传输速率,因此,结合新的主数据库的数据量,以及网络状态,确定每次可挂载的从数据库的数量,可以按照如下方式执行:
首先,利用新的主数据库的数据量除以网卡的数据传输速率,得到新的主数据库的数据量同步一次的所需时间。
然后,根据新的主数据库数据同步至所有从数据库的时间限制以及上述的所需时间,确定完成所有同步操作所需同步总次数。
最后,利用同步总次数对所有从数据库进行分批处理,确定每次可挂载的从数据库的数量。
下面进行举例说明,例如当前主数据库中存储有30G数据,且具有6个从数据库时,则可以选择每次只挂载两个从数据库,也即对两个从数据库的中的数据进行同步。
若主数据库中存储的数据只有2G,只具有2个从数据库时,则可以直接一次性的将全部从数据库同步完成。
可见,选择适当数量的从数据库进行数据同步,保证了数据同步的速度,同时也保证了其他数据处理操作的正常运行。
在确定了每次可挂载的从数据库数量之后,执行步骤S307,根据确定的从数据库数量,分批次实现新的主数据库到剩余其他从数据库的数据同步。
本发明实施例提供了一种数据库的故障处理方法,通过在主数据库发生故障时,收集其从数据库所在服务器的使用状态信息,并通过使用状态信息确定各个从数据库所在服务器的可用业务承载能力,选择其中可用业务承载能力最好的服务器对应的从数据库作为新的主数据库。通过本发明实施例所提供的方法,当主数据库发生故障无法提供服务时,可以选择业务承载能力最好的服务器上的从数据库作为新的主数据库,从而避免了由于新的主数据库选择不当造成宕机(服务中断)或者运行效率低下的问题。
实施例三
图5是本发明一个实施例提供的一种数据库的故障处理装置的结构框图,应用于具有主从结构的数据库集群,该装置500包括:
信息收集模块510,适于检测到主数据库发生故障时,收集主数据库所在服务器对应的至少一个从数据库的使用状态信息;
信息分析模块520,适于对各从数据库所在服务器的使用状态信息进行分析,确定出各从数据库所在服务器的可用业务承载能力;
从数据库选择模块530,适于对各从数据库所在服务器的可用业务承载能力进行比较,选择出其中可用业务承载能力最大的从数据库;以及
替换模块540,适于使用选择出的从数据库替换发生故障的主数据库,以作为新的主数据库。
可选地,上述装置500还包括:
数据同步模块550,适于将新的主数据库中的数据同步至剩余的其他从数据库中。
可选地,数据同步模块550还适于:
确定新的主数据库中存储的数据量,以及新的主数据库与剩余的其他从数据库间的网络状态;
根据新的主数据库的数据量,以及网络状态,确定每次可挂载的从数据库的数量;以及
根据确定的从数据库的数量,分批次实现新的主数据库到剩余的其他从数据库的数据同步。
可选地,网络状态至少包括网卡的数据传输速率。
可选地,数据同步模块550还适于:
利用新的主数据库的数据量除以网卡的数据传输速率,得到新的主数据库的数据量同步一次的所需时间;
根据新的主数据库数据同步至所有从数据库的时间限制以及上述的所需时间,确定完成所有同步操作所需同步总次数;
利用同步总次数对所有从数据库进行分批处理,确定每次可挂载的从数据库的数量。
可选地,从数据库所在服务器的使用状态信息包括以下参数至少之一:
从数据库所在服务器的当前负载;
从数据库所在服务器的内存剩余量;
从数据库所在服务器的可用性;
从数据库所在服务器上的业务数;
从数据库所在服务器上不同业务的互相影响性;
从数据库所在服务器支持的数据读写速率;以及
从数据库所在服务器支持的网卡数据传输速率。
可选地,信息分析模块520还适于:
为所述使用状态信息中的各参数设置不同权值以及权值比重;
计算得到各从数据库所在服务器的使用状态信息中各参数的权值总值,将其作为各从数据库所在服务器的可用业务承载能力指标。
可选地,信息分析模块520还适于:
比较各从数据库所在服务器的使用状态信息中各参数的权值总和,选择出其中最大权值总和对应的从数据库。
可选地,所述主数据库和从数据库皆为内存型数据库,更具体地,所述主数据库和从数据库皆为Redis数据库。
本发明实施例提供了一种数据库的故障处理装置,通过在主数据库发生故障时,收集其从数据库所在服务器的使用状态信息,并通过使用状态信息确定各个从数据库所在服务器的可用业务承载能力,选择其中可用业务承载能力最好的服务器上的从数据库作为新的主数据库。通过本发明实施例所提供的装置,当主数据库发生故障无法提供服务时,可以选择业务承载能力最好的服务器对应的从数据库作为新的主数据库,从而避免了由于新的主数据库选择不当再次造成宕机(服务中断)或者运行效率低下的问题。
本发明实施例还提供了一种数据库系统,该系统包括:一个主数据库,多个从数据库,还包括上述的数据库的故障处理装置500。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的数据库的故障处理装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
至此,本领域技术人员应认识到,虽然本文已详尽示出和描述了本发明的多个示例性实施例,但是,在不脱离本发明精神和范围的情况下,仍可根据本发明公开的内容直接确定或推导出符合本发明原理的许多其他变型或修改。因此,本发明的范围应被理解和认定为覆盖了所有这些其他变型或修改。

Claims (15)

1.一种数据库的故障处理方法,应用于具有主从结构的数据库集群,包括:
检测到主数据库发生故障时,收集所述主数据库对应的至少一个从数据库所在服务器的使用状态信息;
对各从数据库所在服务器的使用状态信息进行分析,确定出各从数据库所在服务器的可用业务承载能力;
对各从数据库所在服务器的可用业务承载能力进行比较,选择出其中可用业务承载能力最大的服务器对应的从数据库;以及
使用选择出的从数据库替换发生故障的主数据库,以作为新的主数据库;
其中,所述对各从数据库所在服务器的使用状态信息进行分析,确定出各从数据库所在服务器的可用业务承载能力,包括:
为所述使用状态信息中的各参数设置不同权值以及权值比重;以及
计算得到各从数据库所在服务器的使用状态信息中各参数的权值总和,将其作为各从数据库所在服务器的可用业务承载能力指标;
所述使用选择出的从数据库替换发生故障的主数据库,以作为新的主数据库之后,还包括:
确定所述新的主数据库中存储的数据量,以及所述新的主数据库与剩余的其他从数据库间的网络状态;
根据所述新的主数据库的数据量,以及所述网络状态,确定每次可挂载的从数据库的数量;以及
根据确定的从数据库的数量,分批次实现所述新的主数据库到剩余的其他从数据库的数据同步。
2.根据权利要求1所述的方法,其中,所述网络状态至少包括网卡的数据传输速率。
3.根据权利要求2所述的方法,其中,根据所述新的主数据库的数据量,以及所述网络状态,确定每次可挂载的从数据库的数量,包括:
利用所述新的主数据库的数据量除以所述网卡的数据传输速率,得到所述新的主数据库的数据量同步一次的所需时间;
根据所述新的主数据库数据同步至所有从数据库的时间限制以及上述所需时间,确定完成所有同步操作所需同步总次数;以及
根据所述同步总次数对所有从数据库进行分批处理,确定每次可挂载的从数据库的数量。
4.根据权利要求1至3任一项所述的方法,其中,所述从数据库所在服务器的使用状态信息包括以下参数至少之一:
从数据库所在服务器的当前负载;
从数据库所在服务器的内存剩余量;
从数据库所在服务器上的业务数;
从数据库所在服务器上不同业务的互相影响性;
从数据库所在服务器支持的数据读写速率;以及
从数据库所在服务器支持的网卡数据传输速率。
5.根据权利要求1所述的方法,其中,对各从数据库所在服务器的可用业务承载能力进行比较,选择出其中可用业务承载能力最大的服务器对应的从数据库,包括:
比较各从数据库所在服务器的使用状态信息中各参数的权值总和,选择出其中最大权值总和对应的从数据库。
6.根据权利要求1至3任一项所述的方法,其中,所述主数据库和从数据库皆为内存型数据库。
7.根据权利要求6所述的方法,其中,所述主数据库和从数据库皆为Redis数据库。
8.一种数据库的故障处理装置,应用于具有主从结构的数据库集群,包括:
信息收集模块,适于检测到主数据库发生故障时,收集所述主数据库对应的至少一个从数据库所在服务器的使用状态信息;
信息分析模块,适于对各从数据库所在服务器的使用状态信息进行分析,确定出各从数据库所在服务器的可用业务承载能力;
从数据库选择模块,适于对各从数据库所在服务器的可用业务承载能力进行比较,选择出其中可用业务承载能力最大的服务器对应的从数据库;以及
替换模块,适于使用选择出的从数据库替换发生故障的主数据库,以作为新的主数据库;
其中,所述信息分析模块还适于:
为所述使用状态信息中的各参数设置不同权值以及权值比重;以及
计算得到各从数据库所在服务器的使用状态信息中各参数的权值总值,将其作为各从数据库所在服务器的可用业务承载能力指标;
其中,所述装置还包括:
数据同步模块,适于确定所述新的主数据库中存储的数据量,以及所述新的主数据库与剩余的其他从数据库间的网络状态;
根据所述新的主数据库的数据量,以及所述网络状态,确定每次可挂载的从数据库的数量;以及
根据确定的从数据库的数量,分批次实现所述新的主数据库到剩余的其他从数据库的数据同步。
9.根据权利要求8所述的装置,其中,所述网络状态至少包括网卡的数据传输速率。
10.根据权利要求9所述的装置,其中,所述数据同步模块还适于:
利用所述新的主数据库的数据量除以所述网卡的数据传输速率,得到所述新的主数据库的数据量同步一次的所需时间;
根据所述新的主数据库数据同步至所有从数据库的时间限制以及上述所需时间,确定完成所有同步操作所需同步总次数;以及
根据所述同步总次数对所有从数据库进行分批处理,确定每次可挂载的从数据库的数量。
11.根据权利要求8至10任一项所述的装置,其中,所述从数据库所在服务器的使用状态信息包括以下参数至少之一:
从数据库所在服务器的当前负载;
从数据库所在服务器的内存剩余量;
从数据库所在服务器上的业务数;
从数据库所在服务器上不同业务的互相影响性;
从数据库所在服务器支持的数据读写速率;以及
从数据库所在服务器支持的网卡数据传输速率。
12.根据权利要求8所述的装置,其中,所述信息分析模块还适于:
比较各从数据库所在服务器的使用状态信息中各参数的权值总和,选择出其中最大权值总和对应的从数据库。
13.根据权利要求8至10任一项所述的装置,其中,所述主数据库和从数据库皆为内存型数据库。
14.根据权利要求13所述的装置,其中,所述主数据库和从数据库皆为Redis数据库。
15.一种数据库系统,包括一个主数据库,多个从数据库,还包括:权利要求8-14任一项所述的数据库的故障处理装置。
CN201510250730.1A 2015-05-15 2015-05-15 数据库的故障处理方法、装置和数据库系统 Expired - Fee Related CN104866556B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510250730.1A CN104866556B (zh) 2015-05-15 2015-05-15 数据库的故障处理方法、装置和数据库系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510250730.1A CN104866556B (zh) 2015-05-15 2015-05-15 数据库的故障处理方法、装置和数据库系统

Publications (2)

Publication Number Publication Date
CN104866556A CN104866556A (zh) 2015-08-26
CN104866556B true CN104866556B (zh) 2019-07-23

Family

ID=53912382

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510250730.1A Expired - Fee Related CN104866556B (zh) 2015-05-15 2015-05-15 数据库的故障处理方法、装置和数据库系统

Country Status (1)

Country Link
CN (1) CN104866556B (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106372115A (zh) * 2016-08-23 2017-02-01 成都乾威科技有限公司 一种数据读写方法、系统及数据库系统
CN106383861A (zh) * 2016-08-31 2017-02-08 网易(杭州)网络有限公司 一种用于数据库的数据同步方法及装置
CN107330035B (zh) * 2017-06-26 2020-08-07 宁波图灵奇点智能科技有限公司 一种数据库中操作日志同步方法、移动终端以及计算机可读存储介质
CN110413685B (zh) * 2019-04-12 2024-03-12 财付通支付科技有限公司 数据库服务切换方法、装置、可读存储介质和计算机设备
CN113495798A (zh) * 2020-03-20 2021-10-12 深圳市理邦精密仪器股份有限公司 一种基于信息化终端的选定服务器方法与系统
CN111949402A (zh) * 2020-08-05 2020-11-17 中国建设银行股份有限公司 数据库请求处理方法、装置、计算机设备及存储介质
CN112015595B (zh) * 2020-08-28 2021-03-02 掌阅科技股份有限公司 主从数据库的切换方法、计算设备及存储介质
CN113301380B (zh) * 2021-04-23 2024-03-12 海南视联通信技术有限公司 一种业务管控方法、装置、终端设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103580883A (zh) * 2012-07-19 2014-02-12 中兴通讯股份有限公司 一种业务容灾方法及系统
CN104516966A (zh) * 2014-12-24 2015-04-15 北京奇虎科技有限公司 一种数据库集群的高可用解决方法和装置
CN104537046A (zh) * 2014-12-24 2015-04-22 北京奇虎科技有限公司 数据补全方法和装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080189340A1 (en) * 2007-02-01 2008-08-07 David Randall Blea Apparatus, system, and method for synchronizing a remote database
CN104424275A (zh) * 2013-08-29 2015-03-18 中兴通讯股份有限公司 数据库系统以及数据同步方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103580883A (zh) * 2012-07-19 2014-02-12 中兴通讯股份有限公司 一种业务容灾方法及系统
CN104516966A (zh) * 2014-12-24 2015-04-15 北京奇虎科技有限公司 一种数据库集群的高可用解决方法和装置
CN104537046A (zh) * 2014-12-24 2015-04-22 北京奇虎科技有限公司 数据补全方法和装置

Also Published As

Publication number Publication date
CN104866556A (zh) 2015-08-26

Similar Documents

Publication Publication Date Title
CN104866556B (zh) 数据库的故障处理方法、装置和数据库系统
CN102831052B (zh) 测试用例自动化生成装置及方法
CN105653630B (zh) 分布式数据库的数据迁移方法与装置
CN105426310B (zh) 一种检测目标进程的性能的方法和装置
EP2902908A1 (en) System operation trace method in distributed system
CN107015902B (zh) 一种测试方法和设备
US10395400B2 (en) Display method of information indicating an operating status of a manufacturing system
CN110321383A (zh) 大数据平台数据同步方法、装置、计算机设备及存储介质
CN106557308B (zh) 一种软件持续集成方法及装置
CN107423097A (zh) 一种应用程序的管理方法和装置
CN106980571A (zh) 一种测试用例集的构建方法和设备
CN106909568A (zh) 一种数据库集群主数据库的切换方法及装置
CN109040191A (zh) 文件下载方法、装置、计算机设备和存储介质
CN109408361A (zh) Monkey测试复原方法、装置、电子设备及计算机可读存储介质
CN103390288A (zh) 三维渲染文件批量拆分渲染层处理系统
AU2016203921A1 (en) Method and system for facilitating access to recorded data
CN106201810A (zh) 一种测试方法、装置
CN107544894B (zh) 一种日志处理的方法、装置及服务器
CN113032281A (zh) 一种代码覆盖率实时获取方法及装置
CN105074668B (zh) 测试设计辅助装置和测试设计辅助方法
CN109767546B (zh) 有价票据的质量核查调度装置和质量核查调度方法
CN114153732A (zh) 故障场景测试方法、装置、电子设备及存储介质
CN113656210A (zh) 报错信息的处理方法、装置、服务器和可读存储介质
CN106293929A (zh) 一种数据处理方法及第一电子设备
CN111400117A (zh) 一种自动化测试Ceph集群的方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
EXSB Decision made by sipo to initiate substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20220718

Address after: Room 801, 8th floor, No. 104, floors 1-19, building 2, yard 6, Jiuxianqiao Road, Chaoyang District, Beijing 100015

Patentee after: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Address before: 100088 room 112, block D, 28 new street, new street, Xicheng District, Beijing (Desheng Park)

Patentee before: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Patentee before: Qizhi software (Beijing) Co.,Ltd.

CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20190723