漫谈TiDB数据库部署

漫谈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 有一定参考价值,减少一些弯路~

1赞

很详细,谢谢分享

静默region有多大的提升?或者说有什么明显的改善?

客气~

1、在region数比较多的时候,例如50w,开启会提升很多,减少了上报PD的心跳数,SQL执行时间至少能降低20%(保守),region数越多线上表现越好,这个必开的优化~