CN110275793A - 一种用于MongoDB数据分片集群的检测方法及设备 - Google Patents

一种用于MongoDB数据分片集群的检测方法及设备 Download PDF

Info

Publication number
CN110275793A
CN110275793A CN201910567367.4A CN201910567367A CN110275793A CN 110275793 A CN110275793 A CN 110275793A CN 201910567367 A CN201910567367 A CN 201910567367A CN 110275793 A CN110275793 A CN 110275793A
Authority
CN
China
Prior art keywords
node
fragment
testing result
detection
abnormal
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
Application number
CN201910567367.4A
Other languages
English (en)
Other versions
CN110275793B (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.)
China Mobile Communications Group Co Ltd
MIGU Culture Technology Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
MIGU Culture Technology 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 China Mobile Communications Group Co Ltd, MIGU Culture Technology Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN201910567367.4A priority Critical patent/CN110275793B/zh
Publication of CN110275793A publication Critical patent/CN110275793A/zh
Application granted granted Critical
Publication of CN110275793B publication Critical patent/CN110275793B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions
    • 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
    • YGENERAL 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
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/50Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Abstract

本发明实施例提供一种用于MongoDB数据分片集群的检测方法及设备。所述方法包括依次检测路由节点、数据节点和主分片节点的指定端口的连通性是否正常;若存在不正常则指示重启所属的节点;若主分片节点的指定端口连通性正常则检测所在复制集中的分片节点的状态是否正常;若存在状态不正常则指示重启状态不正常的分片节点;若不存在则检测是否存在慢查询;若存在,则执行慢查询修复策略,本发明实施例通过对所有的路由节点、数据节点和主分片节点的连通性进行检测,并调用每个分片节点的状态信息,再进行慢查询检测,并根据检测结果执行相应的修复策略,从而能够及时发现数据库的错误,并主动快速修复,以提高数据库的使用效率。

Description

