SQL的查询方法、装置及存储介质

技术领域

本申请涉及数据处理领域，尤其涉及一种SQL的查询方法、装置及存储介质。

背景技术

随着科技的不断发展，移动支付的不断普及，支付数据量也在不断递增。而这些递增的用户和数据对金融数据库系统的高性能、高并发、高可用、安全性等特性提出了更高的要求，传统单体架构已经无法满足需求，于是分布式数据库便应运而生。不同于传统的金融级数据库对计算机存储性能、运算能力近乎苛刻的超高要求，分布式数据库可以通过增加更多的数据库节点(Data Node，DN)，来满足数据量日益递增的使用需求。而随着DN节点的逐渐增多，分布式事物的一致性也变的更加复杂。全局事务标识符((Global TransactionIdentifier,GTID)为数据库中分布式事务的关键所在，在一些复杂业务的结构化查询语句(Structured Query Language，SQL)语句在执行时，GTID会一直处于活跃状态导致新的业务SQL语句一直被阻塞进而影响客户使用。在发生该问题时，由于缺乏分析手段无法及时反映出问题并且不能够准确找出具体的异常SQL语句。

发明内容

本申请提供了一种SQL的查询方法、装置及存储介质，以解决现有技术中在GTID会一直处于活跃状态导致新的业务SQL语句一直被阻塞时，无法及时反映出问题并且不能够准确找出具体的异常SQL语句的问题。

第一方面，本申请提供了一种结构化查询语言SQL的查询方法，包括：在数据库中的全局事务标识GTID出现冲突后，接收上报的错误信息，其中，所述错误信息中包括出现冲突的GTID和对应的时间戳；基于出现冲突的GTID和对应的时间戳，向数据节点发送可执行文件，其中，所述可执行文件用于出现冲突的GTID和对应的时间戳解析所述数据节点的日志；接收所述数据节点基于所述可执行文件解析得到所有的SQL。

第二方面，本申请提供了一种结构化查询语言SQL的查询装置，包括：第一接收模块，用于在数据库中的全局事务标识GTID出现冲突后，接收上报的错误信息，其中，所述错误信息中包括出现冲突的GTID和对应的时间戳；发送模块，用于基于出现冲突的GTID和对应的时间戳，向数据节点发送可执行文件，其中，所述可执行文件用于出现冲突的GTID和对应的时间戳解析所述数据节点的日志；第二接收模块，用于接收所述数据节点基于所述可执行文件解析得到所有的SQL。

第三方面，提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现第一方面任一项实施例所述的SQL的查询方法的步骤。

第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项实施例所述的SQL的查询方法的步骤。

本申请实施例提供的上述技术方案与现有技术相比具有如下优点：

本申请实施例提供的该方法，在GTID出现冲突后，可以通过出现冲突的GTID和对应的时间戳，基于此向数据节点发送可执行的文件，并从数据节点查询到与出现冲突的GTID和对应的时间戳相关联的SQL，也就是说，在本申请中调用可执行文件，聚合搜索相关日志，然后将返回SQL相关信息，链路简洁并能够迅速确定出与异常相关的SQL，解决了现有技术中在GTID会一直处于活跃状态导致新的业务SQL语句一直被阻塞时，无法及时反映出问题并且不能够准确找出具体的异常SQL语句的问题。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种SQL的查询方法的流程示意图之一；

图2为本申请实施例提供的一种SQL的查询方法的流程示意图之二；

图3为本申请实施例提供的GTID冲突示意图；

图4为本申请实施例提供的一种定位GTID冲突相关SQL的方法的流程示意图；

图5为本申请实施例提供的一种SQL的查询装置的结构示意图；

图6为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请实施例提供的一种SQL的查询方法的流程示意图，如图1所示，该方法的步骤包括：

步骤101，在数据库中的全局事务标识GTID出现冲突后，接收上报的错误信息，其中，错误信息中包括出现冲突的GTID和对应的时间戳；

步骤102，基于出现冲突的GTID和对应的时间戳，向数据节点发送可执行文件，其中，可执行文件用于出现冲突的GTID和对应的时间戳解析数据节点的日志；

需要说明的是，本申请实施例中的可执行文件则是脚本文件，即是通过脚本文件来解析日志文件的。

步骤103，接收数据节点基于可执行文件解析得到所有的SQL。

通过上述步骤101至步骤103，在GTID出现冲突后，可以通过出现冲突的GTID和对应的时间戳，基于此向数据节点发送可执行的文件，并从数据节点查询到与出现冲突的GTID和对应的时间戳相关联的SQL，也就是说，在本申请中调用可执行文件，聚合搜索相关日志，然后将返回SQL相关信息，链路简洁并能够迅速确定出与异常相关的SQL，解决了现有技术中在GTID会一直处于活跃状态导致新的业务SQL语句一直被阻塞时，无法及时反映出问题并且不能够准确找出具体的异常SQL语句的问题。

本申请实施例中的执行主体可以是运维中心，该运维中心与CN(分布式数据库系统中数据库代理节点)和数据库监控代理(DBAgent)相关联，则可以是由CN上报的GTID冲突，然后由运维中心通过DBAgent向数据节点发送用于解析日志的可执行文件。

在本申请实施例的可选实施方式中，对于上述步骤102中涉及到的基于出现冲突的GTID和对应的时间戳，向数据节点发送可执行文件的方式，进一步可以包括：

方式1)：基于出现冲突的GTID和对应的时间戳，向数据库中的各个分片中的主用数据节点发送可执行文件，其中，数据库中包括多个数据节点，多个数据节点分布多个分片中，每一个分片中包括一个主用数据节点和一个或多个备用数据节点。

