作者： 18515065291 原文来源：https://tidb.net/blog/6ac99f39

58 同城大规模 TiDB 运维实践

–2020-10-21 刘春雷

1、前言

为了贴合周六的 TUG 走进伴鱼的主题：TiDB 大规模运维实践，大致讲讲 58 同城 TiDB 运维实践。

2、TiDB 现状

自 18 年 7 月上线至今，已经部署了 52 套集群 ， 服务器 体量 320+ 台 ，涵盖业务线：本地服务、58 房产、金融公司、车业务、TEG- 搜索、用户增长、商业产品技术、58 招聘、信息安全、安居客等 15 条业务线。

使用存储 130T+，整体上已经算是比较大的体量了（膜拜比 58 体量大的大佬~）

【TiDB 集群架构情况】

3、对大规模采取了哪些措施？

既然规模已经比较大了，我们有几个 TiDB DBA 呢？2 个 (同时还要负责 MySQL 建设) ！，近期又入职了 1 个同学，我们可以继续在 tidb 上做一些建设工作了~

3.1、大规模运维方向

论把大规模 TiDB 数据库运维好，总共分几步？

• 第一步：基础建设

• 制定好运维规范，如端口、目录、服务器类型 / 配置、

• 制定好业务接入准则、开发规范

• 建设好元信息，集群、实例、库等维度，集群管理员、业务线等

• 拓扑查看、访问工具

• 自动化部署集群、部署库

• 自动化扩容、缩容、升级等

• 连接管理, 因 TiDB 表都比较大，开发随便跑个 SQL 都有可能是特别慢的 SQL，要有处理机制，例如 kill 等

• 第二步：监控

• 自动化存活监控、报警

• 自动化性能监控、报警

• 统一入口，查看所有集群重点监控情况

• 第三步：备份

• 制定好备份规范、备份方式 (mydumper、BR)

• 自动化备份与恢复

• 第四步：迁移

• 制定好接入业务规范，不是所有业务都可以接入 TiDB

• 测试好迁移工具，如 mydumper、loader、lightning、syncer、DM 等

• 第五步：平台化

• 平台化管理元信息

• 平台自动化创建、扩缩容集群

• 自动化工单，如建表、改表、授权、导数据等

• 监控图展示，如性能监控：CPU、IO、QPS、SQL 执行时间等等

• 开发相关报表：如集群重点信息：集群大小、增长趋势、QPS 等，服务器负载报表，库表具体信息报表，慢 SQL 报表

• 自助查询 (开发可以在平台查询数据)

• 权限管理：管理员、开发、测试等

• 第六步：文档化

• 为了让 DBA 更高效的工作，文档化是跑不开的，例如写好：开发使用须知、使用手册、TiDB 与 MySQL 对比、基准测试 (功能、性能)

这样，TiDB 这头 ” 大象 ” 就成功装入冰箱了~

3.2、无图无真相

【CDB- 管理端】

【CDB- 客户端】

【CDB- 客户端：集群概览】

【汇总监控】

4、单集群大规模运维经验

58 这边，单集群大一点的大约 20T 左右, 日常操作比较多的还是 1-5T 左右的集群，关注如下

• 慢 SQL 情况，并及时优化

• 定期查看重点监控，例如 SQL 执行时间，QPS、服务器负载等

• 空间使用率控制在 60% 以下，如果超了，及时扩容

• 如果数据可以定期归档，及时归档数据，使用 Tokudb 的高压缩来实现

• 业务升级，版本号比当前多个 5-8 个版本，或者当前版本有明显问题、新版本有大的功能、性能提升，才会进行升级，且会选择业务低峰期操作，如果 region 很多，滚动时要注意等待 leader 传输的等待时间

• 扩缩容实例:

• tikv，要注意数据平衡速度，几个 limit 的参数，如果调整的过高，会影响 SQL 执行时间

• tidb：要注意连接的中断，提前周知业务

• PD：切换的话，会阻塞，需要业务低峰期操作

• 添加索引等，特别大的表，要注意添加索引的速度，及时调整，减少对线上的影响。

• 混合部署，要注意相互影响的问题，58 这边已经使用虚拟机来实现相关隔离了，例如 TiDB、PD Server 使用 32G/8 核的虚拟机部署，大大减少了相互影响的问题。

5、常见问题与解决思路

问题： 慢 SQL

处理： 4.0 版本要关注 dashboard，关注慢 SQL 表 SLOW_QUERY 等，及时发现，及时优化。具体查看是从 DBA 角度优化，还是业务角度。

问题： 实例故障

处理： 及时报警，及时处理，关注监控：业务流量，SQL 执行时间等，并及时扩容

问题： 连接阻塞

处理： 要有连接管理，阻塞及时进行 kill，及时优化阻塞的 SQL，及时扩容

问题： 读写时间异常增长、读写时间持续很高

处理： 调整相关参数，例如均衡、合并数据、迁移热点等限制参数，调整相关 tikv 参数，增大线程数、cache 等，关注慢 SQL，异常 SQL，替换更好的磁盘等。推荐使用虚拟机来部署 TiDB、PD 节点，例如使用 32G、8 核虚拟机来部署，可以减少相互影响的情况

6、运维平台落地经验

想要快速建设 TiDB 运维平台，要做好：规范化、工具化、自动化这几个点，这样平台化就水到渠成了

优先实现重要紧急的功能，如：元信息管理、自动化部署、扩缩容，工单自动化、自助查询等

再实现重要不紧急的功能，如：报表可视化、备份恢复、实时监控展示、慢 SQL 展示

最后再进行其他功能建设等：如权限管理等，持续迭代进行平台化建设。

7、总结

TiDB 历经 2.x 至今 4.x，已经成熟稳定了很多，且很多自动化相关工作官方已经替大家实现了，例如 tiup，虽然 tiup 还有很多问题 (别怪我吐槽，吐槽是为了 TiDB 更好~)，大家适当根据自己的业务场景建设平台即可。

58 同城这边，因前期开发了很多自动化工具，历经 ansible、tiup，有大致 15 种多，持续跟进官方的更新而迭代，所以能够很好、很快的建设平台化，节约了很多人力~

最后希望大家都能更轻松的运维 TiDB!