分布式数据库的事务监控方法及装置、系统、存储介质
技术领域
本发明实施例涉及但不限于分布式数据库的事务监控方法及装置、系统、存储介质。
背景技术
分布式数据库已经成为数据库发展的一个重点方向,分布式数据库GoldenDB的总体架构如图1所示,结合图1描述如下:
业务端也就是客户接入层,由多个应用APP组成,支持通用的ODBC(Open DatabaseConnectivity,开放数据库连接)和JDBC(Java DataBase Connectivity,java数据库连接)接口,用户通过客户接入层使用分布式数据库;
计算节点集群由多个中间件DBProxy(DB代理节点)组成,SQL语句在计算节点中完成基本的处理和分发;
管理节点包括多个组件,比如OMM(Operation Maintenance Module,操作维护模块)Server(服务器),MDS(Meta Data Server,元数据服务器),PM(Proxy Manager,代理节点管理中心),CM(Cluster Manager,集群管理中心)等,用于管理和保障分布式数据库系统;
全局事务管理GTM主要用于生成和维护分布式事务的全局事务ID(Identity,标识);
数据节点集群由多个DB-GROUP(数据库群组)组成,每个DB-GROUP由1主1备(或多备)的DB(Database,数据库)构成;
后置中间件主要对数据节点进行监测,备份,恢复等。
目前针对单机数据库的监控措施有很多,比如MySQL自身的performance_schema监控,主备复制状态监控等等。但是对于业务端、计算节点、数据节点分离的大型分布式数据库系统,数据节点的单独监控并不能满足分布式数据库运维和管理需求。
发明内容
本发明至少一实施例提供了一种分布式数据库的事务监控方法及装置、系统、存储介质。
本发明至少一实施例提供一种分布式数据库的事务监控方法,包括:
接收到事务的执行请求后,记录所述事务的执行请求中携带的事务指示信息;
根据所述事务指示信息进行事务监控。
本发明至少一实施例提供一种分布式数据库的事务监控方法,包括:
节点发送事务的执行请求,在所述事务的执行请求中携带事务指示信息。
本发明至少一实施例提供一种分布式数据库的事务监控系统,包括:
数据节点,用于接收到事务的执行请求后,记录所述事务的执行请求中携带的事务指示信息;
管理节点,用于根据所述事务指示信息进行事务监控。
本发明至少一实施例提供一种分布式数据库的事务监控装置,包括存储器和处理器,所述存储器存储有程序,所述程序在被所述处理器读取执行时,实现任一实施例所述的分布式数据库的事务监控方法。
本发明至少一实施例提供一种计算机可读存储介质,所述计算机可读存储介质存储有一个或者多个程序,所述一个或者多个程序可被一个或者多个处理器执行,以实现任一实施例所述的分布式数据库的事务监控方法。
与相关技术相比,本发明一实施例中,包括接收到事务的执行请求后,记录所述事务的执行请求中携带的事务指示信息;根据所述事务指示信息进行事务监控。本实施例提供的方案,提高了运维效率。
本发明的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本发明技术方案的进一步理解,并且构成说明书的一部分,与本申请的实施例一起用于解释本发明的技术方案,并不构成对本发明技术方案的限制。
图1为分布式数据库总体架构图;
图2为本发明一实施例提供的分布式数据库的事务监控方法流程图;
图3为分布式数据库事务核心信息分层图;
图4为本发明一实施例提供的分布式数据库的事务监控方法流程图;
图5为本发明一实施例提供的数据节点执行过程流程图;
图6为本发明一实施例提供的死锁事务分析方案实施流程图;
图7为本发明一实施例提供的分布式事务异常处理方案实施流程图;
图8为本发明一实施例提供的分布式数据库的事务监控方法流程图;
图9为本发明一实施例提供的分布式数据库的事务监控系统框图;
图10为本发明一实施例提供的分布式数据库的事务监控装置框图;
图11为本发明一实施例提供的计算机可读存储介质框图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白,下文中将结合附图对本发明的实施例进行详细说明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互任意组合。
在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
在普通的分布式数据库系统中,当异常问题出现在一个数据节点时,无法直接定位该异常事务的业务端来源,也无法直接进行分布式全局事务异常处理。
如图2所示,本发明一实施例提供一种分布式数据库的事务监控方法,包括:
步骤201,接收到事务的执行请求后,记录所述事务的执行请求中携带的事务指示信息;
其中,事务的执行请求可以是事务的第1条至第N条语句中任一条或多条、也可以是第1条语句之前的管理命令等。语句可以是sql语句。
步骤202,根据所述事务指示信息进行事务监控。
本发明实施例提供的方案,记录了事务指示信息,便于通过事务指示信息定位事务,增强了分布式数据库的运维手段,可以有效提升分布式数据库的运维效率,大大简化分布式事务异常处理流程。
其中,事务指示信息是事务的一标识信息,事务指示信息可以是事务流水号(TSN:trx serial num),也可以是全局事务标识(GTID:global trx ID,全局事务ID),还可以是事务流水号和全局事务ID。需要说明的是,使用TSN和全局事务ID仅为示例,也可根据需要使用其他能够指示事务的标识信息,或者,使用新定义的信息等。
对于分布式数据库分层结构,每一层均有相应的核心事务信息,如图3所示,包括:
事务流水号信息,由业务端产生,可以通过事务流水号追溯事务的业务来源。在相关技术中,对于计算节点和数据节点,TSN信息不可见,因此在数据节点中,无法追溯事务的业务来源;在一实施例中,在事务的执行请求中携带事务流水号,从而数据节点可以通过事务流水号追溯事务的业务来源。
事务的全局事务ID信息,在计算节点产生,可唯一标识一个事务。在一实施例中,在事务的执行请求中携带全局事务ID,实现分布式全局事务异常处理。
事务ID(TRX_ID),在数据节点产生,为事务的真正执行信息及其相关信息,对于分布式数据库系统,仅仅分析单个数据节点的事务情况,不能够满足分布式数据库的要求。
需要说明的是,使用事务流水号和/或全局事务ID作为事务指示信息仅为示例。
在一实施例中,将上述TSN和全局事务ID作为事务指示信息,通过执行请求发送到数据节点,数据节点记录所述TSN和全局事务ID,根据TSN和全局事务ID进行事务监控。具体的,业务端将TSN发送给计算节点,计算节点将TSN和全局事务ID发送给数据节点。本实施例提供的方案,可以实现分布式数据库中在数据节点进行全链路监控。
在另一实施例中,将上述TSN作为事务指示信息,通过执行请求发送到数据节点,数据节点记录所述TSN,根据TSN进行事务监控。具体的,业务端将TSN发送给计算节点,计算节点将TSN发送给数据节点。
在另一实施例中,将上述全局事务ID作为事务指示信息,通过执行请求发送到数据节点,数据节点记录所述全局事务ID,根据全局事务ID进行事务监控。具体的,计算节点将全局事务ID发送给数据节点。
其中,记录所述事务在所述分布式数据库的数据节点的事务标识和所述事务的事务指示信息的关联关系。即,记录TSN、全局事务ID时,将其和TRX_ID进行关联。
TSN信息和全局事务ID信息在解析之后,每一个事务会生成一条数据记录,记录中主要包括了TRX_ID,TSN,全局事务ID等信息,写入数据库内部临时表中,管理节点可以通过一个SQL查询语句获取内部临时表中该事务的TSN信息和全局事务ID信息。
其中,当数据节点事务发生异常时,可以根据TSN追溯事务的业务来源,从而分析数据节点异常现象根本原因,进而解决该异常。在数据节点上关联分布式全局事务ID,可以用于进行分布式全局事务的异常处理。
在一实施例中,所述根据所述事务指示信息进行事务监控包括:
当事务异常时,根据所述事务的事务流水号确定所述事务的业务来源。具体的,获取异常事务的TRX_ID,根据TRX_ID关联的事务流水号确定事务的业务来源。
在一实施例中,所述根据所述事务指示信息进行事务监控包括:
当事务异常时,根据所述异常的事务的所述全局事务标识确定所述异常事务的事务标识。比如,监控到事务异常时,根据事务的GTID确定TRX_ID,进而可以对数据节点中相应TRX_ID指示的事务进行处理。
在一实施例中,所述事务的执行请求中的事务指示信息通过预设注释格式携带。在一实施例中,事务中的sql语句按照/*+*/所示的预设注释格式增加事务指示信息,以HINT(提示)信息的方式增加。HINT信息将会被解析、缓存在线程thd中,sql执行流程将不受HINT信息影响;在一实施例中,TSN信息格式为/*+TSN=?*/,通过事务所关联的TSN信息,能够直接追溯事务的业务端来源;GTID信息的格式为/*+GTID=?*/,通过事务所关联的GTID信息,能够在事务异常时,直接根据GTID进行分布式事务异常处理。需要说明的是,上述格式仅为示例,可以根据需要使用其他格式携带。
采用本发明实施例所述技术,与现有技术相比,能够在数据节点完成分布式事务的全链路监控,进而在分布式事务异常时,自动完成分布式事务异常处理。
本发明一实施例提供一种分布式数据库的事务监控方法,如图4所示,包括:
步骤401,业务端1发起事务1,设置事务2的事务流水号为TSN_1;
步骤402,业务端2发起事务2,设置事务2的事务流水号为TSN_2;
步骤403,计算节点接收到业务端1的事务1和业务端2的事务2,为事务1和事务2分配GTID,设置事务1的GTID为GTID_1,设置事务2的GTID为GTID_2。将事务1和事务2分发至不同的数据节点执行;
步骤404,数据节点1的链路1收到事务1执行请求。执行事务1,在链路上的事务1执行过程中,利用事务1中携带的TSN_1和GTID_1完成在该节点对事务1的全链路监控;
步骤405,数据节点1的链路2收到事务2执行请求。执行事务2,在链路上的事务2执行过程中,利用事务2中携带的TSN_2和GTID_2完成在该节点对事务2的全链路监控;
步骤406,数据节点2的链路1收到事务2执行请求。数据节点2执行事务2,在链路上的事务2执行过程中,利用事务2中携带的TSN_2和GTID_2完成在该节点对事务2的全链路监控。
其中,对于事务在数据节点的详细处理流程如图5所示,包括:
步骤501,业务端发起事务开始命令;
步骤502,计算节点发送事务内第1条sql语句到数据节点,该sql语句携带事务流水号TSN信息(一HINT信息)和事务全局事务GTID信息(另一HINT信息);
步骤503,数据节点解析sql_1语句,同时解析sql语句携带的两种HINT信息;
步骤504,数据节点将解析到的两种HINT信息以字符串的形式保存在线程的Thd对象中,供该连接上整个事务阶段使用;
步骤505,数据节点继续执行该携带HINT信息的sql语句,即第1条语句;
步骤506,数据节点执行事务内的第2条至第n条语句,以及结束语句。
需要说明的是,第2条至第n条语句可以携带上述HINT信息,也可以不携带HINT信息。
在步骤505~506过程中,数据节点监控数据节点收到事务信息。具体包括:记录数据节点的事务id信息及其关联的事务流水号TSN信息,记录数据节点的事务id信息及其关联的全局事务GTID信息,记录数据节点事务id信息及本身的相关信息如锁、执行sql语句、执行时间等等。
在步骤505~506过程中,当出现异常问题时,通过事务id所关联的事务流水号(TSN)信息,在数据节点直接定位事务的业务来源;通过事务id所关联的全局事务ID(GTID)信息,在数据节点利用GTID直接进行分布式全局事务异常处理。
以下结合具体实施例对本发明方案进行阐述。
实施例1
本实施例提供一种死锁事务分析的实施方案。死锁事务分析中,通过事务所关联的TSN信息追溯事务的业务来源,有效提升了分布式数据库的运维效率。技术实施流程图如图6所示,具体描述如下:
步骤601,业务端发起事务1,事务1的开始第1条语句中携带事务流水号信息TSN1;
步骤602,业务端发起事务2,事务2的开始第1条语句中携带事务流水号信息TSN2;
步骤603,计算节点进行事务的分发处理;
步骤604,数据节点1中的链路1处理事务1的请求,记录TSN1;
步骤605,数据节点1中的链路2处理事务2的请求,记录TSN2;
步骤606,数据节点1中的链路2执行事务2的过程中,产生了死锁,回滚事务2,返回执行失败给计算节点;
步骤607,数据节点1中的链路1执行事务1成功;
步骤608,管理节点监控到数据节点1中的事务2发生了死锁场景;
步骤609,管理节点分析死锁信息,从死锁信息中获知了死锁并回滚的事务2的TRX_ID_2,以及导致事务2死锁的事务1的TRX_ID_1;
步骤610,管理节点查找事务TRX_ID1以及TRX_ID2对应的事务流水号TSN1及TSN2;
其中,管理节点可以SQL查询语句从数据库内部临时表中获取一条TRX_ID1相关的记录,该记录中包括了该事务对应的TSN信息。
步骤611,管理节点根据TSN信息定位事务的业务端来源,TSN1定位到业务端的事务1,TSN2定位到业务端的事务2;
步骤612,根据业务端事务1的事务逻辑以及业务端事务2的事务逻辑,分析事务1和事务2产生死锁的原因,修改产生死锁的事务逻辑,完成对死锁问题的分析和解决。
需要说明的是,步骤612可以由管理节点自动完成,也可以人工完成,即步骤611中输出事务的业务端来源即可,后续人工完成异常处理。
实施例2
本实施例提供一种分布式事务异常处理的实现方案。本实施例中,采用了数据节点事务记录事务指示信息的方法,通过事务所关联的GTID信息进行分布式事务异常处理,大大简化分布式事务异常处理流程。技术实施流程图如图7所示,具体描述如下:
步骤701,业务端发起分布式事务1;
步骤702,计算节点接收到分布式事务1的请求,首先分配全局事务ID(GTID),然后根据分布式事务的分发规则,将事务1的语句分发至分布式数据库的多个数据节点执行;
步骤703,数据节点1执行事务1成功;
步骤704,数据节点2执行事务1,由于异常原因,导致事务1执行hang住(挂死,事务即没有返回成功,也没有返回失败);
步骤705,数据节点3执行事务1,由于异常原因,导致事务1执行失败;
步骤706,管理节点监控到计算节点中的事务1执行异常(未明确返回成功/失败响应,执行时间过长);
步骤707,管理节点在计算节点获取异常事务1的GTID信息;
步骤708,根据GTID信息在3个数据节点中查找GTID值匹配的异常事务1;
相关技术中,无法直接根据GTID确定数据节点中的事务(相关技术中,数据节点中只有事务的TRX_ID,无GTID,因此,无法将GTID和数据节点中的事务进行对应),因此,需要人工方式在数据节点中查找到异常事务1,而本实施例中,只需查找GTID匹配到的事务即可,提高了运维效率。
步骤709,通过匹配查找,发现数据节点1的事务1执行成功;数据节点2的事务1执行hang住;数据节点3的事务1执行失败;
步骤710,在数据节点2上执行事务1的异常处理,如kill query(终止任务)等;
步骤711,待计算节点收到全部数据节点的响应后,触发分布式事务1的GTID的已提交事务回滚操作。
由于数据节点2和数据节点3事务执行失败,因此,仅需要在数据节点1上执行事务1的已提交事务回滚操作。
至此,完成分布式事务的异常处理。通过数据节点的TRX_ID关联GTID信息,简化了分布式事务的异常处理流程。
如图8所示,本发明一实施例提供一种分布式数据库的事务监控方法,包括:
步骤801,节点发送事务的执行请求,在所述事务的执行请求中携带事务指示信息。
在一实施例中,所述节点为所述分布式数据库的业务端,所述事务指示信息为事务流水号;或者,所述节点为所述分布式数据库的计算节点,所述事务指示信息为全局事务标识。
如图9所示,本发明一实施例提供一种分布式数据库的事务监控系统,包括:
数据节点901,用于接收到事务的执行请求后,记录所述事务的执行请求中携带的事务指示信息;
管理节点902,用于根据所述事务指示信息进行事务监控。
在一实施例中,所述事务监控系统还包括业务端903,所述业务端903用于,发送事务的执行请求,在所述事务的执行请求中携带事务指示信息。
在一实施例中,所述事务监控系统还包括计算节点904,所述计算节点904用于,发送事务的执行请求至所述数据节点901,在所述事务的执行请求中携带事务指示信息。
在一实施例中,所述管理节点902根据所述事务指示信息进行事务监控包括以下至少之一:
所述管理节点902在事务异常时,根据所述事务指示信息中的事务流水号确定所述事务的业务来源;
所述管理节点902在事务异常时,根据所述异常的事务的所述全局事务标识确定数据节点中所述异常事务。
如图10所示,本发明一实施例提供一种分布式数据库的事务监控装置100,包括存储器1010和处理器1020,所述存储器1010存储有程序,所述程序在被所述处理器1020读取执行时,实现任一实施例所述的分布式数据库的事务监控方法。
如图11所示,本发明一实施例一种计算机可读存储介质110,所述计算机可读存储介质存储110有一个或者多个程序1110,所述一个或者多个程序1110可被一个或者多个处理器执行,以实现任一实施例所述的分布式数据库的事务监控方法。
本领域普通技术人员可以理解,上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中,在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分;例如,一个物理组件可以具有多个功能,或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器,如数字信号处理器或微处理器执行的软件,或者被实施为硬件,或者被实施为集成电路,如专用集成电路。这样的软件可以分布在计算机可读介质上,计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的,术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外,本领域普通技术人员公知的是,通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据,并且可包括任何信息递送介质。