CN111459903A - 数据库管理系统及方法 - Google Patents
数据库管理系统及方法 Download PDFInfo
- Publication number
- CN111459903A CN111459903A CN201910055160.9A CN201910055160A CN111459903A CN 111459903 A CN111459903 A CN 111459903A CN 201910055160 A CN201910055160 A CN 201910055160A CN 111459903 A CN111459903 A CN 111459903A
- Authority
- CN
- China
- Prior art keywords
- server
- database
- management server
- management
- 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.)
- Pending
Links
Images
Landscapes
- Hardware Redundancy (AREA)
Abstract
本申请公开了一种数据库管理系统及方法,该系统包括:第一管理服务器,该第一管理服务器包括:检测模块,用于通过java数据库连接检测第一管理服务器所管理的该数据库集群中的主服务器的连通性、主服务器所在的物理主机的连通性和/或主服务器的数据库实例的连通性;切换模块,用于基于该检测模块的检测结果将该数据库集群中的从服务器切换为该数据库集群的主服务器。本申请实施例利用java数据库连接,完成管理服务器与所管理的数据库集群中数据库的直接交互,无需在数据库实例中部署代理服务,实现了在主从服务器上部署有多个数据库实例的数据库集群的管理,实现了数据库架构的扩展。
Description
技术领域
本申请一般涉及数据库运维管理技术领域,具体涉及一种数据库管理系统及方法。
背景技术
随着企业规模的壮大和业务形式的复杂化,企业内部对数据库管理能力和存储能力要求越来越高。SSD架构的高可用数据库架构(MySQL HA)与传统的甲骨文(oracle)数据库架构和存储网络(SAN)的存储性能相比,MySQL HA的存储性能更优。
高可用数据库架构要求一个数据库集群中必须最少有三台数据库服务器,一主二从,即一台充当主服务器,一台充电备用服务器,另外一台充当从服务器。并要求配置一台管理服务器,即一个管理服务(MHA-manger)节点,且在数据库集群中的为每个数据库实例配置一个代理服务节点,即MHA-agent。管理服务器利用每个实例的MHA-agent与每个数据库进行数据交互,具体利用每个数据库实例所在的物理机的IP来标识不同的实例,实现所有数据库集群的管理。
由于所有的数据库集群利用配置的MHA-manger及MHA-agent来管理,当一台物理主机上需要部署多个数据库实例时,使得物理机主上对应的部署多个MHA-agent,导致数据库架构不灵活。
发明内容
鉴于现有技术中的上述缺陷或不足,期望提供一种数据库管理系统及方法,以实现数据库的高效灵活管理。
第一方面,本申请提供一种数据库管理系统,该系统包括:第一管理服务器,该第一管理服务器用于管理预先分配的至少一个数据库集群,该数据库集群包括主服务器和从服务器,该主服务器及该从服务器上配置有至少一个数据库实例,其中,
该第一管理服务器包括:
检测模块,用于通过java数据库连接检测第一管理服务器所管理的该数据库集群中的主服务器的连通性、主服务器所在的物理主机的连通性和/或主服务器的数据库实例的连通性;
切换模块,用于基于该检测模块的检测结果,在主服务器不正常时,将该数据库集群中的从服务器切换为该数据库集群的新的主服务器。
第二方面,本申请实施例提供一种数据库管理方法,该方法包括:
第一管理服务器通过java数据库连接检测其管理的预先分配的至少一个数据库集群中的主服务器的连通性、主服务器所在的物理主机的连通性和/或主服务器的数据库实例的连通性,数据库集群包括主服务器和从服务器,主服务器及从服务器上配置有至少一个数据库实例;
基于检测结果,在主服务器不正常时,将数据库集群中的从服务器切换为数据库集群的新的主服务器。
综上,本申请实施例提供的数据库管理系统,通过在管理服务器上设置用于管理数据库集群的检测模块及切换模块,使得检测模块利用java数据库连接,检测所管理的数据库集群中的主服务器的连通性、所在的物理主机的连通性和/或数据库实例的连通性,进而使得切换模块根据检测模块的检测结果,完成主从服务器的切换,利用java数据库连接,实现了管理服务器与管理的数据库集群中数据库的直接交互,无需在数据库实例中部署代理服务,实现了在物理主机上部署有多个数据库实例的数据库集群的管理,实现了数据库架构的扩展。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:
图1为MySQL集群的结构示意图;
图2为本申请的实施例的数据库管理系统的结构示意图;
图3为本申请的又一实施例的数据库管理系统的结构示意图;
图4为本申请的实施例的数据库管理方法的流程示意图;
图5为本申请的又一实施例的数据库管理方法的流程示意图;
图6为本申请实施例的主服务器检测方法的流程示意图;
图7为本申请实施例的主从服务器切换方法的流程示意图;
图8为本申请的实施例的数据库集群分配方法的结构示意图;
图9为本申请的实施例的服务器的计算机系统的结构示意图。
具体实施方式
下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释相关申请,而非对该申请的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与申请相关的部分。
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
可以理解,MySQL集群框架中,如图1所示,在管理服务器上部署管理服务(MHA-manger),在每个数据库服务器上,为每个数据库实例部署有一个代理服务(MHA-agent)。在管理服务器进行多个数据库集群管理时,通过管理服务器上的MHA-manger与数据库服务器上的数据库实例对应的MHA-agent进行数据交互,以探测数据库实例是否正常。在交互中,每个MHA-agent利用其所在的物理主机的IP与MHA-manger进行通信,以区别不同的数据库实例。
为了解决上述数据库架构不灵活的问题,本申请实施例涉及的数据库管理,管理服务器上部署有管理服务,但是不需要在数据库集群中,为每个数据库实例部署代理服务,管理服务器直接通过Java数据库连接与其所管理的数据库进行通信。
可以理解,本申请中的管理服务器所管理的至少一个数据库集群是预先分配的,如可以在搭建数据库架构时,数据库运维人员为每个管理服务器分配数据库集群。还可以如下述实施例所述的场景中,在数据库架构运行过程中,当部分管理服务器发生故障时,接管主管理服务器分配的发生故障的管理服务器的数据库集群。
还可以理解,本申请实施例中,管理服务器与MySQL数据库架构中的存储服务器连接,该存储服务器用于存储管理服务器所管数据库集群列表,并存储每个数据库集群的状态信息。管理服务器在管理数据库集群时,可以读取该存储服务器提供的数据库集群信息,完成数据库集群管理。
本申请实施例涉及的数据库管理系统,为了实现每个物理主机上部署多个数据库实例,且方便每个数据库实例的管理,在数据库管理服务器中设置了检测模块及切换模块,使得检测模块及切换模块可以通过java数据库连接直接与部署在每个物理主机上的数据库实例进行数据交互,从而避免了通过管理服务与代理服务的数据交互。
为了便于理解和说明,下面通过图2至图9详细的阐述本申请实施例提供的数据库管理系统及方法。
请参考图2,图2示出了本申请实施例的数据库管理系统的结构示意图。
如图2所示,该系统200可以包括:
第一管理服务器,该第一管理服务器用于管理预先分配的至少一个数据库集群,每个数据库集群包括一个主服务器及至少一个从服务器,该主服务器及该从服务器上配置有至少一个数据库实例,其中,
该第一管理服务器包括:
检测模块210,用于通过java数据库连接检测第一管理服务器管理的集群中的主服务器的连通性、主服务器所在的物理主机的连通性和/或主服务器的数据库实例的连通性;
切换模块220,用于基于检测模块的检测结果,将该数据库集群中的从数据库服务器切换为主数据库服务器。
具体的,本申请实施例提供的数据库管理系统,可以包括一个数据库管理服务器,即第一管理服务器,可以利用该第一管理服务器来管理至少一个数据库集群,如图2所示的数据库集群1至数据库集群n。每个数据库集群中部署有一个主服务器和至少一个从服务器。即利用管理服务器上的检测模块,检测所管理的数据库集群中的主服务器是否正常,如检测主服务器的连通性、主服务器所在的物理主机的连通性和/或主服务器的数据库实例的连通性。在检测到某个数据库集群的主服务器不正常时,如主服务无法连接、主服务器所在的物理主机故障和/或主服务器的数据库实例不连通时,可以利用切换模块,从该数据库集群中的从服务器中选择一个正常的服务器作为备选主服务器,并将该备用主服务器切换为该集群的主服务器,以确保数据库的可用。
在检测模块检测所管理的数据库集群中的主服务器是否正常时,可以通过检测主服务器的连通性、主服务器所在的物理主机的连通性和/或主服务器的数据库实例的连通性来判断该主服务是否正常。切换模块可以根据检测模块的检测结果,确定是否需要进行主从切换。
例如,当检测到数据库连通时,表示主服务器正常,不需要切换;当检测到数据库不连通,且检测到物理主机不可登录时,则表示主服务器不正常,需要切换。
本申请实施例中,在管理服务器通过检测模块及切换模块管理数据库集群时,检测模块及切换模块可以利用JDBC(Java Data Base Connectivity,java数据库连接)来实现管理服务器及数据库的数据交互,以检测数据库集群中的主服务器是否正常,并在不正常时完成切换。
可以理解,JDBC是一种用于执行SQL语句的Java API,可以为多种关系数据库提供统一访问,它由一组用Java语言编写的类和接口组成。
优选的,本申请实施例提供的数据库管理系统,该检测模块210具体可以包括:
创建单元211,用于与待检测数据库集群的主服务器建立JDBC连接。
具体的,管理服务器,即作为manger的服务器,可以为分布式数据管理系统中的一个应用节点,如ThinkDB管理平台中的管理服务器。该管理服务器可以与其管理的每个数据库集群的主服务器建立JDBC连接,从而可以通过建立的JDBC实现与每个数据库集群中的数据库的数据交互。
第三检测单元212,用于利用JDBC连接检测与该主服务器对应的通讯接口是否可以连通。
具体的,在管理服务器对数据库集群进行管理时,首先可以利用JDBC连接检测数据库的通讯接口是否连通,如可以检测ddcs接口是否失效。
如果检测发现通讯接口可以连通,则可以利用读取单元213,从缓存在管理服务器中缓存读取数据库集群的状态信息,如从管理服务器中的H2dB中读取。如果不连通,则可以从存储服务器中读取数据库集群的状态信息,如存储服务器中ddcs数据库。
可以理解,该状态信息可以指示该数据库集群的当前状态,如处于运行中或处于维护中。当状态信息表示该数据库集群当前处于维护状态时,可以退出该检测动作。或者,还可以生成警告信息,以提示数据库运维人员来处理。
当该数据库集群当前处于运行状态时,可以继续执行检测动作。即可以利用第三检测单元检测主服务器上的数据库是否可以连通。
当检测到主服务器上的数据库当检测到数据库连通时,则可以进一步判断主服务器是否可写,如果不可写,则需要将主服务器设置为可写状态,并当检测到主服务器可写或设置为可写状态后,可以检测该数据库集群中的从服务器的节点逻辑,即可以检测该主服务器下是否挂有从服务器,且挂有哪些从服务器,即数据库集群的拓扑结构。
当检测到主服务器的数据库不连通时,则进一步检测主服务器的长连接是否有效。
可以理解,在管理服务器和数据库集群之间部署有一个JDBC线程,即长连接。在第三检测单元检测主服务器是否可用时,当检测到数据库不连通时,需要利用探测命令检测该线程是否仍有效。
如果检测到主服务器长连接有效,则可以进入上述检测数据库集群中的从服务器的节点逻辑的程序,该检测逻辑结束。
进一步的,当检测到主服务器的长连接无效时,则可以检测主服务器所在的物理主机是否可以登录。
例如,可以调用status接口,利用探测命令查看物理主机是否在线,可能因网络故障或宕机等情况,导致物理主机无法连接。
可以理解,当第三检测单元检测到物理主机不可的登录时,则可以利用切换模型,进行主服务器及从服务器的切换,该检测逻辑结束。
进一步的,如果物理主机可以登录,则第三检测单元还需要检测主服务器的数据库实例是否存活。
即当检测到主服务器所在的物理主机可登录时,可以检测主服务器上的数据库实例是否存活,如可以用探测命令查看,如果在预设时间内有返回结果,则表示数据库实例存活。
可以理解,当该第三检测单元检测到数据库实例不存活,且检测的次数达到预设值时,则可以利用激活单元214,调用开始接口,执行激活命令来激活该数据库实例。
当测到数据库实例存活,可以再重复检测主服务器的数据库是否连通。
当检测到主服务器的数据库连通时,同样可以进入检测数据库集群中的从服务器的节点逻辑的程序。当检测到主服务器的数据库不连通时,可以进行多次的检测,并可以对检测次数进行计数。
如果当进行多次检测,仍发现数据库不连通时,且重新检测的次数大于预设值时,则仍需要利用激活单元,调用开始接口,执行激活命令来激活该数据库实例。
同样的,可以对该数据库实例进行多次的激活尝试,且当激活次数大于预设值时,仍未成功时,则结束尝试,并执行主服务器和从服务器的切换。
可以理解,当激活单元成功激活数据库实例时,则可以进一步利用第三检测单元执行检测数据库连通性的程序。如果连通,可以进入检测数据库集群中的从服务器的节点逻辑的程序。否则,执行主服务器和从服务器的切换。
该切换模块220,可以根据检测模块210的检测结果,执行数据库集群中主服务器和从服务器的切换,具体可以包括:
选择单元221,用于从数据库集群中的从服务器中选择一个服务器,作为备选主服务器。
具体的,当经过管理服务器中的检测模块检测,发现其管理的某个数据库集群中的主服务器出故障,如物理主机不可登录,或数据库实例不存活时,或数据库实例激活成功后,数据库仍不连通时,则需要在该数据库集群中的至少一个从服务器中选择一个服务器,即slave节点所在的服务器作为备选主服务器,以将该服务器切换为该数据库集群的主服务器。例如,可以从产品需求文档(PRD)中选择一个备选主服务器。
第四检测单元222,用于检测该备选主服务器的数据库的连通性。
具体的,在利用选择单元选择了一个从服务器作为备选主服务器后,可以检测该备选主服务器的数据库的连通性。
可选的,当检测发现该从服务器的数据库不连通时,可以进行多次的检测,如果检测次数大于预设值后,该服务器的数据库仍不连通,则表示该从服务器不可用,则退出当前的切换逻辑。
进一步的,当第四检测单元检测发现作为备选主服务器的从服务器的数据库连通时,则可以检测该从服务器的域名系统(Domain Name System,DNS)是否合法。如可以利用检测命令,检测该从服务器的DNS是否符合预设规则。同样的,为了确保准确性,可以进行多次检测,当检测的次数大于预设值时,其检测结果仍表示该DNS不合法,则表示该从服务器不可用,不满足切换条件,则退出当前的切换逻辑。
第三判断单元224,用于当该域名系统合法时判断该数据库实例是否可用。
具体的,当该从服务器的DNS合法时,可以进一步判断从服务器的数据实例是否可用,如可以利用判断进程探测该数据库实例是否存活。
获取单元225,用于当该数据库实例可用时获取该备选主服务器与其他从服务器的延时时间。
第四判断单元226,用于判断该延时时间是否小于预设值。
具体的,在获取该从服务器,即备选主服务器与其他从服务器的延时时间时,获取单元可以利用JDBC分别向备选主服务器及其他从服务器发送检测命令,并接收备选主服务器及其他从服务器返回的探测结果,则可以确定备选主服务器及其他从服务器各自的延时时间,然后可以计算备选主服务器与其他从服务器的延时时间的差值,即slave节点延后master节点的gtid差值。进一步可以判断该差值以及其他从服务器的延时时间是否小于预设值。如果两者都小于预设值,则表示该备选主服务器满足切换条件,如果两者之中有一个不小于预设值,则表示该备选主服务器不满足切换条件。
切换单元227,用于当该延时时间小于该预设值时,将该备选主服务器的域名系统设置为主数据库服务器的域名系统。
具体的,在经过上述单元检测或判断发现该备选主服务器满足切换条件时,可以执行切换动作,利用该备选主服务器替换旧的主服务器,并成为新的主服务器。如首先可以停止该备选主服务器上当前执行的进程,然后可以将该数据库集群的主服务器对应的DNS由原来的故障服务器的DNS替换为该被选主服务器的DNS,即将该被选主服务器的IP与该数据库集群的新的主服务器对应的DNS绑定,从而可以利用该DNS访问该数据库集群中的数据库。
可选的,在执行完DNS切换后,还可以将该切换后的主服务器设置为可写状态,并将旧的主服务器的进程同步到新的主服务器上,进一步更新该数据库集群的状态信息。
进一步的,利用JDBC判断该新的主服务器对应的通讯接口是否有效,如果有效,则直接更新旧的服务器的数据库,否则,更新缓存。
本申请实施例提供的数据库管理系统,无需在数据库集群的数据库实例上部署代理服务,使得第一管理服务器通过利用JDBC与数据库集群中的数据库直接通讯,即使得管理服务器无需通过数据库所在的服务器上的代理服务来进行数据库管理,实现数据库所在的主服务器性能的检测,以及根据检测结果实现主从服务器的切换。使得基于JDBC实现数据库管理的数据库集群,能够支持MySQL集群架构SIT/SGT环境中1主+1从、1主+3从及扩展至的1主+多从等架构,可以在一个物理主机上部署多个MySQL数据库实例,克服了性能瓶颈。
进一步,本申请实施例为了解决一个管理服务器的数据库架构下存在的单点故障的问题,即当管理所有数据库集群的管理服务器出现故障时,将使得整个数据库集群不可用的问题,提供了如图3所示的包括多个管理服务器的数据库管理系统。
图3为本申请又一实施例提供的数据库管理系统的结构示意图,如图3所示,该系统300可以包括:
第一管理服务器、至少一个第二管理服务器及存储服务器,即该系统中包括多个管理服务器310及存储服务器320。可以理解,该系统中,第一管理服务器和第二管理服务器只是为了便于描述,多个管理服务器中的任一个管理服务器可以为第一管理服务器,其他的则可以为第二管理服务器。所有的管理服务器中,可以有一个管理服务器作为当前的主管理服务器(即ThinkDB中的主节点),则其他的管理服务作为当前的非主管理服务器(即ThinkDB中的非主节点)。如一个第二管理服务作为当前的主管理服务器,其他的第二管理服务和第一管理服务作为当前的非主管理服务器。该系统中的每个主或非主管理服务器用于管理该系统中的部分数据库集群中,即每个管理服务器负责管理一个或多个数据库集群。每个数据库集群包括主服务器及从服务器,主服务器及从服务器上配置有至少一个数据库实例,该主管理服务器可用于协调所有数据库集群的管理任务。
例如,图3中,管理服务器1可以为第一管理服务器,其余的管理服务器作为第二管理服务器,并且,假如管理服务器2为当前的主管理服务器,其他的管理服务为当前的非主管理服务器。
可以理解,本申请实施例提供的数据库管理系统,每个管理服务器都需要向存储服务器320更新其心跳时间。
具体的,该MySQL数据库系统中,设置有一个存储服务器,每个管理服务器,即ThinkDB应用节点与该存储服务器通过JDBC连接,即可以通过JDBC与该存储服务器进行数据交互。
在数据交互中,所有的管理服务器可以在存储服务器中更新自身的心跳时间。
例如,对于作为主管理服务器的第二管理服务器,可以利用如下的心跳表实现心跳时间的更新:
CREATE TABLE`tt_ha_node_heartbeat`(`node_name`varchar(50)NOT NULLCOMMENT',Thinkdb应用节点部署IP';
`last_heartbeat`timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ONUPDATE CURRENT_TIMESTAMP COMMENT'最后心跳时间';
`env`varchar(20)DEFAULT'SIT'COMMENT'部署环境';
PRIMARY KEY(`node_name`))ENGINE=InnoDB DEFAULT CHARSET=utf8mb4COMMENT='thinkdb应用节点心跳表。
对于作为非主管理服务器的其他的第二管理服务器及第一管理服务器,可以利用如下的心跳表实现心跳时间的更新:
CREATE TABLE`tt_ms_appha_config`(`node_name`varchar(36)NOT NULLCOMMENT'M-S监控程序leader节点ip';
`env`varchar(20)DEFAULT'SIT'COMMENT'部署环境';
PRIMARY KEY(`node_name`))ENGINE=InnoDB DEFAULT CHARSET=utf8mb4COMMENT='M-S监控程序应用HA表'。
由上述心跳表可知,主管理服务器和每个非主管理服务器可以在预设的时间间隔内更新自己的心跳时间。
还可以理解,在数据库架构搭建时,可以初步设置一个主管理服务器,用于管理其他的非主管理服务器,并为每个管理服务器分配至少一个数据库集群。在多个管理服务器运行过程中,如果设置的主管理服务器心跳停止,即出现故障,则其他的非主管理服务器可以竞争成为主管理服务器,并在某个非主管理服务器竞争成功后,可以接管出故障的主管理服务器的任务。或者,其中任一个非主管理服务器出现故障后,当前的主管理服务器可以将该故障的非主管理服务器所管理的数据库集群分配到其他的非主管理服务器上,从而克服了单点故障的问题。
在该实施例中,每个管理服务器可以包括检测模块311、切换模块312、接管模块313及分配模块314。
具体的,该检测模块及切换模块的功能与上述实施例中的功能相同,此处不再赘述。
接管模块313,用于接管任意一个异常的作为主管理服务器或非主管理服务器的第二管理服务器所管理的至少一个数据库集群。
具体的,假设某个第二管理服务器作为当前的主管理服务器,如管理服务器2,该第一管理服务器及其他的第二管理服务器作为当前的非主管理服务器,该第一管理服务器或作为非主管理服务器的第二管理服务器可以接管出故障的第二管理服务器所管理的至少一个数据库集群。即接管出故障的非主管理服务器或出故障的主管理服务器所管理的至少一个数据库集群。
例如,作为当前的非主管理服务器的第一管理服务器及第二管理服务器,可以接管当前的主管理服务器分配的其他的出故障的非主管理服务器所管理的数据库集群。即作为当前的主管理服务器的第二管理服务器发现系统中的某个非主管理服务器出现故障,则可以在存储服务器中,将出现故障的该非主管理服务器所管理的至少数据库集群的信息更新到存储服务器中的第一管理服务器所管理的数据库集群列表中,以使得作为当前的非主管理服务器的第一管理服务器或作为当前的非主管理服务器第二管理服务器可以接管新增的数据库集群。数据库集群的信息如数据库实例的vip和端口等信息。
或者,作为当前的非主管理服务器的第一管理服务器及第二管理服务器,可以接管出故障的主管理服务器所管理的数据库集群。当第一管理服务器或某个作为当前的非主管理服务器的第二管理服务器发现作为当前的主管理服务器的第二管理服务器出现故障时,作为非主管理服务器的该第二管理服务器或第一管理服务器竞争成为新的主管理服务器后,可以接管旧的主管理服务器所管理的数据库集群;或者,在没有竞争成为新的主管理服务器时,接管由竞争成功的主管理服务器分配的旧的主管理服务器管理的数据库集群,即当前的主管理服务器将旧的主管理服务器管理的数据库集群更新到第一管理服务器或非主的第二管理服务器所管理的数据库集群列表中,使得该第一管理服务器或作为当前的非主管理服务器第二管理服务器接管作为主管理服务器的第二管理服务器所管理的数据库集群。进一步,分配模块314,用于将任意一个作为非主管理服务器的第二管理服务器所管理的至少一个数据库集群分配到其他的作为非主管理服务器的第二管理服务器上。
具体的,每个管理服务器上的分配模块,可用于当其作为主管理服务器时,将任意一个非主管理服务器所管理的至少一个数据库集群分配到其他的第二管理服务器上。
或者,当该管理服务器作为非主管理服务器时,当该系统中主管理服务器出现故障时,该非主管理服务器通过竞争成为新的主管理服务器,并将出现故障的旧的主管理服务器所管理的数据库集群分配到其他的非主管理服务器上。可以理解,主管理服务器将出故障的非主管理服务器或旧的主管服务器所管理的数据库集群分配给第一管理服务器或当前的非主管理服务器外。该主管理服务器还可以直接接管,并不分配给其他的非主管理服务器。
还可以理解,主管理服务器还可以利用负载均衡器,根据当前某个非主管理服务器的运行情况,将其管理的数据库集群分配给其他的非主管理服务器。
可选的,第一管理服务器作为非主管理服务器,其分配模块314可以包括:
第一检测单元301,用于利用java数据库连接检测作为当前的主管理服务器的第二管理服务器最近的所述心跳时间。
具体的,第一管理服务器作为非主管理服务器,其上的该第一检测单元可以以预设频率,利用java数据库连接检测作为当前的主管理服务器的第二管理服务器最后心跳时间。
可以理解,所有的作为当前的非主管理服务器的第二管理服务器可以检测作为当前的主管理服务器最后一次的心跳时间。
第一判断单元302,用于判断作为当前的主管理服务器的第二管理服务器最近的心跳时间与当前时间的第一时间间隔是否大于预设时长。
具体的,如果作为非主管理服务器的第一管理服务器检测到主管理服务器的最后心跳时间后,经过判断发现该心跳时间与当前时间的间隔大于预设值,则说明该主管理服务器出现故障。
竞争单元303,用于当该主管理服务器的该间隔大于该预设时长时,第一管理服务器向该存储服务器发送竞争消息,使得作为非主管理服务器的第一管理服务器成为新的主管理服务器。
具体的,当非主管理服务器检测发现主管理服务器出现故障时,作为非主管理服务器的第一管理服务器或第二管理服务器可以竞争成为新的主管理服务器,并在竞争成功后,可以接管该出故障的旧的主管理服务器所管理的数据库集群。或者,还可以进一步将旧的主管理服务器所管理的数据库集群分配给其他的当前非主管理服务器,并向存储服务器中更新主管理服务器的心跳时间。如在存储服务器中,将旧的主管理服务器管理的数据库集群列表更新到自己的数据库集群列表中,并在存储服务器中更新主管理服务器的心跳时间。
例如,作为非主管理服务器的第一管理服务器和第二管理服务器共同向存储服务器发送主管理服务器的心跳时间更新消息,即竞争消息。如通过update sql消息并发更新表tt_ms_appha_config,则第一个更新成功的非主管理服务器即为竞争成功的主管理服务器,如第一管理服务器更新成功。
update tt_ms_appha_config set node_name=#{newLeader}wherenode_name=#{oldLeader}and env=#{env}。第二检测单元304,用于当第一管理服务器竞争成为新的主管理服务器时,利用java数据库连接检测其他的作为非主管理器的第二管理服务器的最近的心跳时间。
第二判断单元305,用于判断作为非主管理器的第二管理服务器的最近的心跳时间与当前时间的第二时间间隔是否大于预设时长。
具体的,当第一管理服务器竞争成功后,作为新的主管理服务器,可以检测所有作为非主管理服务器的第二管理服务器最后的心跳时间。如果第一管理服务器检测到某个非主管理服务器的最后的心跳时间后,经过判断发现该心跳时间与当前时间的间隔大于预设时长,则说明该非主管理服务器出现故障,即该非主管理服务器目前无法正常运行,无法对其管理的数据库集群进行正常管理,如执行数据库集群中主服务器的状态检测及切换。
分配单元306,用于当第二时间间隔大于预设时长时,将作为非主管理服务器的第二管理服务器所管理的至少一个数据库集群分配到其他的作为非主管理服务器的第二管理服务器上。
具体的,当作为新的主管理服务器的第一管理服务器检测到某个非主管理服务器的该间隔大于该预设时长时,第一管理服务器可以将该非主管理服务器上的数据库集群分配到其他的非主管理服务器上。
例如,可以在存储服务器内,将非主管理服务器上的数据库集群的列表更新到某个正常的非主管理服务器所管理的数据库集群列表中,使得该正常的非主管理服务器管理出故障的非主管理服务器上的数据库集群。
为了便于理解本申请实施例提供的数据库框架下,管理服务器对数据库的具体管理过程中,下面通过图4至图8详细解释本申请实施例提供的数据库管理的方法。图4所示为本申请实施例提供的数据库管理方法的流程示意图,如图4所示,该方法可以由管理服务器执行,具体包括:
S410,第一管理服务器通过java数据库连接检测其管理的预先分配的至少一个数据库集群中的主服务器的连通性、主服务器所在的物理主机的连通性和/或主服务器的数据库实例的连通性。
S420,基于第一管理服务器的检测结果,在主服务器不正常时,将数据库集群中的从服务器切换为数据库集群的新的主服务器。
具体的,上述的检测过程及切换过程可以如上述检测模块及切换模块的执行过程,此处不再赘述。可以理解,该数据库管理装置管理的数据库集群包括一个主服务器及至少一个从服务器,该主服务器及该从服务器上配置有至少一个数据库实例。
对于具体的检测过程及切换过程可如图6及图7所示。图6为本申请实施例提供的管理服务器在检测数据库集群中的主服务器是否正常的方法流程示意图。图7为本申请实施例提供的管理服务器在切换主服务的方法流程示意图。
图5所示为又一实施例提供的数据库管理方法的流程示意图。该场景中的数据库管理涉及多个管理服务器和存储服务器。如图5所示,该方法可以由多个管理服务器中的第一管理服务器执行。可以理解,该第一管理服务器可以为多个管理服务器中的任意一个。该第一管理服务器为当前的非主管理服务器,其他的第二管理服务器中的某个为当前的主管理服务器。该方法具体包括:
S510,接管任意一个异常的作为主管理服务器或非主管理服务器的第二管理服务器所管理的至少一个数据库集群;
S530,利用java数据库连接检测所管理的数据库集群中的主服务器上的该数据库实例是否连通。
S540,当检测的该数据库实例不连通时,将该数据库集群中的从数据库服务器切换为主数据库服务器。
本申请实施例中,第一管理服务器可以接管出故障的主管理服务器或非主管理服务器的数据库集群,实现数据库架构的高可用。该数据库集群包括一个主数据库服务器及至少一个从数据库服务器,该主数据库服务器及该从数据库服务器上配置有至少一个数据库实例。
可以理解,在另一实施例中,该方法还可以包括:将任意一个非主管理服务器的数据库管理模块所管理的至少一个数据库集群分配到其他的非主管理服务器上。
即当第一管理服务器作为当前的主管理服务器后,可以将出故障的任一个非主管理服务器所管理的数据库集群分配给正常的非主管理服务上。该第一管理服务器可以通过竞争成为当前的主管理服务器。
具体的,第一管理服务器在进行竞争成为主管理服务器,并在竞争成功后对数据库集群的分配过程,可以参考图8,图8为本申请实施例提供的多个管理服务器对数据库集群的分配方法的流程示意图。
S810,java数据库连接检测作为当前的主管理服务器的第二管理服务器最近的心跳时间;
S820,判断作为当前的主管理服务器的第二管理服务器最近的心跳时间与当前时间的第一时间间隔是否大于预设时长;
S830,当第一时间间隔大于所述预设时长时,向存储服务器发送竞争消息,使其成为新的主管理服务器;
S840,当其竞争成为新的主管理服务器时,java数据库连接检测其他的作为非主管理器的第二管理服务器的最近的心跳时间。
S850,判断作为非主管理服务器的第二管理服务器的最近的心跳时间与当前时间的第二时间间隔是否大于预设时长;
S860,当该二时间间隔大于该预设时长时,将作为该非主管理服务器的第二管理服务器所管理的至少一个该数据库集群分配到其他的作为非主管理服务器的第二管理服务器上。
可以理解,上述方法的实现过程与上述实施例中的各个单元模块的执行过程类似,此处不再赘述。
还可以理解,本申请实施例对上述数据库管理过程中,每个管理服务器对心跳时间的更新及检测,且根据检测结果执行主管理服务器的竞争过程,与每个管理服务器对其所管理的数据库集群的检测与切换的步骤的执行顺序不做限制,可以同时执行。
可以理解,本申请实施例还提供了一种服务器,该服务器包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序,该处理器执行该程序时可用于执行上述的数据库管理方法。
下面参考图9,其示出了适于用来实现本申请实施例的服务器的计算机系统900的结构示意图。
如图9所示,计算机系统包括中央处理单元(CPU)901,其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM903中,还存储有系统操作所需的各种程序和数据。CPU 901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。
以下部件连接至I/O接口905:包括键盘、鼠标等的输入部分906;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分;包括硬盘等的存储部分908;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器也根据需要连接至I/O接口905。可拆卸介质911,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器910上,以便于从其上读出的计算机程序根据需要被安装入存储部分908。
特别地,根据本发明的实施例,上文参考流程图4至图8描述的过程可以被实现为计算机软件程序。例如,本发明的实施例数据库管理包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分从网络上被下载和安装,和/或从可拆卸介质被安装。在该计算机程序被中央处理单元(CPU)901执行时,执行本申请的系统中限定的上述功能。
需要说明的是,本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。
附图中的流程图和框图,图示了按照本发明各种实施例数据库管理的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本发明实施例中所涉及到的单元可以通过软件的方式实现,也可以通过硬件的方式来实现,所描述的单元也可以设置在处理器中。其中,这些单元的名称在某种情况下并不构成对该单元本身的限定。所描述的单元或模块也可以设置在处理器中,例如,可以描述为:一种处理器包括检测模块及切换模块。其中,这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定,例如,切换模块还可以被描述为“用于当检测到任一个数据库集群的主服务器不可用时,将数据库集群中的从服务器切换为所述数据库集群的主服务器”。
作为另一方面,本申请还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该电子设备执行时,使得该电子设备实现如上述实施例中所述的数据库管理方法。
例如,所述电子设备可以实现如图1中所示的:
S410,第一管理服务器通过java数据库连接检测其管理的预先分配的至少一个数据库集群中的主服务器的连通性、主服务器所在的物理主机的连通性和/或主服务器的数据库实例的连通性。S420,基于第一管理服务器的检测结果,在主服务器不正常时,将数据库集群中的从服务器切换为数据库集群的新的主服务器。又如,该电子设备可以实现如图5至图8中所示的各个步骤。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
此外,尽管在附图中以特定顺序描述了本公开中方法的各个步骤,但是,这并非要求或者暗示必须按照该特定顺序来执行这些步骤,或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,以及/或者将一个步骤分解为多个步骤执行等。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。
综上所述,本申请实施例提供的数据库管理系统,通过在管理服务器上设置用于管理数据库集群的检测模块及切换模块,使得检测模块利用java数据库连接,检测所管理的数据库集群中的主服务器的连通性、所在的物理主机的连通性和/或数据库实例的连通性,进而使得切换模块根据检测模块的检测结果,完成主从服务器的切换,利用java数据库连接,实现了管理服务器与管理的数据库集群中数据库的直接交互,无需在数据库实例中部署代理服务,实现了在物理主机上部署有多个数据库实例的数据库集群的管理,实现了数据库架构的扩展。
以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本申请中所涉及的申请范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离该申请构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
Claims (10)
1.一种数据库管理系统,其特征在于,所述系统包括:
第一管理服务器,所述第一管理服务器用于管理预先分配的至少一个数据库集群,所述数据库集群包括主服务器和从服务器,所述主服务器及所述从服务器上配置有至少一个数据库实例,其中,
所述第一管理服务器包括:
检测模块,用于通过java数据库连接检测所述第一管理服务器所管理的所述数据库集群中的主服务器的连通性、所述主服务器所在的物理主机的连通性和/或所述主服务器的数据库实例的连通性;
切换模块,用于基于所述检测模块的检测结果,在主服务器不正常时,将所述数据库集群中的从服务器切换为所述数据库集群的新的主服务器。
2.根据权利要求1所述的数据库管理系统,其特征在于,还包括存储服务器及至少一个第二管理服务器,所述第二管理服务器协助所述第一管理服务器,用于管理至少部分所述数据库集群,一所述第二管理服务器为当前的主管理服务器,则其余管理服务器为非主管理服务器,其中,
所述第一管理服务器还包括:
接管模块,用于接管任意一个异常的作为主管理服务器或非主管理服务器的所述第二管理服务器所管理的至少一个所述数据库集群。
3.根据权利要求2所述的数据库管理系统,其特征在于,所述第一管理服务器还包括:
分配模块,用于将任意一个作为非主管理服务器的所述第二管理服务器所管理的至少一个所述数据库集群分配到其他的作为非主管理服务器的所述第二管理服务器上。
4.根据权利要求3所述的数据库管理系统,其特征在于,所述分配模块包括:
第一检测单元,用于检测作为当前的主管理服务器的所述第二管理服务器最近的心跳时间;
第一判断单元,用于判断作为当前的所述主管理服务器的所述第二管理服务器最近的心跳时间与当前时间的第一时间间隔是否大于预设时长;
竞争单元,用于当所述第一时间间隔大于所述预设时长时,向所述存储服务器发送竞争消息,所述竞争消息用于使得所述第一管理服务器成为新的主管理服务器;
第二检测单元,用于当所述第一管理服务器竞争成为新的主管理服务器时,检测其他的作为非主管理服务器的所述第二管理服务器的最近的心跳时间;
第二判断单元,用于判断作为非主管理服务器的第二管理服务器的最近的心跳时间与当前时间的第二时间间隔是否大于预设时长;
分配单元,用于当所述第二时间间隔大于所述预设时长时,将作为非主管理服务器的所述第二管理服务器所管理的至少一个所述数据库集群分配到其他的作为非主管理服务器的所述第二管理服务器上。
5.根据权利要求1所述的数据库管理系统,其特征在于,所述检测模块包括:
创建单元,用于与待检测的所述数据库集群的所述主服务器建立java数据库连接;
第三检测单元:用于利用java数据库连接检测与所述主服务器对应的通讯接口是否可以连通;
读取单元,用于基于所述通讯接口的连通性,从所述第一管理服务器或存储服务器读取所述数据库集群的状态信息;
当所述状态信息表示所述数据库集群处于运行状态时,所述第三检测单元还用于:
利用java数据库连接检测所述主服务器的数据库是否连通;
当所述数据库不连通时,利用java数据库连接检测所述主服务器的长连接是否有效;
当所述长连接无效时,利用java数据库连接检测所述主服务器所在的物理主机是否可登录;
当所述物理主机可登录时,利用java数据库连接检测所述主服务器的数据库实例是否存活;
当所述数据库实例存活时,检测所述主服务器的数据库是否连通。
6.根据权利要求5所述的数据库管理系统,其特征在于,所述检测模块还包括:
激活单元,用于当所述主服务器的数据库实例不存活时激活所述数据库实例;其中,
第三检测单元还用于当所述数据库实例激活成功时,检测所述主服务器的数据库是否连通。
7.根据权利要求6所述的数据库管理系统,其特征在于,所述切换模块包括:
选择单元,用于当所述物理主机不可登录,或
当所述数据库实例激活失败,或
当所述数据库实例激活成功后,所述数据库不连通时,从数据库集群中的从服务器中选择一个服务器,作为备选主服务器;
第四检测单元,用于检测所述备选主服务器的数据库的是否连通;
并当所述数据库连通时检测所述备选主服务器的域名系统是否合法;
第三判断单元,用于当所述域名系统合法时判断所述备选主服务器的数据库实例是否可用;
获取单元,用于当所述数据库实例可用时获取所述备选主服务器与其他从服务器的延时时间;
第四判断单元,用于判断所述延时时间是否小于预设值;
切换单元,用于当所述延时时间小于所述预设值时,将所述备选主服务器的域名系统设置为新的主服务器的域名系统。
8.根据权利要求6所述的数据库管理装置,其特征在于,所述第三检测单元还用于:
当所述数据库连通,或所述主服务器长连接有效时,检测所述数据库集群中的主服务及从服务的拓扑关系。
9.一种数据库管理方法,其特征在于,所述方法包括:
第一管理服务器通过java数据库连接检测其管理的预先分配的至少一个数据库集群中的主服务器的连通性、所述主服务器所在的物理主机的连通性和/或所述主服务器的数据库实例的连通性,所述数据库集群包括主服务器和从服务器,所述主服务器及所述从服务器上配置有至少一个数据库实例;
基于所述第一管理服务器的检测结果,在主服务器不正常时,将所述数据库集群中的从服务器切换为所述数据库集群的新的主服务器。
10.根据权利要求9所述的数据库管理方法,其特征在于,所述方法还包括:
接管任意一个异常的第二管理服务器所管理的至少一个所述数据库集群,一所述第二管理服务器为当前的主管理服务器,则其余管理服务器为非主管理服务器;
检测作为当前的主管理服务器的所述第二管理服务器最近的心跳时间;
判断作为当前的所述主管理服务器的所述第二管理服务器最近的心跳时间与当前时间的第一时间间隔是否大于预设时长;
当所述第一时间间隔大于所述预设时长时,向所述存储服务器发送竞争消息,所述竞争消息用于使其成为新的主管理服务器;
当其竞争成为新的主管理服务器时,检测其他的作为非主管理服务器的所述第二管理服务器的最近的心跳时间;
判断作为非主管理服务器的第二管理服务器的最近的心跳时间与当前时间的第二时间间隔是否大于预设时长;
当所述二时间间隔大于所述预设时长时,将作为非主管理服务器的所述第二管理服务器所管理的至少一个所述数据库集群分配到其他的作为非主管理服务器的第二管理服务器上。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910055160.9A CN111459903A (zh) | 2019-01-21 | 2019-01-21 | 数据库管理系统及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910055160.9A CN111459903A (zh) | 2019-01-21 | 2019-01-21 | 数据库管理系统及方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111459903A true CN111459903A (zh) | 2020-07-28 |
Family
ID=71680653
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910055160.9A Pending CN111459903A (zh) | 2019-01-21 | 2019-01-21 | 数据库管理系统及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111459903A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113220421A (zh) * | 2021-05-31 | 2021-08-06 | 深圳市恒扬数据股份有限公司 | 一种服务器集群的管理方法、管理服务器及管理系统 |
CN114520778A (zh) * | 2022-01-13 | 2022-05-20 | 深信服科技股份有限公司 | 一种连通性检测方法、装置、电子设备及存储介质 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN201497981U (zh) * | 2009-04-30 | 2010-06-02 | 升东网络科技发展(上海)有限公司 | 数据库故障自动检测及转移系统 |
CN103747091A (zh) * | 2014-01-16 | 2014-04-23 | 电信科学技术第一研究所 | 一种嵌入式设备的分布式数据同步系统及方法 |
CN104317803A (zh) * | 2014-09-23 | 2015-01-28 | 厦门美柚信息科技有限公司 | 数据库集群的数据存取结构和方法 |
CN104754000A (zh) * | 2013-12-30 | 2015-07-01 | 国家电网公司 | 一种负载均衡方法及系统 |
CN105224637A (zh) * | 2015-09-24 | 2016-01-06 | 珠海许继芝电网自动化有限公司 | 一种基于PostgreSQL数据库的主备/集群应用的综合性方法 |
CN106126652A (zh) * | 2016-06-24 | 2016-11-16 | 武汉斗鱼网络科技有限公司 | 用于分布式数据库集群的故障数据库切换方法及系统 |
CN106817408A (zh) * | 2016-12-27 | 2017-06-09 | 中国银联股份有限公司 | 一种分布式服务器集群调度方法及装置 |
CN108833164A (zh) * | 2018-06-14 | 2018-11-16 | 杭州网易再顾科技有限公司 | 服务器控制方法、装置、电子设备及存储介质 |
-
2019
- 2019-01-21 CN CN201910055160.9A patent/CN111459903A/zh active Pending
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN201497981U (zh) * | 2009-04-30 | 2010-06-02 | 升东网络科技发展(上海)有限公司 | 数据库故障自动检测及转移系统 |
CN104754000A (zh) * | 2013-12-30 | 2015-07-01 | 国家电网公司 | 一种负载均衡方法及系统 |
CN103747091A (zh) * | 2014-01-16 | 2014-04-23 | 电信科学技术第一研究所 | 一种嵌入式设备的分布式数据同步系统及方法 |
CN104317803A (zh) * | 2014-09-23 | 2015-01-28 | 厦门美柚信息科技有限公司 | 数据库集群的数据存取结构和方法 |
CN105224637A (zh) * | 2015-09-24 | 2016-01-06 | 珠海许继芝电网自动化有限公司 | 一种基于PostgreSQL数据库的主备/集群应用的综合性方法 |
CN106126652A (zh) * | 2016-06-24 | 2016-11-16 | 武汉斗鱼网络科技有限公司 | 用于分布式数据库集群的故障数据库切换方法及系统 |
CN106817408A (zh) * | 2016-12-27 | 2017-06-09 | 中国银联股份有限公司 | 一种分布式服务器集群调度方法及装置 |
CN108833164A (zh) * | 2018-06-14 | 2018-11-16 | 杭州网易再顾科技有限公司 | 服务器控制方法、装置、电子设备及存储介质 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113220421A (zh) * | 2021-05-31 | 2021-08-06 | 深圳市恒扬数据股份有限公司 | 一种服务器集群的管理方法、管理服务器及管理系统 |
CN113220421B (zh) * | 2021-05-31 | 2023-01-31 | 深圳市恒扬数据股份有限公司 | 一种服务器集群的管理方法、管理服务器及管理系统 |
CN114520778A (zh) * | 2022-01-13 | 2022-05-20 | 深信服科技股份有限公司 | 一种连通性检测方法、装置、电子设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110401696B (zh) | 一种去中心化处理的方法、通信代理、主机以及存储介质 | |
US10509680B2 (en) | Methods, systems and apparatus to perform a workflow in a software defined data center | |
CN112099918A (zh) | 容器化环境中的集群的实时迁移 | |
CN106575247B (zh) | 计算集群的容错联盟 | |
CN105933137A (zh) | 一种资源管理方法、装置及系统 | |
US20100162226A1 (en) | Zero downtime mechanism for software upgrade of a distributed computer system | |
JP2002500785A (ja) | ネットワーク・サービスの負荷平衡化及びフェールオーバ | |
US11556369B2 (en) | Virtual machine deployment method and OMM virtual machine | |
EP3442201B1 (en) | Cloud platform construction method and cloud platform | |
CN107395458B (zh) | 系统监控方法及装置 | |
CN111385114A (zh) | Vnf服务实例化方法及装置 | |
US20080196029A1 (en) | Transaction Manager Virtualization | |
CN111897558A (zh) | 容器集群管理系统Kubernetes升级方法和装置 | |
US10761869B2 (en) | Cloud platform construction method and cloud platform storing image files in storage backend cluster according to image file type | |
CN109845192B (zh) | 动态地适配网络的计算机系统和方法及计算机可读介质 | |
CN111880934A (zh) | 一种资源管理方法、装置、设备及可读存储介质 | |
KR20200078328A (ko) | 소프트웨어 애플리케이션 프로세스를 모니터링하는 시스템 및 방법 | |
EP3915224A1 (en) | State controller running in a kubernetes system and method for operating same | |
CN111459903A (zh) | 数据库管理系统及方法 | |
WO2018144291A1 (en) | Deploying a cloud service with capacity reservation followed by activation | |
CN105794182A (zh) | 分布式系统中锁服务器故障的处理方法及其系统 | |
CN111158949A (zh) | 容灾架构的配置方法、切换方法及装置、设备和存储介质 | |
CN110391940A (zh) | 服务地址的响应方法、装置、系统、设备和存储介质 | |
CN112434008A (zh) | 分布式数据库升级方法、设备及介质 | |
CN111131445B (zh) | Dhcp集群的调度方法和dhcp集群系统 |
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 |