效率 10x！ 打造运维 TiDB 的瑞士军刀

极致的易用性一直是 PingCAP 追寻的目标。在这之前，TiDB 通过兼容 MySQL，将分布式的复杂度隐藏在 TiDB 之后，将用户从复杂的分库分表方案中解脱出来，使用户可以像使用单机数据库一样使用 TiDB。

不过兼容 MySQL 只是易用性的第一步，这一步主要提升了开发人员的体验。但是对于 DBA 来说，运维一个分布式系统的难度还是不低。那么分布式数据库的运维目前到底面临哪些难题？大致有以下几个方面：

• 各组件状态信息分散。

• 运维操作需要跨节点。

• 运维脚本重复编写，无法标准化。

图 1 查询集群系统信息

在上面的示例中，我们通过 SQL 获得集群以下信息：

• 所有节点的拓扑信息，版本信息。

• 所有节点的配置信息。

• 所有节点当前正在处理的请求，即 processlist。

• 所有节点的慢查询信息。

• 所有节点的服务器硬件信息。

• 所有节点当前的负载（Load）信息。

在此之前，TiDB 提供系统信息的系统表较少。本次 Hackathon 的项目也添加了更多的系统表用于通过 SQL 获取更多信息：

• 节点的硬件信息：CPU，memory，网卡，磁盘等硬件信息。

• 节点的负载信息：CPU / Memory load，网络 / 磁盘流量信息。

• 节点的配置信息。

• 节点的监控信息：如 QPS，KV Duration，TSO duration 等。

下面演示用 SQL 动态修改集群所有节点的配置:

图 2 动态修改集群配置

根据上面的动图可以看出，我们能通过 Update 语句修改 CLUSTER_CONFIG 系统表，即可完成集群配置的变更，而不需要再通过复杂的运维命令。当然，通过这个语句，也能指定只修改某个节点的某项配置。

当 TiDB 集群出现故障后，以前 DBA 可能会根据现象以及故障排除手册逐个排查。依靠我们添加完成上述的基础能力，这些完全是可以自动化的，比如一些 TiDB 中常见的故障排查场景：

• 找出系统写入变慢的原因，例如节点发生宕机等等。

• 找出集群中慢查询的全链路日志行为。

• 找出磁盘容量或者内存监控异常的节点。

在这个项目之前，查询 TiDB 的系统表时，用户一定会遇到的问题是：某些系统表只包含了当前 TiDB 节点的数据，而不是所有节点的数据。比如 PROCESSLIST（当前执行语句），SLOW_QUERY（慢查询内存表）等。

要实现读取所有节点的系统信息和修改所有节点的配置，首先要打通 TiDB 节点之间的数据交互。先看下目前 TiDB 集群的架构，如下：

图 3 原来 TiDB 集群系统架构

• TiDB 用 HTTP API 读其他 TiDB 节点的信息的可扩展性相对会差一些，RPC 框架的可塑性更高，可以承接未来 TiDB 节点间数据交互的需求。
• 计算下推到各个 TiDB 节点。某些信息的数据量可能很大，比如慢查询内存表，如果没有算子下推来完成数据的过滤，会存在很多多余的网络开销，这一点原理跟 TiDB 下推算子到 TiKV 是一样的。

图 4 现在 TiDB 集群系统架构

图 5 计算下推到其他 TiDB 节点执行

以上功能由于时间原因并未能完全在 Hackathon 期间完成，不过其目前已经作为一个 社区孵化项目。相信将会很快跟大家见面。

也欢迎感兴趣的社区小伙伴们加入我们社区的工作组：SQL 诊断工作组，一起进一步完善并落地这个项目，提高 TiDB 的易用性。

令人振奋的是，这一切只是一个开始。