一种用于MongoDB数据分片集群的检测方法及设备
技术领域
本发明涉及数据处理技术领域,尤其涉及一种用于MongoDB数据分片集群的检测方法及设备。
背景技术
由于大数据时代的到来,以及云存储技术的快速发展,要求对海量数据进行有效和快速地存储和提取。传统的关系型数据库,暴露了很多难以解决的问题。尤其在面对高并发量的读写请求,海量数据的快速访问、高效存储方面和数据库高扩展性等方面,需求难以得到满足。因此,非关系型数据库NoSql应运而生。NoSql数据库以支持海量数据、高可用性、高扩展性而闻名,解决了关系型数据库所面临的问题。
MongoDB是NoSql数据库产品中最热门的一种,它是一个基于分布式文件存储的数据库,旨在为WEB应用提供可扩展的高性能数据存储解决方案。因其高性能、易部署、易使用、存储效率高等优点,获得很多大中型企业和网站的使用。MongoDB为了存储海量数据,依据其自动分片机制来实现数据库的水平扩展,而且水平扩展的过程是系统自动实现。随着数据量的增加对于MongoDB的运维能力和保障能力也将变得越来越重要。
官方提供的操作管理器MongoDB Ops Manager虽然功能庞大,但也仅仅提供了指标监控和报警规则订制,对于分片集群部署架构,仅支持在某个节点失效后的报警,仍需运维人员人工介入进行MongoDB节点修复操作。
目前这种报警提醒到人工介入修复的方式不但不能在第一时间修复失效的MongoDB节点,而且即使事后修复,操作比较繁琐,稍有不慎可能出错。
发明内容
本发明实施例提供一种用于MongoDB数据分片集群的检测方法及设备,用以解决现有技术中人工介入修复的方式不但不能在第一时间修复失效的MongoDB节点,而且即使事后修复,操作比较繁琐,稍有不慎可能出错的问题。
第一方面,本发明实施例提供了一种用于MongoDB数据分片集群的检测方法,包括:
依次检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果;所述指定端口包括:接收客户端访问请求的端口;
若存在表征指定端口的连通性不正常的第一类检测结果,则指示重启连通性不正常的指定端口所属的节点;
若根据所述第一类检测结果判定任一主分片节点的指定端口连通性正常,则检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果;其中,每个复制集包括一个主分片节点和至少一个从分片节点;
若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的分片节点;
若不存在表征分片节点的状态不正常的第二类检测结果,则检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果;
若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则执行预设的慢查询修复策略。
第二方面,本发明实施例还提供了一种电子设备,包括:
处理器、存储器、通信接口和通信总线;其中,
所述处理器、存储器、通信接口通过所述通信总线完成相互间的通信;
所述通信接口用于该电子设备的通信设备之间的信息传输;
所述存储器存储有可被所述处理器执行的计算机程序指令,所述处理器调用所述程序指令能够执行如下方法:
依次检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果;所述指定端口包括:接收客户端访问请求的端口;
若存在表征指定端口的连通性不正常的第一类检测结果,则指示重启连通性不正常的指定端口所属的节点;
若根据所述第一类检测结果判定任一主分片节点的指定端口连通性正常,则检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果;其中,每个复制集包括一个主分片节点和至少一个从分片节点;
若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的分片节点;
若不存在表征分片节点的状态不正常的第二类检测结果,则检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果;
若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则执行预设的慢查询修复策略。
第三方面,本发明实施例还提供了一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现如下方法:
依次检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果;所述指定端口包括:接收客户端访问请求的端口;
若存在表征指定端口的连通性不正常的第一类检测结果,则指示重启连通性不正常的指定端口所属的节点;
若根据所述第一类检测结果判定任一主分片节点的指定端口连通性正常,则检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果;其中,每个复制集包括一个主分片节点和至少一个从分片节点;
若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的分片节点;
若不存在表征分片节点的状态不正常的第二类检测结果,则检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果;
若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则执行预设的慢查询修复策略。
本发明实施例提供的用于MongoDB数据分片集群的检测方法及设备,通过对所有的路由节点、数据节点和主分片节点的连通性进行检测得到第一类检测结果,并调用每个分片节点的状态信息以得到第二类检测结果,再继续进行慢查询检测以得到第三类检测结果,并根据所述检测结果执行相应的修复策略,从而能够及时发现数据库的错误,并主动快速修复,以提高数据库的使用效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例的用于MongoDB数据分片集群的检测方法流程图;
图2为本发明实施例的另一用于MongoDB数据分片集群的检测方法流程图;
图3为本发明实施例的又一用于MongoDB数据分片集群的检测方法流程图;
图4为本发明实施例的再一用于MongoDB数据分片集群的检测方法流程图;
图5为本发明实施例的用于MongoDB数据分片集群的检测装置结构示意图;
图6为本发明实施例的用于MongoDB数据分片集群的检测的整体架构示意图;
图7示例了一种电子设备的实体结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
图1为本发明实施例的用于MongoDB数据分片集群的检测方法流程图,如图1所示,所述方法包括:
步骤S01、检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果;所述指定端口包括:接收客户端访问请求的端口。
MongoDB数据分片集群包括三类节点,分别为路由节点Router Server,数据节点Config Server和分片节点Shard Server。
所述路由节点用于提供对外应用访问,与客户端进行信息交互。所有的路由节点组合为路由节点集群。
所述数据节点用于存储所有分片数据路由信息,所有存、取数据的方式。所有的数据节点组合为数据节点集群。
所述分片节点则用于存储具体的数据。所有分片节点被分为多个复制集,每个复制集包括一个主分片节点和至少一个从分片节点,其中,由所述主分片节点执行对外的读写操作。所有的复制集组合为分片节点集群。
当路由节点接收到客户端发送的数据请求时,会从数据节点调用所需数据的路由信息,再根据路由信息转发数据请求给相应的复制集的主分片节点执行读写操作,并将接收到的由主分片节点发来的数据返回给客户端。
本发明实施例根据预设的周期,定期执行预编写的脚本程序来对所述整个数据库进行检测,以发现问题,并执行相应的修复操作。所述脚本程序即可以是通过数据库所在服务器执行,也可以通过与所述数据库相连的客户端执行,在些不作具体限定。在下面的实施例中,都仅给客户端执行所述脚本程序为例进行举例说明。
所述客户端为了能够正常访问所述MongoDB数据分片集群中的各个节点,需要先检测所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常。
具体的检测顺序,根据MongoDB数据分片集群的架构,可以先检测每个路由节点的指定端口;若所有的路由节点的指定端口均正常,再检测每个数据节点的指定端口;若所有的数据节点的指定端口均正常,再检测每个主分片节点的指定端口。
所述客户端根据每个路由节点、数据节点和主分片节点在检测期间回复的检测反馈信息,得到第一类检测结果。
根据所述第一类检测结果,若所有的节点的指定端口的连通性均正常,则表明所述客户端可以通过向指定端口发送访问请求来登录任一节点或者对所述MongoDB数据分片集群中保存的数据进行读\写操作。
步骤S02、若存在表征指定端口的连通性不正常的第一类检测结果,则指示重启连通性不正常的指定端口所属的节点。
若根据得到的第一类检测结果为存在任一指定端口的连通性不正常,所述客户端将终止本次周期性检测,并指示该指定端口所属的节点执行重启操作。
在对每个路由节点的指定端口进行检测过程中,若根据第一类检测结果判定指定端口的连通性不正常,则终止本次周期性检测,并指示该路由节点执行重启操作。
在对每个数据节点的指定端口进行检测过程中,若根据第一类检测结果判定指定端口的连通性不正常,则终止本次周期性检测,并指示该数据节点执行重启操作。
在对每个主分片节点的指定端口进行检测过程中,若根据第一类检测结果判定指定端口的连通性不正常,则终止本次周期性检测,并指示该主分片节点执行重启操作。
步骤S03、若根据所述第一类检测结果判定任一主分片节点的指定端口连通性正常,则检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果;其中,每个复制集包括一个主分片节点和至少一个从分片节点。
通过对所有节点的指定端口的连通性进行检测的过程中,所述客户端将获取到所有主分片节点的地址,并登录每个主分片节点。
若所述客户端登录成功,则所述客户端可向该主分片节点调用该主分片节点所在的复制集中所有分片节点的状态信息。并根据对所有分片节点的状态信息的分析来判断每个分片节点的状态是否正常,包括该复制集中的主分片节点以及每个从分片节点,从而得到了第二类检测结果。
步骤S04、若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的分片节点。
若根据第二类检测结果判定任一分片节点的状态不正常,则此时,将停止本次周期性检测,并由所述客户端通过远程指示该任一分片节点执行重启操作。
步骤S05、若不存在表征分片节点的状态不正常的第二类检测结果,则检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果。
而若根据得到的第一类检测结果和第二类检测结果,判定所有路由节点、数据节点和主分片节点的指定端口的连通性均正常,且所有分片节点的状态也均正常,相当于判定所述MongoDB数据分片集群中的路由节点集群、数据节点集群和分片节点集群均正常。
此时,所述客户端可继续检测所述MongoDB数据分片集群中是否存在慢查询,并根据慢查询检测结果得到第三类检测结果。
步骤S06、若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则执行预设的慢查询修复策略。
若所述客户端根据第三类检测结果判定存在慢查询,则结束本次周期检测,并执行预设的慢查询自动修复策略。由于出现慢查询一般和MongoDB数据分片集群中用于存储数据的表结构设计和读写方式有关,目前的自动化修改策略是从第三类检测结果中提取出其中包括的所有慢查询,所述慢查询至少包括表名和列名。将与提取出的表名和列名对应的列在数据库中与为每个表建立的索引进行对照,以查看所述数据库是否已经为与提取的表名和列名对应的列建立了相对应的索引,若没有则新建与提取的表名和列名对应的新的索引,以便加快后续对与该提取的表名和列名对应的列的查询速度。
本发明实施例通过对所有的路由节点、数据节点和主分片节点的连通性进行检测得到第一类检测结果,并调用每个分片节点的状态信息以得到第二类检测结果,再继续进行慢查询检测以得到第三类检测结果,并根据所述检测结果执行相应的修复策略,从而能够及时发现数据库的错误,并主动快速修复,以提高数据库的使用效率。
图2为本发明实施例的另一用于MongoDB数据分片集群的检测方法流程图,如图2所示,所述步骤S01具体包括:
步骤S011、根据预存的所有路由节点的地址向每个路由节点发送连通性检测指令,以使所述路由节点回复检测反馈信息。
所述客户端保存有每个路由节点的地址,例如,每个路由节点的统一资源定位符(Uniform Resource Locator,URL)。根据保存的地址向每个路由节点发送连通性检测指令,所述连通性检测指令具体可以为通过操作系统提供的端口探测工具向所述路由节点发送探测指令,例如,Linux系统上的nc命令等。
所述路由节点在接收到所述连通性检测指令后,会根据自身的指定端口的状态回复检测反馈信息。
步骤S012、若根据由所述路由节点发送的检测反馈信息,判定所有路由节点的指定端口的连通性正常,则向所述路由节点发送数据节点的地址请求,以使所述路由节点回复所有数据节点的地址。
若所述客户端在预设的时间段内,没有收到所述路由节点的检测反馈信息或者收到了错误的检测反馈信息,即得到的第一类检测结果为该路由节点的指定端口的连通性不正常,可判定所述路由节点集群不可用。此时,所述客户端将终止本次周期性检测,并向该路由节点发送重启操作指令,用于重启该路由节点。
而若所述客户端在预设的时间段内,接收到由所述路由节点发送的正确的检测反馈信息,则得到的第一类检测结果为该路由节点的指定端口的连通性正常。
当完成对所有路由节点的连通性检测,且所有路由节点的指定端口的连通性均正常时,则可判定所述路由节点集群可用。此时,所述客户端将向所述路由节点发送数据节点的地址请求。
所述路由节点在接收所述数据节点的地址请求后,调取所述路由节点保存的配置文件,从中获取所有数据节点的地址,例如,数据节点为的URL。
步骤S013、根据所有数据节点的地址,向每个数据节点发送所述连通性检测指令,以使所述数据节点回复所述检测反馈信息。
所述客户端根据从路由节点获取到的数据节点的地址,向每个数据节点发送连通性检测指令,同样,具体可以通过操作系统提供的端口探测工具向所述路由节点发送探测指令。
所述数据节点则根据自身的指定端口的状态回复相应的检测反馈信息。
步骤S014、若根据由所述数据节点发送的检测反馈信息,判定所有数据节点的指定端口连通性正常,则向所述路由节点发送分片节点的地址请求,以使所述路由节点回复所有分片节点的地址。
若所述客户端在预设的时间段内,没有接收到所述数据节点发送的检测反馈信息或者接收到了错误的检测反馈信息,即所述第一类检测结果为所述数据节点的指定端口的连通性出错,可判定所述数据节点集群不可用。此时,所述客户端将终止本次周期性检测,并向该数据节点发送重启操作指令,用于重启该数据节点。
若所述客户端在预设的时间段内,接收到由所述数据节点发送的正确的检测反馈信息,则判定该数据节点的指定端口的连通性正常。
当完成对所有数据节点的连通性检测,且所有数据节点的指定端口的连通性均正确时,则可判定所述数据节点集群可用。
然后,所述客户端将向所述路由节点发送分片节点的地址请求,具体地,可先向所述路由节点发送登录请求,并在获得登录许可后,向所述路由节点传入基于该客户端支持的客户脚本应用程序接口(Client Script API)编写的程序文件,通过sh.status()命令来获取所有分片节点的地址,例如,分布节点的URL。所述路由节点将接收到的分片节点地址发送给所述客户端。
步骤S015、根据所有主分片节点的地址,依次向每个主分片节点发送登录请求。
根据接收到的所有分片节点的地址中每个主分片节点的地址,向每个主分片节点发送登录请求。所述主分片节点则根据自身状态回复登录响应。
步骤S016、若登录成功,则判定所述主分片节点的指定端口连通性正常。
若所述客户端根据所述主分片节点发送的回复登录响应,得到所述主分片节点登录失败,即所述第一类检测结果为所述主分片节点的指定端口的连通性出错,可判定所述分片节点集群不可用。此时,所述客户端将终止本次周期检测,并向所述主分片节点发送重启操作指令,用于重启该主分片节点。
而若登录成功,则判定所述主分片节点的指定端口的连通性正常。
本发明实施例通过依次检测所有的路由节点,并从路由节点获取所有数据节点的地址,再检测所有数据节点,并从数据节点得到所有分片节点的地址,登录每个主分片节点来检测所述主分片节点的指定端口的连通性,从而能够及时发现数据库的错误,并主动快速修复,提高了数据库的使用效率。
图3为本发明实施例的又一用于MongoDB数据分片集群的检测方法流程图,如图3所示,所述步骤S03具体包括:
步骤S031、在登录所述主分片节点后,向所述主分片节点发送状态信息请求,以使所述主分片节点回复所述主分片节点所在复制集中所有分片节点状态信息;其中,所述状态信息包括可用信息和健康信息。
当所述客户端登录主分片节点后,将向所述主分片节点发送状态信息请求,以使所述主分片节点收集自身所在的复制集中所有分片节点的状态信息并进行回复。具体地,可以通过调用rs.status()命令来实现。
所述状态信息中至少包括可用信息replSetGetStatus.members[n].health字段和健康信息replSetGetStatus.members[n].stateStr字段。其中所述可用信息用于表示所述分片节点是否处于可以正常访问的状态,而所述健康信息则用于判断所述分片节点是否被其它的进程所占用,例如同步进程。
步骤S032、若根据所述可用信息判定所述分片节点的可以正常访问,且根据所述健康信息判定所述分片节点当前未被其它进程占用,则所述分片节点的状态为正常。
若根据所述可用信息所述客户端判定所述分片节点处于可正常访问的状态,同时而若根据所述健康信息所述客户端判定所述分片节点未被其它进程所占用,则判定所述分片节点的状态正常。而若通过登陆每个主分片节点获取到所有的分片节的状态信息,并判定状态均正常时,则表明所述MongoDB数据分片集群的分片节点集群正常。
本发明实施例通过登录每个主分片节点,调用所有分片节点的状态信息,并分别根据所述状态信息中的可用信息和健康信息来判断所述主分片节点的是否可被正常访问以及是否被其它进程所占用,从而能够及时发现数据库的错误,并主动快速修复,提高了数据库的使用效率。
基于上述实施例,进一步地,所述步骤S04具体包括:
步骤S041、若根据任一分片节点的可用信息判定所述分片节点无法正常访问,则指示重启所述分片节点。
在所述客户端成功登录主分片节点并调用所述主分片节点所在的复制集中所有分片节点的状态信息后,若根据对每个分片节点的可用信息的解析判定任一分片节点无法正常访问,则进一步判定所述分片节点集群不可用。此时,所述客户端将终止本次周期检测,并向所述分片节点发送重启操作指令,用于重启该分片节点。
步骤S042、若根据任一分片节点的健康信息在预设周期数内连续判定所述分片节点被其它进程占用,则结束本次周期性检测,直接指示将与所述片节点对应的主分片节点的数据拷贝到所述分片节点,并指示重启所述分片节点。
而若根据对每个分片节点的健康信息的解析判定任一分片节点正被其它进程所占用,则结束本次周期性检测,并对该分片节点进行标记,从而在后续的周期性检测中持续关注该发片节点的健康信息,以期望该发片节点能够通过正常的Oplogs自动同步方式进行自我恢复。而若该分片节点在预设的周期数内持续被判定为被其它进行所占用,则判定该分片节点无法通过正常的Oplogs自动同步方式进行自我恢复,所述客户端将终止本次周期性检测,并直接通过预设的脚本程序远程将与所述分片节点所在的复制集中的主分片节点的数据拷贝到该分片节点,然后向该分片节点发送重启操作指令,用于重启该分片节点。
本发明实施例通过在判定任一路由节点、数据节点或者分片节点的状态出现异常时,终止本次周期性检测,并对出现异常的路由节点、数据节点或分片节点执行重启,从而能够及时发现数据库的错误,并主动快速修复,提高了数据库的使用效率。
基于上述实施例,进一步地,所述步骤S05具体包括:
登录每个路由节点,并向所述路由节点发送包括预设时间阈值的慢查询检测指令,以使所述路由节点根据所述时间阈值执行慢查询检测,并回复慢查询检测结果,所述慢查询检测结果包括所有查询耗时超过所述时间阈值的慢查询。
在所述客户端根据第一类检测结果和第二类检测结果判定所述路由节点集群、数据节点集群和分片节点集群均正常。所述客户端还需要通过向所述路由节点发送慢查询检测指令来判断所述Mongo数据分片集群中是否存在慢查询。具体,可以先登录所述路由节点,再通过执行下述命令来实现:
db.currentOp({‘active’:true,‘secs-running’:{‘$gt’:[指定的慢查询耗时]}}),
其中,所述“指定的慢查询耗时”即为所述慢查询检测指令中预设的时间阈值。从而所述路由节点根据所述慢查询检测指令随机生成针对数据库保存的各个表的查询式,所述查询式包括查询条件,所述查询条件包括查询的表的表名和以及作为筛选条件的列的列名。在执行查询过程中,若任一查询耗时超过了预设的时间阈值,则判定该查询式为慢查询,并将统计得到的所有慢查询作为慢查询检测结果回复给所述客户端。
所述客户端将根据所述慢查询检测结果,得到第三类检测结果。
而若根据所述第三类检测结果,判定不存在慢查询,则本次周期检测完成,且所述MongoDB数据分片集群无任何异常。否则,执行预设的慢查询修复策略。
本发明实施例通过将向所述路由节点发送慢查询检测指令来判定是否存在慢查询,若存在慢查询,则执行慢查询自动修复策略,从而能够及时发现数据库的错误,并主动快速修复,提高了数据库的使用效率。
基于上述实施例,进一步地,所述方法还包括:
根据本次周期检测的结果,更新预设的复数个预警状态的标记;其中所述预警状态包括第一状态、第二状态、第三状态、第四状态和第五状态;具体地:
若存在表征任一路由节点的指定端口连通性不正常的第一类检测结果,则将所述第一状态标记为异常;
若存在表征任一数据节点的指定端口连通性不正常的第一类检测结果,则将所述第二状态标记为异常;
若存在表征任一主分片节点的指定端口连通性不正常的第一类检测结果,或者存在表征任一分片节点的状态为无法正常访问的第二类检测结果,则将所述第三状态标记为异常;
若存在表征任一分片节点的状态为被其它进程占用的第二类检测结果,则将所述第四状态标记为异常;
若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则将所述第五状态标记为异常;相应地,所述方法还包括:
若任一预警状态被标记为异常,则查看预设的与所述预警状态一一对应的报警计时器;
若所述报警计时器没有开启,则触发与所述预警状态对应的报警提醒,并开启所述报警计时器;
若所述报警计时器的数值超过了预设的间隔阈值,则触发与所述预警状态对应的报警提醒,并重置所述报警计时器。
所述客户端预先设置有多个预警状态,所述预警状态具体包括:与所述路由节点集群相对应的第一状态、与所述路由数据集群相对应的第二状态、与所述分片节点集群相对应的第三状态和第四状态、以及与所述慢查询相对应的第五状态。
在进行周期性检测的过程中,根据实际的检测结果,对各个预警状态进行标记。
若所述客户端根据第一类检测结果,判定任一路由节点的指定端口连通性出错,则判定所述路由节点集群不可用,所述客户端将所述第一状态标记为异常;而若所有的路由节点的指定端口连通性正常,则判定所述路由节点集群可用,所述客户端将所述第一状态标记为正常;
若所述客户端根据第一类检测结果,判定任一数据节点的指定端口连通性出错,则判定所述数据节点集群不可用,所述客户端将所述第二状态标记为异常;而若所有的数据节点的指定端口连通性正常,则判定所述数据节点集群可用,所述客户端将所述第二状态标记为正常;
若所述客户端根据第一类检测结果,判定任一主分片节点的指定端口连通性出错,或者所述客户端根据第二类检测结果,判定任一分片节点的状态为无法正常访问,则判定所述分片节点集群不可用,所述客户端将第三状态标记为异常;若所有主分片节点的指定端口连通性正常且所有分片节点的状态为可以被正常访问,则判定所述分片节点集群可用,所述客户端将第三状态标记为正常;
若所述客户端根据第二类检测结果,判定任一分片节点的状态为被其它进程占用,则判定所述分片节点集群不健康,所述客户端将所述第四状态标记为异常;而若所有分片节点的状态为均为未被其它进行占用,则判定所述分片节点集群健康,所述客户端将所述第四状态标记为正常;
若所述客户端根据第三类检测结果,判定存在慢查询,则所述客户端将第五状态标记为异常;若不存在慢查询,则所述客户端将第五状态标记为正常。
在一次周期检测过程中,当任一预警状态标记为异常时,所述客户端可发出与所述预警状态相对应的报警提醒:第一状态报警、第二状态报警、第三状态报警、第四状态报警和第五状态报警。
为了减少连续报警的次数据,所述客户端为每个预警状态分别设置了报警计时器和间隔阈值,以使在所述间隔阈值范围内出现的连续异常不再发出报警提醒。
当任一预警状态被标记为异常时,将查看与所述预警状态对应的报警计时器:
若所述报警计时器为关闭,则判定在上一次周期性检测期间,该预警状态为正常。此地,发出与所述预警状态对应的报警提醒,并开启该报警计时器。
而若所述报警计时器为开启,则表示在上一次周期性检测期间,该预警状态为异常。此时,进一步查看所述报警计时器的数值是否超过所述间隔阈值:若小于,则不发出报警提醒;而若大于等于,则发出报警提醒,且将所述报警计时器的数值进行重置。
用户通过客户端发出的报警提醒可以准确地了解到本次检测的结果,以及通过重启等修复过程的实际效果,进而根据当前的实际需要来判断是否对无法修复的异常采取进一步的操作,甚至采用人工干预。例如,对于连续几次都收到相同分片节点的第五状态报警,可判定无法通过Oplogs自动同步方式进行自我恢复,此时,可进一步将位于同一复制集中的主分片节点数据文件远程拷贝到该分片节点,并再执行重启操作。
本发明实施例通过为每个预警状态设置对应的报警计时器和间隔阈值,从而在所述间隔阈值内,若所述预警状态连续异常,则不发出相应的报警提醒,从而在能够及时发现数据库的错误,并主动快速修复,提高了数据库的使用效率的前提下,减少了所述报警提醒的数量。
基于上述实施例,进一步地,所述方法还包括:
在本次周期检测期间,若任一预警状态由异常变为正常,则触发与所述预警状态一一对应的恢复提醒,并关闭与所述预警状态对应的报警计时器。
所述客户端还设置有与所述预警状态相对应的恢复提醒:第一状态恢复、第二状态恢复、第三状态恢复、第四状态恢复和第五状态恢复。在任一预警状态由异常变为正常时,触发所述恢复提醒,并关闭与所述恢复提醒对应的预警状态的报警计时器。
本发明实施例通过设置与所述预警状态对应的恢复提醒,在任一预警状态由异常转变为正常时发出恢复提醒,从而在能够及时发现数据库的错误,并主动快速修复,提高了数据库的使用效率的前提下,让用户能够及时了解数据的当前信息。
图4为本发明实施例的再一用于MongoDB数据分片集群的检测方法流程图,如图4所示,本发明实施例为在客户端周期性得运行的用于检测的脚本程序的具体过程。
先通过FC_Begin开始运行脚本程序;
对RouterServer集群,即路由节点集群,的可用性进行监控,具体通过检测每个路由节点的指定端口的连通性来进行;
若任一路由节点的指定端口的连通性出错,则FC_Decision判定所述RouterServer集群的可用性为否,从而作出状态1报警提醒,相当于第一状态异常,并对该路由节点进行远程重启,对于Linux系统,可以通过SSH指令进行远程调用MongoDB命令的方式来实现;然后,执行FC_End结束本次脚本程序;
否则,若FC_Decision判定所述RouterServer集群的可用性为是,则开启对ConfigServer集群,即数据节点集群,的可用性进行监测,具体通过检测每个数据节点的指定端口的连通性来进行;
若任一数据节点的指定端口的连通性出错,则FC_Decision判定所述ConfigServer集群的可用性为否,从而作出状态2报警提醒,相当于第二状态异常,并对该数据节点通过SSH指令进行远程重启;然后,执行FC_End结束本次脚本程序;
否则,若FC_Decision判定所述ConfigServer集群的可用性为是,则开启对ShardServer集群,即分片节点集群,的健康状态进行监测,具体包括通过登录每个主分片节点并获取该主分片节点所在复制集中所有分片节点的状态信息来进行;
若任一主分片节点无法登录,或者任一分片节点的可用信息显示为该分片节点无法被访问,则FC_Decision判定该ShardServer集群的可用性为否,从而作出状态3报警提醒,相当于第三状态异常,并对该分片节点通过SSH指令进行远程重启;然后,执行FC_End结束本次脚本程序;
而任一分片节点的健康信息显示为该分片节点被其它进程所占用,则FC_Decision判定所述ShardServer集群的健康性为为否,从而作出状态4报警提醒,相当于第四状态异常;然后,执行FC_End结束本次脚本程序;
否则,若FC_Decision判定该ShardServer集群的可用性为是,且判定ShardServer集群的健康性为是,则开启慢查询检测;
若FC_Decision判定存在慢查询,则作为状态5报警提醒,相当于第五状态异常;然后,执行FC_End结束本次脚本程序;
否则,若FC_Decision判定不存在慢查询,则执行FC_End结束本次脚本程序。
基于上述实施例,进一步地,所述指示重启所述任一节点或任一分片节点具体包括:
在所述路由节点重启前,需要满足预设的路由节点重启条件,并在重启后执行预设的路由节点重启检测;
在所述数据节点重启前,需要满足预设的数据节点重启条件,并在重启后执行预设的数据节点重启检测;
在所述分片节点重启前,需要满足预设的分片节点重启条件,并在重启后执行预设的分片节点重启检测。
本发明实施例在对任一路由节点、数据节点或与所述主分片节点对应的复制集中的各个分片节点进行重启的过程中,在重启前需要分别检测所述路由节点、数据节点或包含所述主分片节点的复制集所在的服务器的当前状态,来判断是否满足相应的重启条件:与所述路由节点对应的路由节点重启条件、与所述数据节点对应的数据节点为重启条件,与所述分片节点对应的分片节点重启条件。若满足,则在执行重启操作;否则,则在本次检测结束后不执行重启操作,到下一周期的检测过程中,若依然判定需要进行重启操作,则再次检测是否满足对应的重启条件,若满足,则扫行重启操作。
其中,所述路由节点重启条件:日志文件所在磁盘分区有充足空间、操作系统CPU使用率有剩余、配置文件中最大连接数net.maxIncomingConnections参数未被篡改、pid文件已经不存在。
所述数据节点重启条件:数据文件存在、数据文件和日志文件所在磁盘分区有充足空间、操作系统CPU和内存使用率有剩余、复制集名称replication.replSetName参数未被篡改、pid文件已经不存在。所述数据文件为对所述数据文件至少包括所述所有分片数据路由信息。
所述分片节点重启条件:数据文件存在、数据文件和日志文件所在磁盘分区有充足空间、操作系统CPU和内存使用率有剩余、复制集名称replication.replSetName参数未被篡改、pid文件已经不存在。
另外,在完成重启操作后,为了判断重启后的路由节点、数据节点和复制集中的各个分片节点的是否可用,需要对重启后的路由节点、数据节点或分片节点进行相应的重启检测,其中,所述路由节点对应于路由节点重启检测,所述数据节点对应于数据节点重启检测,所述分片节点对应于分片节点重启检测。
所述路由节点重启检测可通过数据库MongoDB内置的isdbgrid命令来判定是否已正确加载路由节点对应的配置文件。
所述数据节点重启检测可通过数据库MongoDB内置的rs.config()命令判定数据节点各个成员都已经注册成功。
所述分片节点重启检测可在任一路由节点中执行数据库MongoDB内置的db.printShardingStatus()命令,来判定所述复制集中各个分片节点都已经在注册成功。
本发明实施例通过在对路由节点、数据节点和分片节点进行重启前检测对应的重启条件,并在重启后进行对应的重启检测,从而在能够及时发现数据库的错误,并主动快速修复,提高了数据库的使用效率的前提下,并保证修复的成功率。
图5为本发明实施例的用于MongoDB数据分片集群的检测装置结构示意图,图6为本发明实施例的用于MongoDB数据分片集群的检测的整体架构示意图,如图5所示,所述装置包括:第一检测模块10、第二检测模块11、重启执行模块12、第三检测模块13和索引建立模块14,其中,
所述第一检测模块10用于依次检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果;所述指定端口包括:接收客户端访问请求的端口;所述重启执行模块12用于若存在表征指定端口的连通性不正常的第一类检测结果,则指示重启连通性不正常的指定端口所属的节点;所述第二检测模块11用于若根据所述第一类检测结果判定任一主分片节点的指定端口连通性正常,则检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果;其中,每个复制集包括一个主分片节点和至少一个从分片节点;所述重启执行模块12还用于若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的分片节点;所述第三检测模块13用于若不存在表征分片节点的状态不正常的第二类检测结果,则检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果;索引建立模块14,用于若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则执行预设的慢查询修复策略。具体地:
为了能够正常访问所述MongoDB数据分片集群中的各个节点,所述第一检测模块10需要先检测所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常。
具体的检测顺序,根据MongoDB数据分片集群的架构,可以先检测每个路由节点的指定端口;若所有的路由节点的指定端口均正常,再检测每个数据节点的指定端口;若所有的数据节点的指定端口均正常,再检测每个主分片节点的指定端口。
所述第一检测模块10根据每个路由节点、数据节点和主分片节点在检测期间回复的检测反馈信息,得到第一类检测结果。
根据所述第一类检测结果,若所有的节点的指定端口的连通性均正常,则表明可以通过向指定端口发送访问请求来登录任一节点或者对所述MongoDB数据分片集群中保存的数据进行读\写操作。
若根据得到的第一类检测结果为存在任一指定端口的连通性不正常,所述第一检测模块10将该指示端口所述的节点的信息发送给所述重启执行模块12。所述重启执行模块12将终止本次周期性检测,并指示该指定端口所属的节点执行重启操作。
在对每个路由节点的指定端口进行检测过程中,若根据第一类检测结果判定指定端口的连通性不正常,则所述重启执行模块12将终止本次周期性检测,并指示该路由节点执行重启操作。
在对每个数据节点的指定端口进行检测过程中,若根据第一类检测结果判定指定端口的连通性不正常,则所述重启执行模块12将终止本次周期性检测,并指示该数据节点执行重启操作。
在对每个主分片节点的指定端口进行检测过程中,若根据第一类检测结果判定指定端口的连通性不正常,则所述重启执行模块12将终止本次周期性检测,并指示该主分片节点执行重启操作。
通过对所有节点的连通性进行检测的过程中,所述第一检测模块10获取到所有主分片节点的地址,并登录每个主分片节点,同时向所述第二检测模块11发送检测指令。
则所述第二检测模块11可向登录的主分片节点调用该主分片节点所在的复制集中所有分片节点的状态信息。并根据对所有分片节点的状态信息的分析来判断每个分片节点的状态是否正常,包括该复制集中的主分片节点以及每个从分片节点的状态,从而得到了第二类检测结果。
若所述第二检测模块11根据第二类检测结果判定任一分片节点的状态不正常,则所述第二检测模块11同样将状态不正常的分片节点发送给所述重启执行模块12。所述重启执行模块12将停止本次周期性检测,并通过远程指示该任一分片节点执行重启操作。
而若所述第一检测模块10根据得到的第一类检测结果判定所有路由节点、数据节点和主分片节点的指定端口的连通性均正常,且所述第二检测模块11根据第二类检测结果判定所有分片节点的状态也均正常,相当于判定所述MongoDB数据分片集群中的路由节点集群、数据节点集群和分片节点集群均正常。
此时,所述第二检测模块11将指示所述第三检测模块13可继续检测所述MongoDB数据分片集群中是否存在慢查询,并根据慢查询检测结果得到第三类检测结果。
若所述第三检测模块13根据第三类检测结果判定存在慢查询,将判定结果发送给索引建立模块14。所述索引建立模块14则结束本次周期检测,并执行预设的慢查询自动修复策略。由于出现慢查询一般和MongoDB数据分片集群中用于存储数据的表结构设计和读写方式有关,目前的自动化修改策略是由所述索引建立模块14从第三类检测结果中提取出其中包括的所有慢查询,所述慢查询至少包括表名和列名。将与提取出的表名和列名对应的列在数据库中与为每个表建立的索引进行对照,以查看所述数据库是否已经为与提取的表名和列名对应的列建立了相对应的索引,若没有则新建与提取的表名和列名对应的新的索引,以便加快后续对与该提取的表名和列名对应的列的查询速度。
如图6所示,基于Linux系统,本发明实施例给出了实现的整体部署架构分为三个部分,分别为安装有MongoDB服务端的设备,安装了MongoDB客户端的设备,以及给运维人员提供监测结果的设备。MongoDB客户通过运行检测的脚本程序,通过Linux系统提供的nc命令,周期检测MongoDB服务端并收集检测结果,并根据检测结果向运维人员发送SpringBoot提醒服务,从而使运维人员能够及时应对相应的故障。
本发明实施例提供的装置用于执行上述方法,其功能具体参考上述方法实施例,其具体方法流程在此处不再赘述。
本发明实施例通过对所有的路由节点、数据节点和主分片节点的连通性进行检测得到第一类检测结果,并调用每个分片节点的状态信息以得到第二类检测结果,再继续进行慢查询检测以得到第三类检测结果,并根据所述检测结果执行相应的修复策略,从而能够及时发现数据库的错误,并主动快速修复,以提高数据库的使用效率。
图7示例了一种电子设备的实体结构示意图,如图7所示,该服务器可以包括:处理器(processor)810、通信接口(Communications Interface)820、存储器(memory)830和通信总线840,其中,处理器810,通信接口820,存储器830通过通信总线840完成相互间的通信。处理器810可以调用存储器830中的逻辑指令,以执行如下方法:依次检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果;所述指定端口包括:接收客户端访问请求的端口;若存在表征指定端口的连通性不正常的第一类检测结果,则指示重启连通性不正常的指定端口所属的节点;若根据所述第一类检测结果判定任一主分片节点的指定端口连通性正常,则检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果;其中,每个复制集包括一个主分片节点和至少一个从分片节点;若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的分片节点;若不存在表征分片节点的状态不正常的第二类检测结果,则检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果;若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则执行预设的慢查询修复策略。
进一步地,本发明实施例公开一种计算机程序产品,所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序,所述计算机程序包括程序指令,当所述程序指令被计算机执行时,计算机能够执行上述各方法实施例所提供的方法,例如包括:依次检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果;所述指定端口包括:接收客户端访问请求的端口;若存在表征指定端口的连通性不正常的第一类检测结果,则指示重启连通性不正常的指定端口所属的节点;若根据所述第一类检测结果判定任一主分片节点的指定端口连通性正常,则检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果;其中,每个复制集包括一个主分片节点和至少一个从分片节点;若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的分片节点;若不存在表征分片节点的状态不正常的第二类检测结果,则检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果;若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则执行预设的慢查询修复策略。
进一步地,本发明实施例提供一种非暂态计算机可读存储介质,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令使所述计算机执行上述各方法实施例所提供的方法,例如包括:依次检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果;所述指定端口包括:接收客户端访问请求的端口;若存在表征指定端口的连通性不正常的第一类检测结果,则指示重启连通性不正常的指定端口所属的节点;若根据所述第一类检测结果判定任一主分片节点的指定端口连通性正常,则检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果;其中,每个复制集包括一个主分片节点和至少一个从分片节点;若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的分片节点;若不存在表征分片节点的状态不正常的第二类检测结果,则检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果;若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则执行预设的慢查询修复策略。
本领域普通技术人员可以理解:此外,上述的存储器830中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random AccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种MongoDB数据分片集群的节点重启方法,其特征在于,包括:
依次检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果;所述指定端口包括:接收客户端访问请求的端口;
若存在表征指定端口的连通性不正常的第一类检测结果,则指示重启连通性不正常的指定端口所属的节点;
若根据所述第一类检测结果判定任一主分片节点的指定端口连通性正常,则检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果;其中,每个复制集包括一个主分片节点和至少一个从分片节点;
若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的从分片节点;
若不存在表征分片节点的状态不正常的第二类检测结果,则检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果;
若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则执行预设的慢查询修复策略。
2.根据权利要求1所述的用于MongoDB数据分片集群的检测方法,其特征在于,所述依次检测所述MongoDB数据分片集群中所有路由节点、所有数据节点和所有主分片节点的指定端口的连通性是否正常,以得到第一类检测结果,具体包括:
根据预存的所有路由节点的地址向每个路由节点发送连通性检测指令,以使所述路由节点回复检测反馈信息;
若根据由所述路由节点发送的检测反馈信息,判定所有路由节点的指定端口的连通性正常,则向所述路由节点发送数据节点的地址请求,以使所述路由节点回复所有数据节点的地址;
根据所有数据节点的地址,向每个数据节点发送所述连通性检测指令,以使所述数据节点回复所述检测反馈信息;
若根据由所述数据节点发送的检测反馈信息,判定所有数据节点的指定端口连通性正常,则向所述路由节点发送分片节点的地址请求,以使所述路由节点回复所有分片节点的地址;
根据所有主分片节点的地址,依次向每个主分片节点发送登录请求;
若登录成功,则判定所述主分片节点的指定端口连通性正常。
3.根据权利要求2所述的用于MongoDB数据分片集群的检测方法,其特征在于,所述检测所述任一主分片节点所在复制集中的所有分片节点的状态是否正常,以得到第二类检测结果,具体包括:
在登录所述主分片节点后,向所述主分片节点发送状态信息请求,以使所述主分片节点回复所述主分片节点所在复制集中所有分片节点状态信息;其中,所述状态信息包括可用信息和健康信息;
若根据所述可用信息判定所述分片节点的可以正常访问,且根据所述健康信息判定所述分片节点当前未被其它进程占用,则所述分片节点的状态为正常。
4.根据权利要求3所述的用于MongoDB数据分片集群的检测方法,其特征在于,所述若存在表征分片节点的状态不正常的第二类检测结果,则指示重启状态不正常的从分片节点,具体包括:
若根据任一分片节点的可用信息判定所述分片节点无法正常访问,则指示重启所述分片节点;
若根据任一分片节点的健康信息在预设周期数内连续判定所述分片节点被其它进程占用,则结束本次周期性检测,直接指示将与所述片节点对应的主分片节点的数据拷贝到所述分片节点,并指示重启所述分片节点。
5.根据权利要求4所述的用于MongoDB数据分片集群的检测方法,其特征在于,所述继续检测所述MongoDB数据分片集群是否存在慢查询,以得到第三类检测结果,具体包括:
登录每个路由节点,并向所述路由节点发送包括预设时间阈值的慢查询检测指令,以使所述路由节点根据所述时间阈值执行慢查询检测,并回复慢查询检测结果,所述慢查询检测结果包括所有查询耗时超过所述时间阈值的慢查询。
6.根据权利要求5所述的用于MongoDB数据分片集群的检测方法,其特征在于,所述方法还包括:
根据本次周期检测的结果,更新预设的复数个预警状态的标记;其中所述预警状态包括第一状态、第二状态、第三状态、第四状态和第五状态;具体地:
若存在表征任一路由节点的指定端口连通性不正常的第一类检测结果,则将所述第一状态标记为异常;
若存在表征任一数据节点的指定端口连通性不正常的第一类检测结果,则将所述第二状态标记为异常;
若存在表征任一主分片节点的指定端口连通性不正常的第一类检测结果,或者存在表征任一分片节点的状态为无法正常访问的第二类检测结果,则将所述第三状态标记为异常;
若存在表征任一分片节点的状态为被其它进程占用的第二类检测结果,则将所述第四状态标记为异常;
若存在表征所述MongoDB数据分片集群存在慢查询的第三类检测结果,则将所述第五状态标记为异常;相应地,所述方法还包括:
若任一预警状态被标记为异常,则查看预设的与所述预警状态一一对应的报警计时器;
若所述报警计时器没有开启,则触发与所述预警状态对应的报警提醒,并开启所述报警计时器;
若所述报警计时器的数值超过了预设的间隔阈值,则触发与所述预警状态对应的报警提醒,并重置所述报警计时器。
7.根据权利要求6所述的用于MongoDB数据分片集群的检测方法,其特征在于,所述方法还包括:
在本次周期检测期间,若任一预警状态由异常变为正常,则触发与所述预警状态一一对应的恢复提醒,并关闭与所述预警状态对应的报警计时器。
8.根据权利要求1-7任一所述的用于MongoDB数据分片集群的检测方法,其特征在于,所述指示重启所述任一节点或任一分片节点,具体包括:
在所述路由节点重启前,需要满足预设的路由节点重启条件,并在重启后执行预设的路由节点重启检测;
在所述数据节点重启前,需要满足预设的数据节点重启条件,并在重启后执行预设的数据节点重启检测;
在所述分片节点重启前,需要满足预设的分片节点重启条件,并在重启后执行预设的分片节点重启检测。
9.一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时实现如权利要求1至8任一项所述用于MongoDB数据分片集群的检测方法的步骤。
10.一种非暂态计算机可读存储介质,其上存储有计算机程序,其特征在于,该计算机程序被处理器执行时实现如权利要求1至8任一项所述用于MongoDB数据分片集群的检测方法的步骤。
CN201910567367.4A 2019-06-27 2019-06-27 一种用于MongoDB数据分片集群的检测方法及设备 Active CN110275793B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910567367.4A CN110275793B (zh) 2019-06-27 2019-06-27 一种用于MongoDB数据分片集群的检测方法及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910567367.4A CN110275793B (zh) 2019-06-27 2019-06-27 一种用于MongoDB数据分片集群的检测方法及设备

