【是否原创】是
【首发渠道】知乎
【首发渠道链接】 基于阿里云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。
IP地址 | 配置 | 部署组件 | 系统版本 | 额外 |
---|---|---|---|---|
10.133.1.131 | 16C 64G | TiDB | CentOS 7 | grafana、中控机器 |
10.133.1.137 | 16C 64G | TiKV | CentOS 7 | |
10.133.1.138 | 16C 64G | TiKV | CentOS 7 | |
10.133.1.139 | 16C 64G | TiKV | CentOS 7 | |
10.133.1.132 | 8C 16G | pump | CentOS 7 | |
10.133.1.136 | 8C 16G | PD | CentOS 7 | monitoring、alertmanager |
10.133.1.129 | 8C 16G | drainer | CentOS 7 |
版本信息:
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
-
升级前的准备
# 进入到中控机,切换为tidb用户 su tidb # 备份原tidb-ansible 部署文件 cd /home/tidb mv tidb-ansible tidb-ansible-bak # 下载TiDB 3.1.0对应的tidb-ansible脚本 git clone -b v3.1.0 https://github.com/pingcap/tidb-ansible.git # 检查tidb-ansible依赖是否完整 cd /home/tidb/tidb-ansible && \" sudo pip install -r ./requirements.txt # 确保中控机存在ansible ansible --version # 检查SSH互信配置以及tidb用户sudo免密配置 cd /home/tidb/tidb-ansible-bak # 均返回tidb,则代表SSH互信配置OK ansible -i inventory.ini all -m shell -a 'whoami' # 均返回root,则代表tidb用户 sudo免密配置OK ansible -i inventory.ini all -m shell -a 'whoami' -b
-
修改 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
-
执行升级操作
cd /home/tidb/tidb-ansible # 下载TiDB v3.1.0的binary到中控机中 ansible-playbook local_prepare.yml # 执行升级脚本 ansible-playbook excessive_rolling_update.yml # 滚动升级TiDB 监控组件 ansible-playbook rolling_update_monitor.yml # 升级TiDB Binlog组件 # pump 集群升级,pump也会跟着升级 # drainer ansible-playbook stop_drainer.yml --tags=drainer ansible-playbook start_drainer.yml --tags=drainer
-
升级完的检查
检查grafana overview面板,确保所有组件正常启动;
检查grafana TiDB、PD、TiKV面板,确保无异常情况;
检查TiDB Binlog组件,确保时间戳得到更新;
第二步,利用TiUP将 TiDB v3.1.0升级到 TiDB v4.0.0-rc
-
安装tiup
# 在中控机上执行命令(使用tidb用户,而非root用户执行) curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh # 重新生命全局变量 source .bash_profile # 确认tiup工具正常安装 which tiup # 安装 tiup cluster工具 tiup cluster
-
将 TiDB Ansible 及 inventory.ini 配置导入到 TiUP
# 导入配置 tiup cluster import -d /home/tidb/tidb-ansible # 通过display查看集群信息 tiup cluster display test-cluster
-
升级TiDB集群
# 修改集群配置,对比以前的inventroy.ini的配置与topology模板来进行修改 tiup cluster edit-config test-cluster # 执行滚动升级 tiup cluster upgrade test-cluster v4.0.0-rc # 升级后的验证 tiup cluster display test-cluster
方案二:直接升级,直接将TiDB v2.1.14升级到TiDB v4.0.0-rc,然后再用TiUP接管整个集群。
这个方案的升级过程与TiDB v2.1.14升级到TiDB v3.1.0过程类似,最后直接将tidb-ansbile导入到tiup工具接管,这里不做过多赘述了。
升级过程中遇到的问题
-
tidb-ansible无法正常启动,提示ImportError: No module named markupsafe
解决办法:
在安装之前,使用 sudo pip uninstall markupsafe 卸载原来遗留的包
执行 sudo yum install python-markupsafe -y
PS:需要注意的是,这里不能使用 pip install markupsafe ,用pip安装的是错误的包
-
node_exporter、blackbox_exporter 利用服务脚本无法关闭,提示关闭超时
在升级的过程中,在一台机器上出现这个问题 ,提示服务没找到,但是那台机器上是的的确确存在这个服务的。
解决办法:
在ansible脚本等待的过程中,手动停止这两个服务
systemctl stop node_exporter-9100.service blackbox_exporter-9115.service
-
升级完成之后,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划分为两个时代。
这一次的集群升级,结果是十分成功的,也为不久之后的业务集群升级打下了坚实基础。