基于阿里云 ECS 部署的 TiDB 2.1.14 升级到 4.0.0-rc 实践

作者： CuteRay 原文来源：https://tidb.net/blog/d07b432f

【是否原创】是

【首发渠道】知乎

【首发渠道链接】 基于阿里云 ECS 部署的 TiDB 2.1.14 升级到 4.0.0-rc 实践 - 知乎 (zhihu.com)

【正文】

前言

随着 TiDB 最新版本 v5.2 的发布，线上有一套跑了两年多的 TiDB v2.1.14 也显得太过老旧，加上相关业务系统也是越来越慢，于是决定对数据库进行升级操作。一方面是抛弃利用 ansible 的运维方式，使用 tiup 接管整个集群，方便后续运维，二来也确实是遇到了性能瓶颈，急需升级。

原 TiDB 集群是基于阿里云 ECS 部署的，预先就设置了防火墙、安全组、网络等，同一子网内的机器互通有无，对于中控机等对外提供服务的机器，对其端口做了一个规划，开设 4000、3000 等对外访问端口。

此次升级也是参考了 AskTUG 社区中 SOP 系列文章，感谢 AskTUG 社区的支持。

【SOP 系列 01】 Release-2.1 升级到 Release-3.0 线上集群升级 - 新手区 / TiDB 运维手册 - AskTUG

TiDB 架构说明

说明：这是一套测试环境中 TiDB 的配置。整个 TiDB 集群是一个缩小化的线上业务集群，一个 TiDB 节点，一个 PD 节点，三个 TiKV 节点，一组 TiDB Binlog。

版本信息：

PS：由于 TiDB v4.0 当中新加了一个 dashboard 的功能，于是预先开放 PD 节点的 2379 端口，供外部访问。

升级方式

有两种方式，经过测试，都是可行的。

方案一：逐步滚动升级，先将原 TiDB 升级到 TiDB v3.1.0，然后再升级到 TiDB v4.0.0-rc，接着用 TiUP 接管。

升级过程：

第一步：TiDB v2.1.14 升级到 TiDB v3.1.0

1. 升级前的准备

2. 修改 inventory.ini 文件 和配置文件

参照之前版本的 inventory.ini 的配置，去修改新部署集群的配置

   # 修改inventory.ini    cd /home/tidb/tidb-ansible   vi inventory.ini
   # 修改conf文件    # 集群部署有drainer，这里需要修改conf目录下的drainer.toml，保证与老集群一致   vi /home/tidbtidb-ansible/conf/drainer.toml

1. 执行升级操作

2. 升级完的检查

检查 grafana overview 面板，确保所有组件正常启动；

检查 grafana TiDB、PD、TiKV 面板，确保无异常情况；

检查 TiDB Binlog 组件，确保时间戳得到更新；

第二步，利用 TiUP 将 TiDB v3.1.0 升级到 TiDB v4.0.0-rc

1. 安装 tiup

2. 将 TiDB Ansible 及 inventory.ini 配置导入到 TiUP

1. 升级 TiDB 集群

方案二：直接升级，直接将 TiDB v2.1.14 升级到 TiDB v4.0.0-rc，然后再用 TiUP 接管整个集群。

这个方案的升级过程与 TiDB v2.1.14 升级到 TiDB v3.1.0 过程类似，最后直接将 tidb-ansbile 导入到 tiup 工具接管，这里不做过多赘述了。

升级过程中遇到的问题

1. tidb-ansible 无法正常启动，提示 ImportError: No module named markupsafe

解决办法：

在安装之前，使用 sudo pip uninstall markupsafe 卸载原来遗留的包

执行 sudo yum install python-markupsafe -y

PS：需要注意的是，这里不能使用 pip install markupsafe ，用 pip 安装的是错误的包

1. node_exporter、blackbox_exporter 利用服务脚本无法关闭，提示关闭超时

在升级的过程中，在一台机器上出现这个问题 ，提示服务没找到，但是那台机器上是的的确确存在这个服务的。

解决办法：

在 ansible 脚本等待的过程中，手动停止这两个服务

systemctl stop node_exporter-9100.service blackbox_exporter-9115.service

1. 升级完成之后，dashboard 提示没找到 Prometheus 组件

解决办法：

执行 tiup cluster reload test-cluster 问题得到解决

性能对比

这里使用 sysbench 分别对 v2.1.14 和 v4.0.0-rc 版本的 TiDB 集群做简单测试，对比升级后的性能变化。

TiDB v2.1.14 sysbench read&write 测试结果：

TiDB v4.0.0-rc sysbench read&write 测试结果：

TiDB 从 v2.1.14 升级到 v4.0.0-rc，性能的确得到了不小的提升，当然，这只是测试环境，也只是简单跑了一下 sysbench 测试，到了线上业务集群，性能提升也许更大。

总结

此次升级过程，让我体会到了 tidb 每次版本升级所带来的巨大变化，3.x 开始出现的 tiflash、4.x 出现的运维神器 TiUP、以及每次升级所带来的集群性能方面的提升。

在 TiUP 出现以前，运维过程是一个非常繁琐的过程。在用 tidb-ansible 运维集群的时候，一个集群的配置得去好几个文件中去修改，一个文件一个文件的去对比、确认，执行过程相较于 TiUP 工具而言也比较繁复。不得不说，TiUP 的出现，可以将 TiDB 划分为两个时代。

这一次的集群升级，结果是十分成功的，也为不久之后的业务集群升级打下了坚实基础。