Publications (2)

Publication Number Publication Date
CN110275793A true CN110275793A (zh) 2019-09-24
CN110275793B CN110275793B (zh) 2023-04-07

Family

ID=67963610

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910567367.4A Active CN110275793B (zh) 2019-06-27 2019-06-27 一种用于MongoDB数据分片集群的检测方法及设备

Country Status (1)

Country Link
CN (1) CN110275793B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111767282A (zh) * 2020-06-12 2020-10-13 咪咕文化科技有限公司 基于MongoDB的存储系统及数据插入方法和存储介质
CN113849458A (zh) * 2021-09-18 2021-12-28 四川长虹网络科技有限责任公司 MongoDB中间件及数据存储方法和数据迁移方法
CN114168221A (zh) * 2021-11-30 2022-03-11 紫光云(南京)数字技术有限公司 一种云管理平台上重启mongodb集群的方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170272209A1 (en) * 2016-03-15 2017-09-21 Cloud Crowding Corp. Distributed Storage System Data Management And Security
CN108282522A (zh) * 2018-01-15 2018-07-13 吉浦斯信息咨询(深圳)有限公司 基于动态路由的数据存储访问方法及系统
CN108833131A (zh) * 2018-04-25 2018-11-16 北京百度网讯科技有限公司 分布式数据库云服务的系统、方法、设备和计算机存储介质
CN109656911A (zh) * 2018-12-11 2019-04-19 江苏瑞中数据股份有限公司 分布式并行处理数据库系统及其数据处理方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170272209A1 (en) * 2016-03-15 2017-09-21 Cloud Crowding Corp. Distributed Storage System Data Management And Security
CN108282522A (zh) * 2018-01-15 2018-07-13 吉浦斯信息咨询(深圳)有限公司 基于动态路由的数据存储访问方法及系统
CN108833131A (zh) * 2018-04-25 2018-11-16 北京百度网讯科技有限公司 分布式数据库云服务的系统、方法、设备和计算机存储介质
CN109656911A (zh) * 2018-12-11 2019-04-19 江苏瑞中数据股份有限公司 分布式并行处理数据库系统及其数据处理方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111767282A (zh) * 2020-06-12 2020-10-13 咪咕文化科技有限公司 基于MongoDB的存储系统及数据插入方法和存储介质
CN113849458A (zh) * 2021-09-18 2021-12-28 四川长虹网络科技有限责任公司 MongoDB中间件及数据存储方法和数据迁移方法
CN114168221A (zh) * 2021-11-30 2022-03-11 紫光云(南京)数字技术有限公司 一种云管理平台上重启mongodb集群的方法

