1前言转转是PingCAP最早的用户之一。见证了TiDB的发展，积累了很多经验。测试从1.0GA开始，到2.0GA正式投产，然后升级到2.1，再升级到4.0.13，最后搭建自动化平台。事实上，转转DBA团队从成立之初就在平台建设上投入了一定的资源，逐步实现了自动化运维。希望所有的需求都可以实现为工单，所有的操作都可以实现为一个平台，从而降低人力成本。这篇文章想分享一下TiDB自动化的历史。从遇到问题到解决问题，平台是用什么做的，也是对以往工作的总结和梳理。2运维痛点(1)翻了30多个现有集群，前期都是2.1.[5,7,8,17]版本，TiKV节点近500个，总共近100台机器TiKV使用。集群新建、扩容、迁移都需要手动找机器。也因为缺乏上帝视角来管理集群，无法实现资源的合理分配，导致日常工作中有很大一部分花费在迁移上，属于重复性工作，效率低下。(2)2.1版本运维基于Ansible。对于日常的扩容、下线、启停、修改配置等操作，有时会出现Ansible执行超时的情况。批量操作集群时，不知道自己在哪个节点。这种情况经常会遇到。在重新加载集群配置文件的时候，遇到的概率很高，尽可能多的会崩溃。(3)TiDB2.1版本本身存在很多问题，比如执行计划失败、读写热点问题（无法快速定位问题）、TiDB大查询OOM、乐观事务、监控不完善、已知/未知问题，甚至集群的状态无法快速获取，当然备份也很痛苦，增加了运维人员的工作难度，增加了人力成本。4.0悲观交易的使用需要满足一定的要求，具体请参考官方文档。(4)机器资源利用不平衡。有的机器内存多，磁盘不够，有的机器内存不够，磁盘多。结果就是老板觉得机器的投资已经很大了，但是DBA在实际使用中发现机器还是不够用。（5）告警噪音大，重复告警，互冲问题，严重浪费告警资源，排错体验很不友好。3解决痛点3.1元数据管理将所有节点信息保存在表中，定时收集节点状态和资源使用情况。以前我们都是靠Ansible的配置文件来管理的。管理的视角基本停留在集群中的节点上，连一台机器有哪些实例都不清楚，更不用说资源管理了。现在把所有的组件保存在一张表中，定时收集组件服务状态、内存盘占用等信息，这样管理就有了全局的视角，查看集群的状态也很方便.后续项目成本核算基于此元数据。另一个好处是组件信息的收集可以很好的控制单个TiKV的容量，不会导致单个集群的容量不断增加，然后在DBA感知之前触发机器的磁盘告警。通过采集到的数据，可以设置一个TiKV的容量上限，比如500GB，当达到这个阈值时，会向DBA发出告警，为扩容做准备。这样可以很好的避免因为机器磁盘告警（单机多实例）而接收到大量的告警信息，也可以为DBA处理提供一个很好的缓冲时间。综上所述，它可以很好地管理机器/集群/组件，合理有效地调度资源，为自动化提供基础数据。3.2机器资源管理表中保存所有机器信息，定期收集硬件资源使用情况。这样做可以获得以下两个好处：首先是重新平衡现有环境。有了元数据信息，rebalance的工作就可以很好的进行了。最终的好处是显而易见的，不仅提高了资源利用率，还减少了15%的机器资源。二是合理有效地调度资源，为自动化提供基础数据。（同元数据管理）元数据管理和机器资源管理，这两部分工作既降低了成本又提高了工作效率，也是一种自下而上的监控策略，将基于这两个数据表进行监控：(1)流程是否正常。(2)机器是否正常。3.3全面升级将所有2.1集群升级到4.0.13。为了更好地管理集群，在升级前做了一些规范化。首先是港口规划。由于TiDB组件太多，一个集群至少需要6个组件，涉及十多个端口，所以做了端口规划。端口采用2+3的格式。前两位表示组件名称，后三位表示簇号。即：前两位代表同一类组件，后三位代表同一簇。这样才能很好的实现标准化管理。例如有一个编号为001的集群，集群信息如下：角色数量端口部署目录域名备注pd313001/14001/path/pd-13001tdb.13001.comDashboard域名tidb315001/16001/path/tidb-15001TDB.15001.com外部服务域名TIKV317001/18001/PATH/TIKV-17001ALERTMANAGER121001/pATH/atermanager-21001tdb.21001.comalertManager20001.comgrafana的域名exportern11001/12001/path/monitor-11001会部署到每台机器上。我们每个集群的监控告警都是独立的组件。原因是在使用Alertmanager的过程中，有时集群A的告警信息的实例值的值是集群B的实例值，为了避免此类问题，每个集群的监控和告警组件都是独立的.另外我们会提供5个域名，分别对应TiDB对外服务，Dashboard、Grafana、Prometheus、Alertmanager。只需要提供集群号即可快速获取各个组件的端口号和域名，查看部署目录即可知道是哪个集群的哪个组件。需要注意的是，如果Dashboard暴露给业务使用（业务喜欢接入慢查询平台），建议创建独立账号。因为平台需要使用root，所以可以为PD组件的几台机器分别创建root账号，root密码与DBA使用的root不同。管理员账号泄露的问题可以避免，但新的问题是账号管理变得复杂。全部升级完成后。整体性能提升30%-50%，解决了抽奖带来的影响。升级后，未收到因开奖影响业务的反馈。升级前，至少会有一次因彩票业务受到影响。3.4告警改造支持短信和语音告警，实现告警汇聚、抑制、告警升级。大大减少告警数量（数量至少可减少60%），节省告警资源。收敛和抑制的目的是降噪。告警升级的主要目的是降低告警成本。升级分为以下几个维度：第一：媒体升级。邮箱-->企业微信-->短信-->电话（同一个告警发送次数超过3次，升级为媒介，可根据需求定义）。第二：收件人升级。1级-->2级-->领导者。第三：按时升级。上班时间邮件/微信提醒，下班时间短信/电话提醒。详情请看这篇文章https://mp.weixin.qq.com/s?__biz=MzIwMjk1ODMzMw==&mid=2247487848&idx=1&sn=0a6f76ca4f8f44c8fcd9b34be3c0f07b&chksm=96d7e5faa1a06cecf916141897b3faad11f93f3899c6d21ef24e09414a23cb035ae7670334f2#rd4实现自动化分布式集群有很多优点，但是对DBA来说Italsoincreasesthecomplexityofoperationandmaintenance.有些集群有几十上百个节点，人工管理运维无疑是非常痛苦的。现在转转已经基本完成了自动化，收益是显而易见的。这部分主要是分享注意事项或者遇到的问题，仅供参考。4.1需求工单这部分主要是通过平台上的工单实现业务的日常需求，降低沟通成本，实现业务需求审计，减轻DBA的工作量。当前支持以下工单类型。工单类型（一）集群部署工单在4.0版本中，部署新集群比较麻烦的是拓扑文件的生成。要求有些不同。例如，Grafana和Alertmanager不需要IO。PD、TiKV、TiFlash对IO的要求比较高。此外，还需要根据服务的重要性进行合理规划。重要的服务需要单独部署或者尽量减少节点数量。点参考维度有点多。以上只是部署集群时需要注意的点，还有一些额外的注意事项，或者操作细节。总结一下：为每个角色选择合适的机器，完成拓扑文件，部署集群。初始化集群，创建业务用户和业务域名。配置Grafana、Prometheus、Alertmanager、Dashboard等平台，创建必要的用户，以及Grafana、Dashboard权限控制、功能验证测试等。集群信息存储在数据库中，必要的信息同步到业务端。因此工单的实现，不仅可以轻松解决资源调度问题，提高机器资源利用率，还可以大大提高效率，避免操作失误或遗漏。尤其是功能验证，如果业务上线后才发现问题，影响会比较大。新集群通过sic判断集群的重要程度，估算QPS、TPS作为辅助参考项，最终根据评分合理分配机器进行集群部署。(2)工作中对数据恢复工单的要求不多，但一旦遇到，就会比较紧急。实现这种工单后，不仅可以降低沟通成本，减少故障的影响时间，还可以降低人工成本。目前支持二维数据恢复。一种是基于快照。如果恢复需求的时间点在GC时间内，会直接通过快照进行数据恢复，所以这类需求的恢复速度更快。一种是基于备份文件。如果恢复的时间点不在GC时间内，只能选择距离时间点最近的备份文件进行恢复。目前这两种维度支持全库（一个工单仅限单库）、单表或多表。基于快照的也支持特定条件，但是基于备份文件的不支持条件。所以相对来说，基于快照，要复杂一些，尤其是需要将多张表恢复到某个时间点，而且恢复是有条件的（单表的部分数据）。比如一个订单涉及多个表，需要将多个表中某个订单号的数据恢复到特定的时间点。可见基于快照的恢复更加灵活。用户可以选择单个数据库、单个表或多个表。由于我们不知道用户需要恢复多少张表，所以查询条件的逻辑应该是动态的，即当用户选中某个表时，会弹出换表的查询条件输入框。几个表有几个输入框。根据提示输入对应的表格即可，如下图所示。数据恢复（3）TiCDC工单中转公司有特殊的业务需求，需要将业务数据提取到大数据平台，主要提供业务数据分析，用户行为和画像资产积累，以及一些趋势预测。如果是MySQL，直接创建一个提供数据抽取的slave库就可以了，TiDB不行。虽然一个TiDB节点可以暴露给大数据进行数据抽取，但本质上还是在同一组TiKV上运行，所以数据抽取的操作非常容易。造成业务抖动。现在我们提供两种方案供商家选择。可以先选择TiCDC，如果TiCDC不能满足要求可以使用TiFlash。ticdc对于已有的cdc任务，只需要更新配置即可。另外，如果下游是Kafka，数据包的大小必须和Kafka的最大配置保持一致。否则可能会报错，尤其是TiDB端扩表时。场景。对我们来说，TiCDC需求确实需要实现工单。对于那些需要抽取数据的业务，几乎需要在加表时更新TiCDC的任务。过去，都是电子邮件通信。现在实现工单后，对于业务、大数据团队或者DBA来说，都非常方便。降低三方沟通成本，提高工作效率。(4)TiFlash工单要求与TiCDC工单相同。考虑到TiFlash的成本，TiCDC不需要额外的存储空间，所以更好，更受欢迎。但是，存在一定的风险。例如，如果TiCDC到下游的同步链路出现问题（上游TiDB业务调整可能导致同步中断），那么下游将无法获取增量数据。TiFlash不存在这个问题，但是需要牺牲一定的存储空间，业务成本会增加，需要业务自己权衡。4.2运营平台化这部分主要通过平台的页面操作实现日常管理，降低运维成本，实现运营审计，避免一定的人为操作失误。(1)节点管理这部分涉及节点的启动、关闭、重启、下线、维护等，节点的启动、停止和重启过程比较简单，这里不再过多介绍。节点管理只有在节点处于关闭状态时才会有启动选项。另外需要注意的是，重启操作改成了reload，所以对业务的影响比较小。前提是评估restart是否等同于reload（不改配置基本没问题）。下线和维护操作需要注意以下事项：节点管理下线的目标节点是否是角色的最后一个节点，或者是否满足raft协议的最低要求，如果是则不能下线直接，需要人工干预。维护操作主要需要和报警消音联动，因为维护操作本身就是一个计划性的操作，可以提前避免不必要的告警。对PD、TiKV等组件数量有要求。PD和TiKV至少需要两个，所以当集群只剩下两个节点时，是不允许下线的。需要DBA介入，当然DM-worker、TiFlash等组件也有最低数量要求，需要根据实际情况判断。(2)扩容管理扩容有两种情况，一种是主动扩容，一种是自动扩容。这个总结就是介绍主动扩容，至于自动扩容，后面会介绍。扩容功能更加灵活，支持多角色同时扩容。可以配置节点数量，也可以配置目标地址，如下图所示：如果扩容时没有指定地址，系统会默认分配一个合理的目标地址。(3)离线管理离线要求是串行操作，即集群中一次只能有一个节点离线，第二个节点等待离线后才能离线。另外，如果是存储节点（TiKV、TiFlash、Pump），需要等待数据迁移完成，再进行集群调整（prune）操作，才算离线。下线需要考虑异常节点下线，也就是机器宕机无法恢复的情况，所以我们增加了一个强制下线的选项来应对这种异常场景。(4)告警管理告警与运维工作密切相关。一个好的告警管理平台不仅可以提高运维效率，还可以提高工作舒适度和生活质量。我们告警管理平台的功能现在比较简单，以后会逐渐丰富。支持预先配置的警报静音。例如，如果要维护一个集群，可以先关闭该集群的告警。报警管理的最大静音时间不允许超过24小时，默认为2小时，避免报警项因遗忘而长时间静音。支持对已提醒的项目进行静音。这部分逻辑是将所有报警项展示出来，供用户选择。以下是报警列表展示页面的报警管理——报警列表支持一键静音，即：所有正在报警的项目都静音。下面是静默规则列表的展示页面。正在运行的静默规则可以删除和禁用，禁用状态允许重新启用。告警管理-静默规则列表(5)慢查询告警该功能统计单位时间内慢查询条目的增长情况。当达到警报阈值时，将触发警报。用户可以设置统计时间范围、慢查询阈值、告警阈值。慢查询告警——添加集群慢查询阈值大于用户自定义规则的最小慢查询阈值的规则，会将集群的慢查询阈值设置为该阈值。例如集群慢查询阈值为300ms，用户自定义告警阈值为200ms，则集群慢查询阈值设置为200ms。下面是规则列表展示页面，支持禁用和删除规则，禁用后可以重新启用。慢查询告警-规则显示页面4.3其他辅助功能(1)进程监控进程监控由于线上的机器基本都是单机多实例，有时可能会因为某个实例影响整机的性能。在监控下，我们排查问题、定位问题是一件非常痛苦的事情。为了解决这个痛点，我们开发了流程维度的监控系统，可以很好的辅助运维人员排查定位定位机资源满等问题。进程层面的资源监控，包括但不限于CPU、内存、磁盘IO、网络流量等，不断丰富。具体实现可以参考这个文章https://mp.weixin.qq.com/s?__biz=MzIwMjk1ODMzMw==&mid=2247487654&idx=1&sn=0722b7e216cb2f887eea2d8f874faa88&chksm=96d7e434a1a06d22b2a52a87b4bcc8a2fbc52218802ceefa6f243a0bb71a0ea02fd521c67395#rd进程监控会记录每个进程的资源使用情况，其中网络数据有限，达到阈值才会采集，所以会出现空白页。此外，网络传输数据会记录源到目的信息。(2)趋势监控随着时间的推移，业务数据也在不断增长。那么问题来了，这种增长符合预期吗？以这个增量，磁盘空间可以持续多久？为了解决这两个问题，我们采用趋势分析方案，提前监控，分析增长趋势，对于异常增长的集群与业务沟通，在磁盘空间接近警戒线时提前迁移。过程监控增量报警。当数据目录连续三天单日增长超过20GB，每月增长超过200GB时，将向业务发出告警。请确认业务。满报警，当数据目录达到报警阈值时，会向DBA发送报警。(3)自动运维自适应迁移当机器准备好达到内存告警阈值和磁盘告警阈值时，会自动迁移。自适应扩容当单个TiKV容量达到800GB时，会自动扩容。无论是自适应迁移还是扩容，都能在一定程度上减轻DBA的工作量，减少告警次数。对于扩容，不仅控制了单个TiKV的大小，还在一定程度上提升了系统性能。单节点TiKV太大，不利于管理。在节点离线的场景下，数据迁移的时间会延长，在节点离线的场景下，生成新副本的时间也会延长。5写在最后本文介绍了转转公司TiDB的发展历程，从研究测试到生产使用，从命令行运维到自动化平台管理，基本实现了日常业务需求的工单，DBA日常管理和维护操作基本上是平台化的。一切自动化的前提是首先要实现标准化。我们一步步走过来，遇到过很多问题，也解决过很多问题，但是每个环境不一样，需求也不一样，可能还有其他不为人知的问题，本文所有内容仅供参考。关于作者莫山，转DBA。负责TiDB、MongoDB、MySQL运维和转转数据库平台开发。