方式2)：基于出现冲突的GTID和对应的时间戳，向数据库中的所有分片中的目标备用数据节点，其中，数据库中包括多个数据节点，多个数据节点分布多个分片中，每一个分片中包括一个主用数据节点和一个或多个备用数据节点，目标备用数据节点为所有分片中的备用数据节点之一。

可见，在本申请实施例中有两种执行可执行文件的方式，一种是由数据库中的主节点来执行，一种由数据库中的备用节点来执行，通过这两种方式能够对数据库中的数据节点进行分类型的执行可执行文件，能够在出现GTID出现冲突后提升查找对应的SQL的效率。

在本申请实施例的可选实施方式中，对于上述步骤102中涉及到的基于出现冲突的GTID和对应的时间戳，向数据节点发送可执行文件的方式，进一步可以包括：基于出现冲突的GTID和对应的时间戳，使用数据库监控代理调用可执行文件以发送至数据节点。

在本申请实施例中，数据库监控代理(DBAgent)，是分布式数据库系统中监控及启停数据库实例的守护进程。可见，在本申请中运维中心可以直接通过采集端发送请求，使用DBAgent调用脚本(可执行文件)分析，脚本拼装查询条件聚合搜索相关binlog(日志)，将返回信息拉取到运维中心，链路简洁能够迅速确定该GTID在相应时间段内的所有相关SQL语句。

在本申请实施例中，在接收数据节点基于可执行文件解析得到所有的SQL之后，如图2所示，本申请实施例的方法还可以包括：

步骤201，对所有SQL进行分类，并在分类后进行展示。

对此，在本申请中可以基于SQL的类型进行分类，这样能够比较方便快捷的当前出现GTID冲突的SQL是什么类型的。

在本申请实施例中，本申请实施例的方法还可以包括：

步骤11，在当前第一事务未提交完成之前，确定第二事务当前所需的GTID与第一事务当前对应的GTID一致时，则确定GTID出现冲突。

在具体示例中，如图3所示，CN1向DN1和DN2发起了事务1，该事务1一直为提交完成，则对应的GTID也就一直活跃，此时如果CN2基于事务2向GTM发起查询GTID列表，如果该GTID列表中的GTID正好与事务1对应的GTID一致，则表明当前GTID无法分配给事务2，则出现了GTID冲突，只有在CN1在完成事务1之后释放GTID才能让事务2使用该GTID。

下面结合本申请实施例的具体实施方式中，对本申请进行解释说明。该具体实施方式提供了一种定位GTID冲突相关SQL的方法，如图4所示，该方法的步骤包括：

步骤401，在发生GTID错误后，CN向运维中心上报错误信息；

步骤402，运维中心下发GTID和时间戳，并行到所有分片上解析事务日志；

步骤403，DBAgent收到指令后，根据GTID和时间解析日志；

步骤404，DN向DBAgent上报解析SQL的结果；

步骤405，DBAgent向运维中心反馈该分片内GTID的所有SQL；

步骤406，拼接并展示所有SQL。