Also Published As

Publication number Publication date
CN110275793B (zh) 2023-04-07

Similar Documents

Publication Publication Date Title
CN109756364B (zh) 一种基于日志分析的微服务性能优化系统和分析方法
US9672085B2 (en) Adaptive fault diagnosis
JP5684946B2 (ja) イベントの根本原因の解析を支援する方法及びシステム
CN110888783B (zh) 微服务系统的监测方法、装置以及电子设备
CN108833197B (zh) 一种基于云的主动探测方法和探测平台
CN110275793A (zh) 一种用于MongoDB数据分片集群的检测方法及设备
US9104572B1 (en) Automated root cause analysis
CN104011719B (zh) 消息跟踪和检查的方法和系统
US20060200450A1 (en) Monitoring health of actively executing computer applications
CN103746829B (zh) 一种基于集群的故障感知系统及其方法
CN103069749B (zh) 虚拟环境中的问题的隔离的方法和系统
CN109120461B (zh) 一种业务性能端到端监控方法、系统及装置
CN105376314B (zh) 一种将环境监测分析数据提取到lims的方法及装置
CN102567185B (zh) 一种应用服务器的监控方法
CN104268061A (zh) 一种适用于虚拟机的存储状态监控机制
CN105302697B (zh) 一种密集数据模型数据库的运行状态监控方法及系统
CN109308227A (zh) 故障检测控制方法及相关设备
CN103368771A (zh) 一种多节点服务器系统的故障现场信息的收集方法及装置
CN108009004B (zh) 基于Docker的业务应用可用度测量监控的实现方法
CN114356499A (zh) Kubernetes集群告警根因分析方法及装置
CN107579858A (zh) 云主机的告警方法及装置、通信系统
CN109062769A (zh) It系统性能风险趋势预测的方法、装置和设备
US11263072B2 (en) Recovery of application from error
CN109921963B (zh) 一种网络状态巡检方法及系统
JP6666489B1 (ja) 障害予兆検知システム

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