建设 TiDB 自动化平台：转转 DBA 团队实践

转转技术 .
转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。 各种干货实践，欢迎交流分享，如有问题可随时联系 waterystone ~
莫善
转转 DBA。 负责 TiDB，MongoDB，MySQL 运维及转转数据库平台开发。

转转是 PingCAP 最早的一批用户之一，见证了 TiDB 的发展，自身也沉淀了不少经验。
从 1.0 GA 开始测试，到 2.0 GA 正式投产，然后升级到了 2.1，后来又升级到 4.0.13，最后建设自动化平台。其实转转 DBA 团队初建以来就开始投入一定的资源进行平台建设，一步一步实现自动化运维，希望一切需求都能实现工单化、一切操作都能实现平台化，进而降低人力成本。
本文将分享转转 DBA 团队实现 TiDB 自动化的历程。从遇到问题开始，到解决问题，以及平台做成什么样，也是对过去工作的总结和梳理。

1 运维痛点

• 转转现有集群 30 多套，早期都是 2.1.[5,7,8,17] 版本，近 500 个 TiKV 节点，总共差不多一百台机器供 TiKV 使用，集群新建、扩容、迁移都需要人工找机器。也因为缺少一个上帝的视角去管理集群，没法做到资源的合理分配，导致日常工作中有很大一部分时间都是在做迁移，都是重复工作，效率很低。
• 2.1 版本的运维工作都是基于 Ansible 进行。如扩容、下线、启停、修改配置等日常操作，有时候会碰到 Ansible 执行超时的情况。批量操作集群时，根本不知道到哪个节点了，这情况经常能遇到，在 reload 集群配置文件的时候遇到的概率就非常大，要多崩溃有多崩溃。
• 2.1 版本的 TiDB 自身有很多问题，执行计划失效、读写热点问题（不能快速定位问题）、TiDB 大查询 OOM、乐观事务、监控不完善、以及已知/未知的问题，就连集群状态都无法快速获取，当然备份也很痛苦，这对运维人员的工作加大了难度，也提升了人力成本。
  4.0 使用悲观事务需要满足一定的要求，具体请参考官方文档。
• 机器资源使用不平衡，存在部分机器内存剩余较多但是磁盘不足，还有部分机器内存不足，但是磁盘剩余很多。导致的结果是老板觉得机器投入已经很大，但是 DBA 实际使用中发现机器还是不够用。
• 告警噪音比较多，存在重复告警，互相冲刷问题，严重浪费告警资源，对排查问题也带来很不友好的体验。

2 解决痛点

2.1 元数据管理

将所有节点信息保存到表里，定期采集节点状态及资源使用情况。
过去都是依靠 Ansible 的配置文件进行管理，管理视角基本是停留在集群都有哪些节点，连一台机器都有哪些实例都不清楚，更别谈资源管理了。
现在将所有组件保存到一个表中，定期采集组件服务状态，内存磁盘占有量等信息。这样就有了一个全局的视角进行管理，也很方便的查阅集群状态。
后续基于这份元数据进行项目成本核算。
还有一个收益就是，组件信息的采集，可以很好的控制单个 TiKV 的容量，不会再出现单个集群容量一直增长，然后触发机器的磁盘告警 DBA 才感知到。有了这个采集的数据后，可以设置一个 TiKV 容量上限，比如 500GB，达到这个阈值就发送告警给 DBA 准备扩容。这样能很好的避免因机器磁盘告警而接收大量告警信息（单机多实例），也能提供一个很好的缓冲时间让 DBA 来处理。
总结起来就是，能很好的将机器/集群/组件管理起来，能合理有效的进行资源调度，也为实现自动化提供了基础数据。

2.2 机器资源管理

将所有机器信息保存到表里，定期采集硬件资源使用情况。这么做能获得如下两点收益：

• 第一是对已有环境进行 rebalance。有了元数据信息，就可以很好的展开 rebalance 工作了。最终收益很明显，既提高了资源利用率，还降低了 15% 的机器资源。
• 第二是能合理有效的进行资源调度，为实现自动化提供了基础数据。（同元数据管理）
  元数据管理和机器资源管理，这两部分工作既降低了成本也提升了工作效率同时也是监控的兜底策略，会基于这两个数据表进行监控：
  （1）进程是否正常。
  （2）机器是否正常。

2.3 全面升级

将所有 2.1 集群升到 4.0.13。
为了更好的管理集群，在升级前还做了一些规范化。第一是端口规划，因为 TiDB 组件太多，一个集群至少需要 6 种组件，