作者：刘春雷
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节点
