开发者学堂课程【第八届大学生创新创业大赛阿里命题数据库命题解析：PolarDB-X 问题诊断与定位系统搭建赛题解析】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1045/detail/15208
PolarDB-X 问题诊断与定位系统搭建赛题解析
内容介绍：
一、PolarDB-X 介绍
二、性能监控
三、日志监控
四、性能剖析
通过这节课可以对 PolarDB-X 诊断与定位体系有更深入的了解，知道如何诊断PolarDB-X 相关的问题，如果是一位开发者，想对监控与诊断系统进行扩展也能受到很好的启发。
一、PolarDB-X 介绍
1、PolarDB-X是云原生的分布式关系型数据库已经于2021年进行正式开源，在公有云上也得到一众客户的好评，它的技术特征有三点，作为分布数据库，可能会有单机数据库一些区别，但是尽可能做到让分布式数据库能有跟单机mysql一样类似的使用体验。一个是透明分布式就是用户可以像mysql一样，用PolarDB-X数据库，降低用户的上手成本，还有全局一致的分布式事务，是比较大的挑战，用户使用单机mysql一样使用分布式数据库，因为下面会用好几个dn，每个dn都有blog，需要有全局一致的逻辑日志流服务给用户输出一份blog，用户就可以用mysql生态里面的工具，比如Ktellmaxwell消费blog，同时是HTaP的数据库具有基于分布式并行执行框架，也就是MPP进行混合复杂的处理能力，优化器会根据语句的复杂程度判断它是tp的sql还是ap的sql，选择不同的执行方式加速它的执行。
2、PolarDB-X整体架构由四个组件组成。一个是GMS元数据存储整个系统里的元数据，比如库名表名列信息还有系统参数。计算节点主要负责接收用户sql，对sql进行解析，优化生成计划，执行计划，操作存储节点，对存储节点的数据进行汇总，返回到用户客户端，存储节点主要是负责数据的持久化，还有单机事物的处理，比如差异事务里面的分支事务的处理，在mysql基础上进行修改，CDC节点通常被称为日志节点，主要处理来自各个存储节点上blog的规定排序，给用户生成单份的逻辑blog，就像单机mysql生成blog一样。
3、如何从哪方面对它进行监控，首先需要解对什么进行监控，在系统里面有哪些监控对象，部署视图，可以看到典型的部署形态，数组介绍，进行好几个容器，一个容器里面可以跑计算节点，cdc节点还元数据节点，存储节点，元数据节点和存储节点就是mysql进程，可以用相同的监控方式监控它，计算节点和cdc节点是java程序，对java程序的监控手段同样可以用到计算节点和cdc节点比如jvm的监控，指标型监控，监控对象是宿主机，容器，jvm，进程本身，引擎，引擎就是计算引擎，cdc引擎，还有mysql引擎。
二、性能监控
1、性能监控有指标，确定监控对象，让每个监控对象有所关心的监控指标，监控指标大类分成五类，引擎，容器，主机，jvm，每个引擎是有不同实现方式，都有想要输出的监控指标，比如mysql引擎，它可以分为两类，sql引擎和存储引擎，两层都有不同的监控指标，可以通过指令获得指标，周期性的访问得到指标。计算引擎，比如qps，tps，rt指标都可以通过访问计算引擎通过端口发送指令拿到，cdc引擎也提供了类似的接口。容器监控可以监控内存，cpu，硬盘io，网络io，存储空间。指标同样可以监控主机上的指标，进程相关的，内存使用率，cpu使用率，cdc和计算节点用的是java写的，还添加了一个jvm监控，java进程启动时，它亲自把堆的内存都给预先分配好，这时单纯接进程的内存使用率，可能一直都是一个值，看不出什么，所以需要增加堆使用率的监控，监控率100%。Gc情况，gc次数，gc时间，qbs突然抖一下，可能会看gc情况，当时有没有发生大的gc，造成一些抖动，监控数据有了之后，还有一个展示，PolarDB-X是分布式系统，分布式系统会跨一个整体的情况，通过节点之间的比较，查看节点有没有异常，多节点视角，异常节点会看其它的指标，更详细的节点指标就是单节点视角。
2、每个指标都提供了获取指标的访问方式，比如计算节点，在管理端口端可以通过输入show@@stasts，show@@stc，qps，或者rt，mysql的数量的一些指标，访问端口时可以用show trans看当前的事务，会话情况，物理会话情况，存储节点就是mysql，通过global status连接监控指标，processlist获取会话信息，cdc节点获得blog消费延迟和吞吐量。
3、公有云上监控里面的qps指标，汇总视角是看多个节点，
两个节点把qps加起之后的指标，多节点看各个节点qps的情况，单个节点，图里面可以显示多个指标，多个指标并行比较，可以看到qps和物理qps差不多，可以基本判断检查。
三、日志监控
1、性能指标就是单纯的数字，数字看起来效果很好，也可以很直观的判断出系统是否处于一个正在运行的状态，找根本原因的时候光靠性能指标不够，需要看系统的日志，sql日志，错误日志，或者其他日志，cpu升高是什么原因造成的，需要看日志，所以会有日志结构。
日志监控和性能监控的监控对象是一样的，计算节点，需要sql，除了判断数据库异常之外，一条sql占用资源太多了，cpu突然升高，是哪条sql造成的，sql位置起到审计的作用，一个用户没有delate数据，为什么数据没有了，可以看sql日志，有可能是根本没有delate，用户记错，数据本来就没用，起到审计作用，很多异常都是慢日志造成的，慢日志量也会稍微少一点，可以快速诊断数据库性能问题，事务的开始，启动情况，启动时间，这段时间有没有重启过，错误日志比较重要，数据库发生异常的时候可以看异常情况哪里出现问题，gc日志，存储节点就是mysql，mysql也需要看三个日志，sql日志，慢日志，错误日志，需要注意计算节点和存储节点sql日志可以联动，都有id把它们关联起来，一个计算节点的sql日志可能会执行的时候变成多条存储节点上的sql日志，它们都会用相同的id 关联起来，形成方便于全链路的诊断，cdc是java程序，有gc日志和错误日志，主要看系统日志，计算节点没有任何日志，被操作系统给cue掉，可以翻系统日志。
2、准备工作是在k8s集群上部署好PolarDB-X实例，从节点打开general log，general log会记录每条存储节点会收到sql日志，比如发事务，可以看到ts id，begin有ts id，update也有ts id，前缀一样，后面的杠多少就表示是第几条sql，update表示事务里面第一条sql，ts id可以到存储节点上group，可以查到sql产生哪些物理sql，突然发现存储节点比较异常，猜测是慢sql导致，通过存储节点慢sql上的ts id反查用户的sql，可以查出用户是哪条sql导致的。
四、性能剖析
1、突然发现节点cpu突然升高，监控日志都没有发现升高的原因是什么，需要进行性能剖析，执行什么方法，在干什么事情，用到方法级别或者函数级别。
2、压测准备，一个PolarDB-X实例，JMeter压测程序，在PolarDB-X实例建库和建表，拆分表。
建表语句
CREATE TABLE 'busutb' (
'id' int(11) NOT NULL AUTO INCREMENT,
myname' varchar(20) NOT NULL,
PRIMARY KEY ('id') ,
) dbpartition by hash('id') tbpartition by hash('id')
插入数据
insert into busutb(myname)
values('busu1'),('busu2'),('busu3'),('busu4'),('busu5');
JMeter不停的插入数据，sql语句是全表遍历，会访问存储节点上每一个分库，不是点插。
3、火焰图生成演示分为两部分，生成节点，存储节点的演示。首先给PolarDB-X施加流量，JMeter压测，使用sql，k8s集群。
用async-profiler工具生成火焰图，用压测流量是因为cpu升高之后，火焰图效果会比较好，便于演示，记录命令，把30s缩短为10s，在目录下生成图，拷贝到本地可以用浏览器看，生成dn节点，dn节点有一些配置在容器内不可操作，登陆到宿主机上操作，在宿主机上和容器内pid是不一样的，查容器内的pid。看容器到宿主机上的映射，宿主机上4个pid。
是同一个进程，再通过profiler工具生成性能采样的数据，用10s，换pid。
重复，两个火焰图都在目录下面，可以通过浏览器查看。Cn计算节点，主要是在处理查询，通过判断可以查看在干什么，cpu突然升高的原因，性能调用时火焰图很有用。
Dn处理正常的函数，遇到问题时会起到很关键的作用。
Cpu一直高，可以用以上的方式进行诊断，如果半夜cpu突然升高，dba起来的时候已经好了，这时需要在程序运行期间进行持续的数据采集，才能看过去时间段进行性能剖析，性能，持续采集一直在跑，需要关注自身的性能，自身的性能不能很差，肯定有问题，实例对采集对象产生性能损耗，实例变的很慢，得不偿失，没有任何影响也是不可能的，把影响控制在百分之一或者百分之零点五的损耗，进行压测，判断究竟损耗多少，资源，磁盘，cpu，内存使用量最好控制在一定的范围内，交互，希望生成火焰图比较好的查验方式，不同监控维度上联动，跟性能监控进行联动，突然发现cpu升高，划一下点性能剖析，日志监控，性能监控进行联动，交互方式最好能提供文本页面，只判断cpu升高，内存升高也可以用类似的工具进行剖析。
