TiDB集群600个以上节点敏捷运维小妙招

**导读**

> 作者：杨漆

> 16年关系型数据库管理，从oracle 9i 、10g、11g、12c到Mysql5.5、5.6、5.7、8.0 到TiDB获得3个OCP、2个OCM；运维路上不平坦，跌过不少坑、熬过许多夜。把工作笔记整理出来分享给大伙儿，希望帮到大家少走弯路、少熬夜。

在维护TiDB时，专业DBA巡检会经常翻看每个集群的指标、看看各个集群的慢日志、给集群核心指标配置告警等操作。然而，一个TiDB集群有上百个指标监控，当维护少数几个TiDB集群时，可以逐个巡检。当维护几十个集群600个(甚至更多)以上节点时就不能靠人工蛮干了...

有时，当DBA被问到以下等问题：

老板问: 马上国庆节了，线上集群有没有风险？

业务leader问，某某集群，过节会有风险吗？

……

然后，DBA一个一个集群的去排查，累不说，可能效果也不怎么好。

每个数据库集群的核心指标、告警阀值、容忍度、一段时间内指标的历史平均值......这些内容关乎底层服务的稳定性，dba必须每天多次关注，随时做到全局掌控，心中有数，而不是等线上服务出了问题或者数据库告警了才去了解。

但这么多集群，这么多指标，如何快速的做到？下面做一些有益的思考:

集群指标虽然很多，可否挑选出少数几个指标来反映集群性能

TiDB集群那么多，到每个集群浏览指标比较耗时，可否把这些关键的指标定制到一个页面里便于快速熟悉？

基于上述需求，通常有以下几种做法：

搭建一套单独的grafana，数据源配置成各集群*TiDB prometheus地址，再定制各指标dashboard

*采用prometheus联邦机制

*单独采集，定制dashboard

以第一种方案举例，简单高效，下面介绍下如何定制TiDB性能大盘:

1、安装grafana

2、定制你所需要的数据源，比如线上TiDB集群地址，如下图所示

3、定制自己想要的监控指标和页面，对于一个TiDB集群，可挑选 node cpu、raftstore cpu、comprocessor cpu和duration4个指标，日常问题，这几个指标很快能反映出问题，大家可以挑选自己关注的指标。定制过程如下所示。

参考源集群，拷贝对应的指标公式到定制的大盘

最终把需要关注的业务TiDB集群指标定制在一个页面上，我配置的其中3个集群的指标，如下图所示

日常案例由于对集群指标进行了精简，DBA每天都会在业务早高峰、午高峰和晚高峰对大盘进行巡检，几秒内线上几十个集群的性能尽收眼底。同时由于每天例行做这个事情，每个集群的指标历史平均值，DBA都能熟记于心了。一个业务集群，请求量大+业务快速迭代，对于服务的稳定性，挑战还是非常大的，所以只要指标有个小波动，DBA都会及时处理掉。这样做带来几个好处：

性能问题扼杀在萌芽阶段。事前把这些事给做好，代价较小，事后做可能花的代价很大。

无形中，研发同学对数据库性能问题更重视了

DBA越来越轻松。

DBA通过巡检，发现和解决了很多萌芽的性能问题，所以数据库(除一次优化器bug，导致大表走错索引，短暂影响线上外)性能还是比较优秀的。

下面讲讲，通过这个简单高效的方法，业内某电商公司快速发现并处理的几个性能问题。

第一个例子：

某电商最核心的直播集群，巡检发现，某天延迟出现小幅抖动，如下图。

当时延告警阀值是125ms，此时这种波动，监控是无法告警出来的。这种小幅度的波动，基本不会影响线上其它请求。从其它2个指标可以看出来，如下图。

这种问题，短时间不处理，也不会出现什么大的问题。但如果发展到事后做，可能付出的代价会很大。

第二个例子：

某集群巡检发现，comprocessor cpu较历史值，有小幅增长(历史值维持在10%以下，机器是64核，理论承载能力可以达到5000%-6000%)，如下图所示。

通过慢日志系统发现，查询只走了部分索引，导致性能变差，通过修改索引，迅速解决。

在业务高速发展的背景下，数据库服务，要做到一个季度、半年、甚至一年不出故障，还是有挑战的。最好的方式，是在事前，把很多事情做好，做到数据库运维精细化，比如SQL审核，慢日志、规范等等。

以上小妙招方便实用，能提供如下便利:

1、DBA可以快速熟悉各业务集群的性能，预测风险

2、业务研发做什么操作时，比如跑批等，可以随时关注操作对线上性能有无影响

备注: 当然，如果你的老板不懂技术，人也比较傻，就喜欢看旋崖救美的英雄片才能感知DBA的价值，您就别用以上方法了，每周给他上演一次惊竦片（比如挂库)，然后你再临危出现，力挽狂澜…… 哈哈哈！

以上仅为玩笑，好好做个有职业道德的DBA，提前发现问题，提前预处置，排除隐患，运维好数据库，加持贵司业务蒸蒸日上 乃正道！

以上小方法分享给大家，希望对大家有帮助。