共计 6425 个字符，预计需要花费 17 分钟才能阅读完成。
转转技术
转转研发核心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。各种干货实际，欢送交换分享，如有问题可随时分割 waterystone ~
莫善
转转 DBA。负责 TiDB，MongoDB，MySQL 运维及转转数据库平台开发。
转转是 PingCAP 最早的一批用户之一，见证了 TiDB 的倒退，本身也积淀了不少教训。
从 1.0 GA 开始测试，到 2.0 GA 正式投产，而后降级到了 2.1，起初又降级到 4.0.13，最初建设自动化平台。其实转转 DBA 团队初建以来就开始投入肯定的资源进行平台建设，一步一步实现自动化运维，心愿所有需要都能实现工单化、所有操作都能实现平台化，进而升高人力老本。
本文将分享转转 DBA 团队实现 TiDB 自动化的历程。从遇到问题开始，到解决问题，以及平台做成什么样，也是对过来工作的总结和梳理。
运维痛点
- 转转现有集群 30 多套，晚期都是 2.1.[5,7,8,17] 版本，近 500 个 TiKV 节点，总共差不多一百台机器供 TiKV 应用，集群新建、扩容、迁徙都须要人工找机器。也因为短少一个上帝的视角去治理集群，没法做到资源的正当调配，导致日常工作中有很大一部分工夫都是在做迁徙，都是反复工作，效率很低。
- 2.1 版本的运维工作都是基于 Ansible 进行。如扩容、下线、启停、批改配置等日常操作，有时候会碰到 Ansible 执行超时的状况。批量操作集群时，基本不晓得到哪个节点了，这状况常常能遇到，在 reload 集群配置文件的时候遇到的概率就十分大，要多解体有多解体。
- 2.1 版本的 TiDB 本身有很多问题，执行打算生效、读写热点问题（不能疾速定位问题）、TiDB 大查问 OOM、乐观事务、监控不欠缺、以及已知 / 未知的问题，就连集群状态都无奈疾速获取，当然备份也很苦楚，这对运维人员的工作加大了难度，也晋升了人力老本。
- 4.0 应用乐观事务须要满足肯定的要求，具体请参考官网文档。
- 机器资源应用不均衡，存在局部机器内存残余较多然而磁盘有余，还有局部机器内存不足，然而磁盘残余很多。导致的后果是老板感觉机器投入曾经很大，然而 DBA 理论应用中发现机器还是不够用。
- 告警乐音比拟多，存在反复告警，相互冲刷问题，重大节约告警资源，对排查问题也带来很不敌对的体验。
解决痛点
元数据管理
将所有节点信息保留到表里，定期采集节点状态及资源应用状况。
过来都是依附 Ansible 的配置文件进行治理，治理视角根本是停留在集群都有哪些节点，连一台机器都有哪些实例都不分明，更别谈资源管理了。
当初将所有组件保留到一个表中，定期采集组件服务状态，内存磁盘占有量等信息。这样就有了一个全局的视角进行治理，也很不便的查阅集群状态。
后续基于这份元数据进行我的项目成本核算。
还有一个收益就是，组件信息的采集，能够很好的管制单个 TiKV 的容量，不会再呈现单个集群容量始终增长，而后触发机器的磁盘告警 DBA 才感知到。有了这个采集的数据后，能够设置一个 TiKV 容量下限，比方 500GB，达到这个阈值就发送告警给 DBA 筹备扩容。这样能很好的防止因机器磁盘告警而接管大量告警信息（单机多实例），也能提供一个很好的缓冲工夫让 DBA 来解决。
总结起来就是，能很好的将机器 / 集群 / 组件治理起来，能正当无效的进行资源调度，也为实现自动化提供了根底数据。
机器资源管理
将所有机器信息保留到表里，定期采集硬件资源应用状况。这么做能取得如下两点收益：
- 第一是对已有环境进行 rebalance。有了元数据信息，就能够很好的开展 rebalance 工作了。最终收益很显著，既进步了资源利用率，还升高了 15% 的机器资源。
- 第二是能正当无效的进行资源调度，为实现自动化提供了根底数据。（同元数据管理）
元数据管理和机器资源管理，这两局部工作既升高了老本也晋升了工作效率同时也是监控的兜底策略，会基于这两个数据表进行监控：
（1）过程是否失常。
（2）机器是否失常。
全面降级
将所有 2.1 集群升到 4.0.13。
为了更好的治理集群，在降级前还做了一些规范化。第一是端口布局，因为 TiDB 组件太多，一个集群至多须要 6 种组件，波及到十多个端口，所以做了端口布局，端口采纳 2+3 的格局，前两位示意组件名，后三位示意集群编号。即：前两位一样示意同一类组件，后三位一样示意同一个集群。这样就能够很好的实现规范化治理。
比方有一个 001 编号的集群，集群信息如下：
- 咱们每个集群的监控告警都是独立的组件，起因是在应用 Alertmanager 过程中发现有时候 A 集群的告警信息的 instance 的值是 B 集群的 instance，为了避免出现这种问题，咱们每个集群的监控告警组件都是独立的。
- 另外咱们会提供 5 个域名，别离对应到 TiDB 对外服务，Dashboard，Grafana，Prometheus，Alertmanager。仅须要提供集群编号，就能够疾速获取各组件的端口号及域名，看到部署目录就能够晓得是哪个集群的哪个组件。
- 须要留神的是，如果将 Dashboard 裸露给业务应用（业务很喜爱拜访慢查问平台），倡议是创立独立的账户，因该平台强制要求应用 root，所以能够针对 PD 组件的几个机器独自创立 root 账号，这个 root 的明码跟 DBA 应用的 root 进行区别。能够防止管理员账户泄露的问题，然而带来新的问题就是账户治理变得复杂了。
全副实现降级后。整体性能晋升 30%-50%，解决了抽数带来的影响，降级当前临时没有收到因抽数导致影响到业务的反馈，在降级前简直每两个月都会有至多一次因为抽数导致业务受影响。
告警革新
反对短信、语音告警，并实现告警收敛、克制，告警降级。大大降低告警条数（条数至多能升高 60%），节约告警资源。
收敛和克制目标是降噪。
告警降级次要是为了升高告警老本，降级分如下几个维度：
- 第一：介质降级。邮件 –> 企业微信 –> 短信 –> 电话（同一个告警项发送超过 3 次就向上降级一个介质，具体能够依据需要定义）。
- 第二：接管人降级。一级 –> 二级 –> leader。
- 第三：依照工夫降级。工作工夫通过邮件 / 企业微信发送告警，工作工夫之外通过短信 / 电话发送告警。
详情请看这篇文章：基于 Alertmanager 告警零碎的革新
实现自动化
分布式集群有很多长处，然而对 DBA 来说也减少了运维复杂度，有些集群几十上百个节点，全靠人工去治理运维无疑是很苦楚。
转转当初根本实现了自动化，收益也很显著，这部分次要是想分享一下注意事项或者遇到的问题，仅供参考。
需要工单化
这部分次要是在平台通过工单的形式实现了业务的日常的需要，升高了沟通老本，实现了业务需要审计，还能缩小 DBA 的工作量。
目前反对如下工单类型。
工单类型
集群部署工单
在 4.0 版本中，部署一个新集群比拟麻烦的是拓扑文件的生成，倒不是有多简单，而是因为一个集群的组件太多，每种组件对硬件的要求又有些区别。
比方 Grafana，Alertmanager 这种不须要 IO，PD，TiKV，TiFlash 对 IO 又要求比拟高，另外还须要依据服务的重要水平进行正当的布局，重要的服务独自部署或者尽可能的缩小节点数，须要思考的点参考维度有点多。
以上只是针对部署集群须要关注的点，还有一些额定的思考点，或者说操作细节。总结起来如下：
- 为各个角色抉择适合的机器，实现拓扑文件，而后部署集群。
- 初始化集群，创立业务用户，业务域名。
- 配置 Grafana，Prometheus，Alertmanager，Dashboard 等平台，创立必要的用户，以及 Grafana，Dashboard 权限管制，以及性能验证测试等。
- 集群信息入库，将必要的信息同步到业务侧。
所以实现工单化，不仅轻松解决资源调度问题，晋升机器资源利用率，还能够大大晋升效率，防止操作出错或者脱漏。尤其是性能验证，万一业务上线当前才发现问题，影响面就比拟大了。
新建集群
通过 sic 判断集群重要等级，预估 QPS，TPS 作为辅助参考项，最终依据评分为其调配正当的机器进行集群部署。
数据恢复工单
这类需要在工作中倒不是很多，然而一旦遇到就会比拟紧急。实现这类工单后，不仅能够升高沟通老本，升高故障的影响工夫，也能升高人力老本。
目前反对两个维度的数据恢复。
- 一种是基于快照，如果复原需要的工夫点在 GC 工夫之内的，就间接通过快照进行数据恢复，所以这类需要复原速度较快。
- 一种是基于备份文件，如果复原的工夫点位不在 GC 工夫之内的，就只能抉择最靠近该工夫点的备份文件来复原了。
目前这两类维度都反对整库（一个工单仅限单库），单表或者多表。基于快照的还反对带特定条件，基于备份文件的不反对带条件。所以相对来说基于快照的简单一些，特地是多表须要复原到某一个工夫点，且是带条件复原（单表局部数据）。
比方一个订单，波及多个表，须要将多个表某些订单号的数据恢复到特定工夫点。
由此可见，基于快照的复原是比拟灵便的，用户能够选单库，或者单表，还能够抉择多表，因为咱们并不知道用户须要复原几张表，所以带查问条件的逻辑应该是动静的，即当用户抉择了某个表，就会弹出改表的查问条件输入框，有几个表就有几个输入框，依据提醒输出到对应的表即可，如下图所示。
数据恢复
TiCDC 工单
转转公司有一种非凡业务需要，须要将业务的数据抽取到大数据平台，次要是给业务提供经营数据分析、用户行为和画像资产积淀以及一些趋势预测。
如果是 MySQL 间接做一个专门提供数据抽取的从库就行了，然而 TiDB 不行，尽管能够裸露一个 TiDB 节点给大数据进行数据抽取，然而实质上还是对同一组 TiKV 进行操作，所以抽数操作很容易引起业务的抖动。
当初咱们提供了两种计划给业务进行抉择，优先能够抉择 TiCDC，如果 TiCDC 不能满足的状况下能够应用 TiFlash。
TiCDC
对于曾经存在 cdc 工作，只需更新配置即可，另外须要留神上游如果是 kafka 的话，数据包的大小，要求跟 kafka 的最大值配置统一，否则可能会报错，尤其是 TiDB 端扩充表构造的场景。
对咱们来说，TiCDC 需要真的太须要实现工单化了。那些须要抽数的业务，简直新增一个表就须要更新 TiCDC 的工作，之前都是邮件沟通，现在实现工单后，对业务，对大数据团队，又或者是 DBA 都是非常不便的，升高了三方的沟通老本，晋升工作效率。
TiFlash 工单
需要同 TiCDC 工单。
TiFlash
从老本上思考，TiCDC 不须要额定的存储空间，所以更优，也更受欢迎。然而存在肯定的危险，比方 TiCDC 到上游的同步链路呈现问题（上游 TiDB 业务进行调整可能会导致同步中断），那么上游就会无奈获取增量数据。
TiFlash 则不会有这个问题，然而须要就义肯定的存储空间，业务老本会有所晋升，须要业务本人去衡量。
操作平台化
这部分次要是在平台通过页面操作实现了日常的治理，升高了运维老本，实现了操作审计，还能防止肯定的人为操作失误。
节点治理
这部分波及节点的启动、敞开、重启、下线、保护等。节点启停、重启流程比较简单，这里不做过多介绍。
节点治理
只有当节点处于敞开状态才会有启动选项。另外须要留神的是，重启操作曾经改成 reload，这样对业务的影响绝对小一些。前提是要评估好 restart 是否等价于 reload（没有变更配置根本不会有什么问题）。
下线和保护操作须要留神如下几个事项：
节点治理
- 下线的指标节点是否是该角色的最初一个节点，或者是否满足 raft 协定的最低要求，如果是则不能间接下线，须要人工染指。
- 保护操作次要是须要联动一下告警静默，因为保护操作自身是打算内操作，对于不必要的告警能够提前躲避掉。
对于 PD，TiKV 等组件对数量是有要求的，PD，TiKV 起码要求两个，所以当集群只剩两个节点的时候是不容许下线的，须要 DBA 染指操作，当然还有 DM-worker，TiFlash 等组件也是有最低数量要求，须要依据理论状况进行判断。
扩容治理
扩容分两种状况，一种是被动扩容，一种是主动扩容。这个小结是介绍被动扩容，至于主动扩容后文会介绍。
扩容性能比拟灵便，反对多角色同时扩容，节点个数可配置，指标地址也可配置，如下图所示：
扩容
未指定地址的话就由零碎默认调配正当的指标地址。
下线治理
下线要求是串行操作，即一个集群在同一个工夫只能有一个节点被下线，期待下线后能力下线第二个节点。另外，如果是存储节点（TiKV，TiFlash，Pump），须要期待数据迁徙结束后，执行完集群调整（prune）操作才算下线实现。
下线
须要考虑一下异样节点的下线，即机器宕机不可复原的状况，所以咱们减少了一个强制下线的选项来解决此类异样场景。
告警治理
告警跟运维工作非亲非故，一个好的告警治理平台不仅能晋升运维的效率，还能晋升工作舒适度及生存品质。
咱们的告警治理平台当初性能比较简单，后续会缓缓丰盛。
- 反对事后配置告警静默，比方将对某个集群进行保护，能够先将该集群的告警进行静默。
告警治理
静默工夫最长不容许超过 24 小时，默认是 2 小时，这样能够防止因忘记导致该告警项被长时间静默。
- 反对针对曾经告警的项进行静默。这部分逻辑是将所有告警项展现进去，供用户抉择。
- 如下是正在告警列表展现页
告警治理 - 告警列表
反对一键静默，即：正在告警的项全副静默。
如下是静默规定列表展现页，正在运行的静默规定反对删除及禁用，禁用状态的容许从新启用。
告警治理 - 静默规定列表
慢查问告警
这个性能是统计单位工夫内慢查问条目增长量，当达到告警阈值就会触发告警，用户能够设置统计的工夫范畴，以及慢查问阈值，还有告警阈值。
慢查问告警 - 增加规定
集群的慢查问阈值大于用户定义的规定的慢查问最小阈值，会将集群的慢查问阈值设置为该阈值。如集群慢查问阈值是 300ms，用户定义告警阈值是 200ms，这时候会将集群的慢查问阈值设置为 200ms。
如下是规定列表展现页，反对规定禁用及删除，禁用后能够从新启用。
慢查问告警 - 规定展现页
其余辅助性能
过程监控
过程监控
因 线上机器 根本都是单机多实例，有时 候会呈现因为某个实例而影响了整个机器的性能，在没有过程级别的监控下，对咱们排查定位问题非常苦楚，为解决这一个痛点，咱们开发了过程维度的监控零碎，这样能够很好的帮助运维人员排查定位机器资源跑满等问题。
过程级别的资源监控，包含然而不限于 CPU, 内存, 磁盘 IO, 网络流量，性能还在持续丰盛。具体实现能够参考这个文章：Linux 环境下针对过程维度的监控实现
过程 监控
会记录每个过程的资源应用状况，其中网络数据是做了限度，只有达到阈值才会采集，所以会呈现空白页状况。另外网络传输数据会记录源端到目标端信息。
趋势监控
随着工夫的推移，业务数据也在一直的增长。那么问题来了，这个增长是否合乎预期？依照这个增量，磁盘空间能反对多长时间？为了解决这两个问题，咱们采取了趋势剖析的计划，提前监控，剖析增长趋势，对于增长异样的集群会和业务进行沟通确认，对于磁盘空间邻近告警线会提前迁徙。
过程监控
- 增量告警，当数据目录在三日内间断单日增长超过 20GB，每个月增量超过 200GB 就会发送告警给业务，请业务进行确认。
- 全量告警，当数据目录达到告警阈值就给 DBA 发送告警。
主动运维
- 自适应迁徙
当机器筹备达到内存告警阈值，磁盘告警阈值，就主动迁徙。
- 自适应扩容
当单个 TiKV 容量达到 800GB 就主动进行扩容。
不论是自适应迁徙还是扩容，都能够缩小 DBA 的工作量，也能在肯定水平上缩小告警量。对于扩容，既管制了单个 TiKV 的大小，对于零碎性能也会有肯定的晋升。
单节点 TiKV 太大，不利于治理。在节点下线的场景下会拉长数据迁徙的工夫，在节点离线的场景下，会拉长生成新正本的工夫。
写在最初
本文介绍了 TiDB 在转转公司的倒退历程，从调研测试到投产应用，从命令行运维到自动化平台治理，将业务日常需要根本实现了工单化，DBA 日常治理保护的操作根本都实现了平台化。
所有自动化的前提是先实现规范化。
咱们一步一步走过去，遇到了很多问题，也解决了很多问题，但各自环境不同，需要也不同，还可能碰上其余未知的问题，本文所有内容仅供参考。