58同城TiDB4.0报告

58同城TiDB4.0报告
–刘春雷 58DBA

1、前言

58同城自2018年6月左右开始上线2.0版本,2019 年 5 月 3.0版本发布,58积极跟进新版本的测试、调研等,对线上20套+集群进行版本升级,提升了稳定性与性能。

2020年4月发布4.0 RC版,58同城同样进行版本升级,新版本带来了性能、稳定性的提升,TiFlash的引入,提升了OLTP业务的能力、dashboard等的引入使DBA更了解了数据库的状态。

历经2个月左右的时间,已经将线上的40套3.0.7 升级为4.0.2版本,且部署了2套TiFlash。并同时对于4.0版本的自动化运维进行了相应工具开发改造。达到平台自动化部署、扩容等要求。

2、58同城TiDB数据库情况

58同城TiDB数据库业务涵盖公司10多条业务线,有多种场景的应用,例如数仓、日志、监控、报表平台、聊天信息、信安数据、客服等。

【增长趋势如图】:

image

3、升级4.0版本

3.1、升级方式

使用Ansible升级,或者TiUP方式测试均可以,官方推荐TiUP进行版本升级。

3.2、升级量

升级线上40套TiDB集群,版本为3.0.7,4.0.0-rc.2 ,升级至4.0.2

3.3、升级准备工作

  • 修正目录权限,/home/tidb 目录 要chown 下权限
  • 集群的node_exporter_port,blackbox_exporter_port端口修正为一致,扩缩容方式
  • TiUP导入inventory.ini配置文件,tiup cluster edit-config修正配置文件
  • tiup cluster display查看状态

3.4、升级效果

有些集群升级后提升明显,例如某集群SQL执行时间降低93%,大部分集群SQL执行时间下降10-20%左右,也有部分集群SQL执行时间增加的情况,大致原因是升级后QPS量增加了,集群压力增大,SQL执行时间增加了一些

【举例提升明显的集群】

3.5、升级避坑指南

  • 问题:TiUP在线版本升级容易存在网络下载失败的情况。

  • 处理:重试即可

  • 问题:TiUP离线版本升级,下载对应的新版本要注意下载目录的大小,容易有目录大小不对的情况

  • 处理:注意目录大小,重新下载

  • 问题:TiUP使用:曾导致TiKV被异常停服、删除,导致线上服务受了影响。原因为没有指定对应的版本,导致某些包找不到就给tikv下线了…

  • 处理:使用对应版本(目前新版本已经修复,可以使用新版本操作旧版本的TiDB了)

  • 问题:长时间运行的TiKV重启需要比较长的时间,会存在重启TiKV超时的情况

  • 处理:再次执行,或者调整等待重启的时间

  • 问题:TiUP导入inventory.ini,如果是自定义了node_exporter_port,blackbox_exporter_port端口,会报升级报找不到服务

  • 处理:要tiup cluster edit-config 查看下具体配置,需要手动更改成正确的端口,且提前要修正为所有节点这2个端口要一致的!

  • 问题:TiUP 导入配置重新命名的集群名字是不能被后期再修改的

  • 处理:官方也无法处理,导入重新命名要慎重

  • 问题:TiUP升级前,目前权限导致升级失败

  • 处理:例如/home/tidb 目录 要chown 下权限

  • 问题:TiDB 4.0版本,低版本存在部分bug(有一定宕机率的问题、及官方给的bug)

  • 处理:推荐升级至4.0.2 版本及以上

  • 问题:升级4版本会导致prometheus的api内部的端口变化,导致有些监控没有数据,以及升级存在导致prometheus的部分api数据不对

  • 处理:需要使用tiup reload下监控节点

  • 问题:如果升级中途失败过,可能导致某些TiKV节点成为 evict-leader-scheduler

  • 处理: pd-ctl 查看,执行scheduler remove evict-leader-scheduler

  • 问题:如果系统内核版本过低,存在内存使用过高导致宕机

  • 处理:推荐使用高版本内核,否则会触发内核bug

  • 问题:升级后,SQL执行时间有所变长

  • 处理:可能存在升级后,SQL执行效率好了,导致QPS升高,流量大了,反倒导致SQL执行时间有所变长,需要参考着看

4、TiUP运维使用姿势

  • 问题:在线 or 离线?

  • 考虑网络安全,推荐离线,升级的话可以临时开外网权限,进行打包,或者其他机器下载后上传

  • TiUP自动化使用:

  • 58这边:开发工具,根据元信息自动生成相关节点的拓扑yaml文件,然后自动化执行扩缩容等,目前已经支持3.0/4.0版本的部署、扩缩容tidb/pd/tikv等自动化,与CDB(内部数据库自动化平台)联动

  • DBA拓扑登录工具:快速展示store、member、配置等信息

  • 更改pd-ctl 为tiup ctl pd -u 'http://IP:Port

  • 集群部署、扩缩容自动化工具,添加运维方式

  • 3版本为Ansible方式,4版本使用TiUP方式

5、日常使用经验

情况:58同城初期为多集群的TiDB混合部署

问题:导致存在多集群相互影响的问题,例如某个集群的慢SQL,会影响其他集群,排查问题需要查看多个监控

处理:TiDB节点虚拟化,独立部署。解决了相互影响问题

情况:TiKV节点多集群混合部署

问题:导致集群负载过高

处理:调整TiKV的capacity,及CPU设置等,且单TiKV机器限制混合部署数量,或者使用更好的磁盘,例如闪存卡等

情况:单机群多库

问题:内部相互影响

处理:拆~拆~拆~,大的库迁移出去,且在上线之初评估好库情况,或者前期可以先使用mysql,后期量大了再迁移至TiDB

情况:单机群不宜过大

问题:目前以58同城的TiDB数据库情况来看,大于15T左右,集群的性能会稍微有所下降,且备份也是难题。

处理:及时清理、归档数据,不宜多个库放一个集群,最好控制下单集群的存储量,开启静默region,关注集群SQL执行时间与存储量的关系。

情况:TiKV机器SSD 、闪存卡

问题:TiVK机器,内存及CPU相比磁盘IO瓶颈不大,如果磁盘IO性能不好,会导致SQL执行时间变长,且不能混合部署,导致资源浪费。

有些时候,集群SQL执行时间长,扩容TiKV的SSD机器,并不能很好的提升效率,改成同样数量的闪存卡提升明显。

处理:如果可以,推荐闪存卡,我们使用闪存卡部署了部分TiKV,提效明显,且可以混合部署,可能反倒节约了成本

情况:版本

问题:低版本性能相比高版本差一些

处理:尽量升级至高版本

情况:TiDB Server节点数量

问题:TiDB Server节点数量少,集群QPS高,会导致SQL执行时间变长

处理:扩容TiDB Server节点

3赞