TiDB在转转公司的发展历程

转转是PingCAP最早的一批用户之一，见证了TiDB的发展，自身也沉淀了不少经验。,从1.0 GA开始测试，到2.0 GA正式投产，然后升级到了2.1，后来又升级到4.0.13，最后建设自动化平台。,其实转转DBA团队初建以来就开始投入一定的资源进行平台建设，一步一步实现自动化运维，希望一切需求都能实现工单化、一切操作都能实现平台化，进而降低人力成本。,本文就想来分享一下TiDB实现自动化的历程。从遇到问题开始，到解决问题，以及平台做成什么样，也是对过去的工作做一个总结和梳理。,（1）转转现有集群30多套，早期都是2.1.[5,7,8,17]版本，近500个TiKV节点，总共差不多一百台机器供TiKV使用，集群新建、扩容、迁移都需要人工找机器。也因为缺少一个上帝的视角去管理集群，没法做到资源的合理分配，导致日常工作中有很大一部分时间都是在做迁移，都是重复工作，效率很低。,（2）2.1版本的运维工作都是基于Ansible进行。如扩容、下线、启停、修改配置等日常操作，有时候会碰到Ansible执行超时的情况。批量操作集群时，根本不知道到哪个节点了，这情况经常能遇到，在reload集群配置文件的时候遇到的概率就非常大，要多崩溃有多崩溃。,（3）2.1版本的TiDB自身有很多问题，执行计划失效、读写热点问题（不能快速定位问题）、TiDB大查询OOM、乐观事务、监控不完善、以及已知/未知的问题，就连集群状态都无法快速获取，当然备份也很痛苦，这对运维人员的工作加大了难度，也提升了人力成本。,（4）机器资源使用不平衡，存在部分机器内存剩余较多但是磁盘不足，还有部分机器内存不足，但是磁盘剩余很多。导致的结果是老板觉得机器投入已经很大，但是DBA实际使用中发现机器还是不够用。,（5）告警噪音比较多，存在重复告警，互相冲刷问题，严重浪费告警资源，对排查问题也带来很不友好的体验。,将所有节点信息保存到表里，定期采集节点状态及资源使用情况。,过去都是依靠Ansible的配置文件进行管理，管理视角基本是停留在集群都有哪些节点，连一台机器都有哪些实例都不清楚，更别谈资源管理了。,现在将所有组件保存到一个表中，定期采集组件服务状态，内存磁盘占有量等信息。这样就有了一个全局的视角进行管理，也很方便的查阅集群状态。,后续基于这份元数据进行项目成本核算。,还有一个收益就是，组件信息的采集，可以很好的控制单个TiKV的容量，不会再出现单个集群容量一直增长，然后触发机器的磁盘告警DBA才感知到。有了这个采集的数据后，可以设置一个TiKV容量上限，比如500GB，达到这个阈值就发送告警给DBA准备扩容。这样能很好的避免因机器磁盘告警而接收大量告警信息（单机多实例），也能提供一个很好的缓冲时间让DBA来处理。,总结起来就是，能很好的将机器/集群/组件管理起来，能合理有效的进行资源调度，也为实现自动化提供了基础数据。,将所有机器信息保存到表里，定期采集硬件资源使用情况。这么做能获得如下两点收益：,将所有2.1集群升到4.0.13。,为了更好的管理集群，在升级前还做了一些规范化。第一是端口规划，因为TiDB组件太多，一个集群至少需要6种组件，涉及到十多个端口，所以做了端口规划，端口采用2+3的格式，前两位表示组件名，后三位表示集群编号。即：前两位一样表示同一类组件，后三位一样表示同一个集群。这样就可以很好的实现规范化管理。,比如有一个001编号的集群，集群信息如下：,全部完成升级后。整体性能提升30%-50%，解决了抽数带来的影响，升级以后暂时没有收到因抽数导致影响到业务的反馈，在升级前几乎每两个月都会有至少一次因为抽数导致业务受影响。,支持短信、语音告警，并实现告警收敛、抑制，告警升级。大大降低告警条数（条数至少能降低60%），节约告警资源。,收敛和抑制目的是降噪。,告警升级主要是为了降低告警成本，升级分如下几个维度：,详情请看这篇文章 https://mp.weixin.qq.com/s?__biz=MzIwMjk1ODMzMw==&mid=2247487848&idx=1&sn=0a6f76ca4f8f44c8fcd9b34be3c0f07b&chksm=96d7e5faa1a06cecf916141897b3faad11f93f3899c6d21ef24e09414a23cb035ae7670334f2#rd,分布式集群有很多优点，但是对DBA来说也增加了运维复杂度，有些集群几十上百个节点，全靠人工去管理运维无疑是很痛苦。,转转现在基本完成了自动化，收益也很明显，这部分主要是想分享一下注意事项或者遇到的问题，仅供参考。,这部分主要是在平台通过工单的方式实现了业务的日常的需求，降低了沟通成本，实现了业务需求审计，还能减少DBA的工作量。,目前支持如下工单类型。,,工单类型,（1）集群部署工单,在4.0版本中，部署一个新集群比较麻烦的是拓扑文件的生成，倒不是有多复杂，而是因为一个集群的组件太多，每种组件对硬件的要求又有些区别。,比如Grafana，Alertmanager这种不需要IO，PD，TiKV，TiFlash对IO又要求比较高，另外还需要根据服务的重要程度进行合理的规划，重要的服务单独部署或者尽可能的减少节点数，需要考虑的点参考维度有点多。,以上只是针对部署集群需要关注的点，还有一些额外的考虑点，或者说操作细节。总结起来如下：,所以实现工单化，不仅轻松解决资源调度问题，提升机器资源利用率，还可以大大提升效率，避免操作出错或者遗漏。尤其是功能验证，万一业务上线以后才发现问题，影响面就比较大了。,,新建集群,通过sic判断集群重要等级，预估QPS，TPS作为辅助参考项，最终根据评分为其分配合理的机器进行集群部署。,（2）数据恢复工单,这类需求在工作中倒不是很多，但是一旦遇到就会比较紧急。实现这类工单后，不仅可以降低沟通成本，降低故障的影响时间，也能降低人力成本。,目前支持两个维度的数据恢复。,目前这两类维度都支持整库（一个工单仅限单库），单表或者多表。基于快照的还支持带特定条件，基于备份文件的不支持带条件。所以相对来说基于快照的复杂一些，特别是多表需要恢复到某一个时间点，且是带条件恢复（单表部分数据）。,比如一个订单，涉及多个表，需要将多个表某些订单号的数据恢复到特定时间点。,由此可见，基于快照的恢复是比较灵活的，用户可以选单库，或者单表，还可以选择多表，由于我们并不知道用户需要恢复几张表，所以带查询条件的逻辑应该是动态的，即当用户选择了某个表，就会弹出改表的查询条件输入框，有几个表就有几个输入框，根据提示输入到对应的表即可，如下图所示。,,数据恢复,（3）TiCDC工单,转转公司有一种特殊业务需求，需要将业务的数据抽取到大数据平台，主要是给业务提供经营数据分析、用户行为和画像资产沉淀以及一些趋势预测。,如果是MySQL直接做一个专门提供数据抽取的从库就行了，但是TiDB不行，虽然可以暴露一个TiDB节点给大数据进行数据抽取，但是本质上还是对同一组TiKV进行操作，所以抽数操作很容易引起业务的抖动。,现在我们提供了两种方案给业务进行选择，优先可以选择TiCDC，如果TiCDC不能满足的情况下可以使用TiFlash。,,ticdc,对于已经存在cdc任务，只需更新配置即可，另外需要注意下游如果是kafka的话，数据包的大小，要求跟kafka的最大值配置一致，否则可能会报错，尤其是TiDB端扩大表结构的场景。,对我们来说，TiCDC需求真的太需要实现工单化了。那些需要抽数的业务，几乎新增一个表就需要更新TiCDC的任务，之前都是邮件沟通，如今实现工单后，对业务，对大数据团队，又或者是DBA都是十分方便的，降低了三方的沟通成本，提升工作效率。,（4）TiFlash工单,需求同TiCDC工单。,,tiflash,从成本上考虑，TiCDC不需要额外的存储空间，所以更优，也更受欢迎。但是存在一定的风险，比如TiCDC到下游的同步链路出现问题（上游TiDB业务进行调整可能会导致同步中断），那么下游就会无法获取增量数据。,TiFlash则不会有这个问题，但是需要牺牲一定的存储空间，业务成本会有所提升，需要业务自己去权衡。,这部分主要是在平台通过页面操作实现了日常的管理，降低了运维成本，实现了操作审计，还能避免一定的人为操作失误。,（1）节点管理,这部分涉及节点的启动、关闭、重启、下线、维护等。节点启停、重启流程比较简单，这里不做过多介绍。,,节点管理,只有当节点处于关闭状态才会有启动选项。另外需要注意的是，重启操作已经改成reload，这样对业务的影响相对小一些。前提是要评估好restart是否等价于reload（没有变更配置基本不会有什么问题）。,下线和维护操作需要注意如下几个事项：,,节点管理,对于PD，TiKV等组件对数量是有要求的，PD，TiKV最少要求两个，所以当集群只剩两个节点的时候是不允许下线的，需要DBA介入操作，当然还有DM-worker，TiFlash等组件也是有最低数量要求，需要根据实际情况进行判断。,（2）扩容管理,扩容分两种情况，一种是主动扩容，一种是自动扩容。这个小结是介绍主动扩容，至于自动扩容后文会介绍。,扩容功能比较灵活，支持多角色同时扩容，节点个数可配置，目标地址也可配置，如下图所示：,,扩容,未指定地址的话就由系统默认分配合理的目标地址。,（3）下线管理,下线要求是串行操作，即一个集群在同一个时间只能有一个节点被下线，等待下线后才能下线第二个节点。另外，如果是存储节点（TiKV，TiFlash，Pump），需要等待数据迁移完毕后，执行完集群调整（prune）操作才算下线完成。,,下线,需要考虑一下异常节点的下线，即机器宕机不可恢复的情况，所以我们增加了一个强制下线的选项来处理此类异常场景。,（4）告警管理,告警跟运维工作息息相关，一个好的告警管理平台不仅能提升运维的效率，还能提升工作舒适度及生活质量。,我们的告警管理平台现在功能比较简单，后续会慢慢丰富。,,告警管理,静默时间最长不允许超过24小时，默认是2小时，这样可以避免因遗忘导致该告警项被长时间静默。,如下是正在告警列表展示页,,告警管理-告警列表,支持一键静默，即：正在告警的项全部静默。,如下是静默规则列表展示页，正在运行的静默规则支持删除及禁用，禁用状态的允许重新启用。,,告警管理-静默规则列表,（5）慢查询告警,这个功能是统计单位时间内慢查询条目增长量，当达到告警阈值就会触发告警，用户可以设置统计的时间范围，以及慢查询阈值，还有告警阈值。,,慢查询告警-添加规则,集群的慢查询阈值大于用户定义的规则的慢查询最小阈值，会将集群的慢查询阈值设置为该阈值。如集群慢查询阈值是300ms，用户定义告警阈值是200ms，这时候会将集群的慢查询阈值设置为200ms。,如下是规则列表展示页，支持规则禁用及删除，禁用后可以重新启用。,,慢查询告警-规则展示页,（1）进程监控,,进程监控,因线上机器基本都是单机多实例，有时候会出现因为某个实例而影响了整个机器的性能，在没有进程级别的监控下，对我们排查定位问题十分痛苦，为解决这一个痛点，我们开发了进程维度的监控系统，这样可以很好的协助运维人员排查定位机器资源跑满等问题。,进程级别的资源监控，包括但是不限于CPU, 内存, 磁盘IO, 网络流量，功能还在继续丰富。具体实现可以参考这个文章 https://mp.weixin.qq.com/s?__biz=MzIwMjk1ODMzMw==&mid=2247487654&idx=1&sn=0722b7e216cb2f887eea2d8f874faa88&chksm=96d7e434a1a06d22b2a52a87b4bcc8a2fbc52218802ceefa6f243a0bb71a0ea02fd521c67395#rd,,进程监控,会记录每个进程的资源使用情况，其中网络数据是做了限制，只有达到阈值才会采集，所以会出现空白页情况。另外网络传输数据会记录源端到目的端信息。,（2）趋势监控,随着时间的推移，业务数据也在不断的增长。那么问题来了，这个增长是否符合预期？按照这个增量，磁盘空间能支持多长时间？为了解决这两个问题，我们采取了趋势分析的方案，提前监控，分析增长趋势，对于增长异常的集群会和业务进行沟通确认，对于磁盘空间临近告警线会提前迁移。,,进程监控,（3）自动运维,当机器准备达到内存告警阈值，磁盘告警阈值，就自动迁移。,当单个TiKV容量达到800GB就自动进行扩容。,不管是自适应迁移还是扩容，都可以减少DBA的工作量，也能在一定程度上减少告警量。对于扩容，既控制了单个TiKV的大小，对于系统性能也会有一定的提升。,本文介绍了TiDB在转转公司的发展历程，从调研测试到投产使用，从命令行运维到自动化平台管理，将业务日常需求基本实现了工单化，DBA日常管理维护的操作基本都实现了平台化。,我们一步一步走过来，遇到了很多问题，也解决了很多问题，但各自环境不同，需求也不同，还可能碰上其他未知的问题，本文所有内容仅供参考。,关于作者,莫善，转转DBA。负责TiDB，MongoDB，MySQL运维及转转数据库平台开发。