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!