通过上述步骤401至步骤406，当系统发生活跃GTID冲突报错时，CN向运维系统上报错误信息，运维系统界面在展示错误信息的同时，智能选择分析策略，分析策略有两种，分析主机策略就是将分析工作交给各个分片的主节点做，分析备机策略则是将分析工作交给所有分片中一个备机(优先同城备机)进行分析。运维系统直接通过采集端发送请求，使用DBAgent调用脚本分析，脚本拼装查询条件聚合搜索相关binlog，将返回信息拉取到运维节点并展示结果，链路简洁快速，能够迅速展示该GTID在相应时间段内的所有相关SQL语句。

此外，在本申请实施例中，在查看GTID冲突SQL之前需要统计GTID数据，通过GTID冲突分析功能，可查看不同计算节点的GTID冲突数量。注意，此项统计需要保证对应开关打开，可以手动进行配置，在对应GTM节点的家目录下，在etc/gtm.ini中配置“ReportSwitch＝1”，动态生效(执行“dbtool-gtm-lc”)。还需要在计算节点家目录下的etc/proxy.ini中配置“gtid_conflict_stat_switch＝”，动态生效(执行“dbtool-p-lc”)。

对应于上述图1，本申请实施例还提供了一种结构化查询语言SQL的查询装置，如图5所示，该装置包括：

第一接收模块52，用于在数据库中的全局事务标识GTID出现冲突后，接收上报的错误信息，其中，错误信息中包括出现冲突的GTID和对应的时间戳；

发送模块54，用于基于出现冲突的GTID和对应的时间戳，向数据节点发送可执行文件，其中，可执行文件用于出现冲突的GTID和对应的时间戳解析数据节点的日志；

第二接收模块56，用于接收数据节点基于可执行文件解析得到所有的SQL。

可见，在本申请实施例中，在GTID出现冲突后，可以通过出现冲突的GTID和对应的时间戳，基于此向数据节点发送可执行的文件，并从数据节点查询到与出现冲突的GTID和对应的时间戳相关联的SQL，也就是说，在本申请中调用可执行文件，聚合搜索相关日志，然后将返回SQL相关信息，链路简洁并能够迅速确定出与异常相关的SQL，解决了现有技术中在GTID会一直处于活跃状态导致新的业务SQL语句一直被阻塞时，无法及时反映出问题并且不能够准确找出具体的异常SQL语句的问题。

在本申请实施例的可选实施方式中，该发送模块44进一步可以包括：第一发送单元，用于基于出现冲突的GTID和对应的时间戳，向数据库中的各个分片中的主用数据节点发送可执行文件，其中，数据库中包括多个数据节点，多个数据节点分布多个分片中，每一个分片中包括一个主用数据节点和一个或多个备用数据节点。

在本申请实施例的可选实施方式中，该发送模块54进一步可以包括：第二发送单元，用于基于出现冲突的GTID和对应的时间戳，向数据库中的所有分片中的目标备用数据节点，其中，数据库中包括多个数据节点，多个数据节点分布多个分片中，每一个分片中包括一个主用数据节点和一个或多个备用数据节点，目标备用数据节点为所有分片中的备用数据节点之一。

在本申请实施例的可选实施方式中，该发送模块54进一步可以包括：第一发送单元或第二发送单元，用于基于出现冲突的GTID和对应的时间戳，使用数据库监控代理调用可执行文件以发送至数据节点。

在本申请实施例的可选实施方式中，该装置还可以包括：处理模块，用于在接收数据节点基于可执行文件解析得到所有的SQL之后，对所有SQL进行分类，并在分类后进行展示。

在本申请实施例的可选实施方式中，该装置还可以包括：确定模块，用于在当前第一事务未提交完成之前，确定第二事务当前所需的GTID与第一事务当前对应的GTID一致时，则确定GTID出现冲突。

如图6所示，本申请实施例提供了一种电子设备，包括处理器111、通信接口112、存储器113和通信总线114，其中，处理器111，通信接口112，存储器113通过通信总线114完成相互间的通信，

存储器113，用于存放计算机程序；

在本申请一个实施例中，处理器111，用于执行存储器113上所存放的程序时，实现前述任意一个方法实施例提供的SQL的查询方法，其所起到的作用也是一致的，在此不再赘述。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如前述任意一个方法实施例提供的SQL的查询方法的步骤。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。