数据库 频道

分布式数据库转型实践:全链路跟踪分析平台赋能分布式数据库

  金融科技移动化、互联网化带来数据爆炸式增长,分布式数据库日益广泛应用于千行百业。同时由于分布式数据库自身特点,也给传统运维带来了挑战:

  首先,分布式数据库系统自身更加复杂。较传统单机数据库系统,分布式数据库规模更庞大,结构更加丰富,节点较多,数据更加分散。同时,数据规模更加海量庞大。

  其次,问题故障精准定位、快速解决更加困难。业务经过分布式数据库内部处理流程更加复杂,业务经过网络、负载均衡器、计算节点、全局事务管理节点、数据节点等环节。

  针对海量大数据处理,包括日志、告警、性能、状态等方面,为了提升精准定位,快速解决故障的能力,需要借助于大数据、人工智能等新技术,才能摆脱传统的依赖文档、脚本、手工时代。

 GoldenDB提供全链路跟踪分析能力

  GoldenDB是一款高性能、高可靠、高扩展、高兼容、金融级分布式数据库。GoldenDB产品推出了引入大数据技术的智能运维平台Insight,提供海量大数据高效处理功能,支持端到端全链路跟踪分析能力。其架构请参见图1。

  图1 GoldenDB全链路跟踪分析平台架构

  监控数据流路径:计算、数据、GTM等节点上产生的日志、性能等数据经过代理采集上报到大数据平台,最终在Web界面上展示。

  计算节点CN负责接收应用发送过来的业务语句,对业务语句做语法解析,优化等;数据节点DN用于存储业务数据以及执行分布式子事务;GTM提供全局事务管理,负责全局事务ID的生命周期管理。

  分布式数据库层面的全链路跟踪流程

  传统依靠人工登录各节点抓取各类日志分析方式定位问题,存在大量数据解析、安全隐患、效率低等弊端。而全链路跟踪工具提供事务、SQL从客户端到CN、DN各节点全流程监视能力。以下以insert流程为例进行原理说明,请参考图2:

  1) 客户端发起事务请求(如insert操作)流程:设置业务流水号。目的是为了将业务与数据库关联起来,方便快速定位业务语句问题。

  2)CN解析客户端请求语句。如果业务未set流水号,则生成流水号:CNID+会话ID+时间戳。

  3)CN向GTM申请全局事务ID(create gtid 请求)。CN从GTM接收到申请全局事务ID响应。

  4) 事务分析、处理、提交;GTID释放等。

  5) 反馈给客户端响应:CN判断GTM释放GTID成功,给客户端回复执行成功结果。如果GTM释放gtid失败,给客户端回复执行失败结果。

  6)在以上各节点、各流程过程中,同时生成相关日志、性能统计数据。

  7)大数据平台采集各节点上日志、性能数据,并且进行分析、清洗、转换、入库。

  8)insight web界面进行展示、分析。

  图2 全链路跟踪原理流程

  全链路跟踪可以根据节点类型、集群号、事务流水号、原始SQL关键字、事务执行的开始与结束时间等进行快速定位事务、SQL执行情况。提供各节点相关日志记录功能:以事务为单位进行统计输出,统计信息包括:客户端信息(IP,PORT),事务流水号,事务开始及结束时间,事务内各SQL语句信息,以及每个SQL语句对应的下到每个分片上的子SQL语句信息等。为运维人员、DBA提供可视化、端到端的故障问题快速定位新助手。全链路跟踪主要界面请参见图3。  

  图3 全链路跟踪主要功能界面

  目前通过端到端全链路跟踪分析平台应用看来,有显著的成效。

  1.提供了大数据、可视化运维平台。降低了运维人员技术门槛,降低运维时间与人力成本。

  2.全链路跟踪一键操作,提升了问题故障精准分析、快速解决的能力。

  当然,全链路跟踪目前还只是初步应用阶段,后续还会在实践中不断代迭代、优化。不断提升GoldenDB产品的简单易用水平,丰富运维能力,有效提高用户体验。

特别提醒:本网信息来自于互联网,目的在于传递更多信息,并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益,请及时联系我们,本站将会在24小时内处理完毕。
0
相关文章