58 同城 TiDB 4.0 报告

🌃 资源中心 📌用户最佳实践
,
1

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执行时间增加了一些

【举例提升明显的集群】

image
image1667×244 153 KB

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节点

6 个赞