漫谈TiDB数据库部署

--2020-11-08 刘春雷

1、前言

使用TiDB数据库2年多了，部署架构上踩过很多坑，也有过很多优化，此篇文章大致梳理下，希望对大家有所帮助~

2、阶段目标

如果说部署及架构私有云(K8S)为最终目标，那么58这边算是走到了第二阶段

【第一阶段：探索阶段】：

• 调研TiDB、探索业务场景、尝试部署架构、解决问题、优化部署

【第二阶段：稳定阶段】：

• 有一定使用经验，提升了稳定性，自动化、平台化的总体完善，沉淀了较好的部署架构，优化业务，快速、稳定发展

【第三阶段：私有云阶段】：

• 探索更好、更轻、更节约人力的运维方式，跟上业界步伐，让DBA有精力去深入优化业务，更多的赋能业务~

3、第一阶段：探索阶段

这一阶段，属于探索阶段，几乎没有很好的业界实践经验，只能自己尝试。

【版本】： 2.x，3.x
【部署机器】：

• TiDB & PD：内存型物理机
• TiKV ：单盘挂载 x 4 的物理机，CPU 32核，内存128G

【集群间部署情况】：

• 多套 TiDB & PD & Prometheus & Grafana 混合部署在多个内存型机器上
• TiKV 单机部署一个集群，4个TiKV节点 分布在独立的4个单盘上

【集群使用情况】：

• 大集群思想，每套集群上建立多个库(schema)

【运维规范】：

• 制定集群的端口规范，每个间隔一定数量，减少混合部署端口问题

【问题】：

• 单个集群占用空间特别大，短时间内就超过了5T、10T，导致Region数多，心跳繁忙

• 单集群内多个库相互影响，慢SQL多

• 多个集群TiDB Server相互影响，导致某一集群慢SQL，影响多个集群的TiDB Server、PD Server等，排查问题复杂

• 单机部署过多TiKV 节点，导致内存、CPU资源不足，经常宕机，最多的时候，1个月宕机4-6台+

• 消耗内存型机器过多，资源跟不上，导致内存型机器部署实例越来越多，有点到达14个多，严重影响了性能及稳定性

• 宕机影响范围大：

  • TiDB & PD 节点宕机，至少影响集群6套以上，宕机一次，DBA需要处理一下午
  • TiKV 节点宕机：4个TiKV节点受影响，导致集群状态异常，且受限于2.x，3.x版本的恢复速度，直接没有流量，影响时间长；有的30分钟级别恢复不了原来的流量，只能等机器起来才能恢复。

• TiKV机器使用的是某老旧型号，磁盘及机器性能都不好，集群读写性能上不去。

【临时处理】：

• 拆分集群，重要的、量大的库单独部署
• 后期出了静默region后，所有集群都设置上
• 重要集群的TiDB Server 部署在节点少、流量少的内存型物理机上
• 关注流量、慢SQL、CPU等报警
• 及时优化慢SQL
• 部分集群尝试使用性能更好的TiKV机器，128G/40核、6x800G SSD RAID5

4、第二阶段：稳定阶段

这一阶段，属于趋于稳定阶段，有了自己的实践经验，能很好的规避一些风险及提升了稳定性。

【版本】 ：3.x,4.x

【部署机器】：

• TiDB ：内存型虚拟机 32G/8核
• PD ：内存型虚拟机 16G/8核
• TiKV ：物理机，CPU 40核，内存128G，6x800G SSD RAID5 或 单盘闪存卡3.5T

【集群间部署情况】：

• TiDB独立部署
• PD独立部署
• Prometheus&Grafana 与TiDB 混合部署
• TiKV 单机混合部署2个集群的TiKV节点，在1个RAID5 分区上

【集群使用情况】：

• 中小型集群思想，每套集群上建立1个重要、量大的库(schema)
• 单独集群部署同一业务的多个量小、不重要的库(schema)，例如日志流水等

【接入规范】 ：

• 规范上对接入的业务进行量及增长情况评估，增量小的、增量不明确的暂时使用MySQL，后期量大了再迁移至TiDB
• 从MySQL接入单表大于100G的，解决MySQL问题

【版本】：

• 快速跟进官方版本迭代，快速调研测试，自动化开发，快速升级，提升性能及丰富功能

【近期工作】：

• Q4大批量替换虚拟机，独立部署，目前剩余近百节点待替换

【优势】：

• TiDB、PD节点独立部署，减少相互影响情况，稳定性提升

• TiDB、PD虚拟机部署，对磁盘要求不高，独立部署后，SQL执行时间没有明显变化，有些更好了

• 接入业务时查看情况，减少小库的不正确使用

• 虚拟机有专业的团队支持，申请简单，可以支持大量使用，稳定性比较好

• TiKV减少部署节点至2个，并配置内存相关参数，减少相互影响，减少宕机概率

• TiKV同一分区，减少集群磁盘使用不均衡问题

• 性能要求高的集群，使用闪存卡，性能至少是 RAID5 后的SSD的5倍以上，解决了性能问题，尤其是写入QPS高的。

• 部署TiFlash，减少分析型SQL对业务性能的影响

• 宕机影响范围小：

  • TiDB & PD 宿主机宕机，影响范围减少，多数为1-2个TiDB虚拟机受影响
  • TiKV 宕机：至多影响2个集群，每个集群1个节点，影响小，业务流量恢复快

【问题】：

• TiKV机器上混合部署2节点，还是会有相互影响的问题，待解决
• 集群存储量比较小的话，磁盘使用率比较低，限于TiKV机器节点数要求，又无法部署很多。

【临时解决】：

• 更多的从接入时的情况来限制，小库先使用MySQL，大了再迁移TiDB
• 及时跟进量小的集群，或混合部署多个不重要、量小的库(scheme)

【最终】：

• 最近1年节点宕机次数，大约在5台之内（所有节点），且均快速恢复
• 开发反馈问题减少，满意度增加

5、最终阶段：云化

这一阶段，属于目标阶段，因为虚拟机还是比较重，还是想达到业界的云化阶段，私有云建设。例如官方已经出了TiDB Operator，是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上。 这样能更好的运维TiDB，真正的解决资源隔离的需求等。

因目前的自动化、平台化都做的比较完善了，很多工作都是基于CDB平台了，且DBA人力不多，也需要Kubernetes团队配合，暂时对于快速使用Kubernetes等虚拟化要求不高，暂定计划为2021年开始做。

目前工作重点还在深度优化业务、尽快替换内存型物理机至虚拟机，保证年底高峰期的稳定运行上，同时积极学习相关知识等。

希望此文对于大家部署TiDB 有一定参考价值，减少一些弯路~