作者： 18515065291 原文来源：https://tidb.net/blog/f40b0eb4

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 多条业务线，有多种场景的应用，例如数仓、日志、监控、报表平台、聊天信息、信安数据、客服等。

【增长趋势如图】：

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