本文档适用于以下升级路径:
警告
ADD INDEX
和列类型变更等耗时较久的 DDL 语句),请勿进行升级操作。在升级前,建议使用 ADMIN SHOW DDL 命令查看集群中是否有正在进行的 DDL Job。如需升级,请等待 DDL 执行完成或使用 ADMIN CANCEL DDL 命令取消该 DDL Job 后再进行升级。注意
如果原集群是 3.0 或 3.1 或更早的版本,不支持直接升级到 6.1.0 及后续修订版本。你需要先从早期版本升级到 4.0 后,再从 4.0 升级到 6.1.0 及后续修订版本。
tiup cluster
) 管理后,再按本文档说明升级到 6.1.0 版本及后续修订版本。tiup cluster
) 将 TiDB Ansible 配置导入。本部分介绍实际开始升级前需要进行的更新 TiUP 和 TiUP Cluster 组件版本等准备工作。
升级 TiUP 和 TiUP Cluster
注意
如果原集群中控机不能访问 https://tiup-mirrors.pingcap.com
地址,可跳过本步骤,然后更新 TiUP 离线镜像。
先升级 TiUP 版本(建议 tiup
版本不低于 1.10.0
):
tiup update --self tiup --version
再升级 TiUP Cluster 版本(建议 tiup cluster
版本不低于 1.10.0
):
tiup update cluster tiup cluster --version
更新 TiUP 离线镜像
注意
如果原集群不是通过离线部署方式部署的,可忽略此步骤。
可以参考使用 TiUP 部署 TiDB 集群的步骤下载部署新版本的 TiUP 离线镜像,上传到中控机。在执行 local_install.sh
后,TiUP 会完成覆盖升级。
tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz sh tidb-community-server-${version}-linux-amd64/local_install.sh source /home/tidb/.bash_profile
覆盖升级完成后,需将 server 和 toolkit 两个离线镜像合并,执行以下命令合并离线组件到 server 目录下。
tar xf tidb-community-toolkit-${version}-linux-amd64.tar.gz ls -ld tidb-community-server-${version}-linux-amd64 tidb-community-toolkit-${version}-linux-amd64 cd tidb-community-server-${version}-linux-amd64/ cp -rp keys ~/.tiup/ tiup mirror merge ../tidb-community-toolkit-${version}-linux-amd64
离线镜像合并后,执行下列命令升级 Cluster 组件:
tiup update cluster
此时离线镜像已经更新成功。如果覆盖后发现 TiUP 运行报错,可能是 manifest 未更新导致,可尝试 rm -rf ~/.tiup/manifests/*
后再使用。
注意
以下情况可跳过此步骤:
6.1.0
默认参数。进入拓扑文件的 vi
编辑模式:
tiup cluster edit-config <cluster-name>
参考 topology 配置模板的格式,将希望修改的参数填到拓扑文件的 server_configs
下面。
修改完成后 :wq
保存并退出编辑模式,输入 Y
确认变更。
注意
升级到 6.1.0 版本前,请确认已在 4.0 修改的参数在 6.1.0 版本中是兼容的,可参考 TiKV 配置文件描述。
以下 TiKV 参数在 TiDB v5.0 已废弃。如果在原集群配置过以下参数,需要通过 edit-config
编辑模式删除这些参数:
为避免升级过程中出现未定义行为或其他故障,建议在升级前对集群当前的 region 健康状态进行检查,此操作可通过 check
子命令完成。
tiup cluster check <cluster-name> --cluster
执行结束后,最后会输出 region status 检查结果。如果结果为 "All regions are healthy",则说明当前集群中所有 region 均为健康状态,可以继续执行升级;如果结果为 "Regions are not fully healthy: m miss-peer, n pending-peer" 并提示 "Please fix unhealthy regions before other operations.",则说明当前集群中有 region 处在异常状态,应先排除相应异常状态,并再次检查结果为 "All regions are healthy" 后再继续升级。
本部分介绍如何滚动升级 TiDB 集群以及如何进行升级后的验证。
升级的方式有两种:不停机升级和停机升级。TiUP Cluster 默认的升级 TiDB 集群的方式是不停机升级,即升级过程中集群仍然可以对外提供服务。升级时会对各节点逐个迁移 leader 后再升级和重启,因此对于大规模集群需要较长时间才能完成整个升级操作。如果业务有维护窗口可供数据库停机维护,则可以使用停机升级的方式快速进行升级操作。
不停机升级
tiup cluster upgrade <cluster-name> <version>
以升级到 6.1.0 版本为例:
tiup cluster upgrade <cluster-name> v6.1.0
注意
--force
参数可以在不驱逐 leader 的前提下快速升级集群至新版本,但是该方式会忽略所有升级中的错误,在升级失败后得不到有效提示,请谨慎使用。--transfer-timeout
为一个更大的值,如 --transfer-timeout 3600
,单位为秒。停机升级
在停机升级前,首先需要将整个集群关停。
tiup cluster stop <cluster-name>
之后通过 upgrade
命令添加 --offline
参数来进行停机升级。
tiup cluster upgrade <cluster-name> <version> --offline
升级完成后集群不会自动启动,需要使用 start
命令来启动集群。
tiup cluster start <cluster-name>
执行 display
命令来查看最新的集群版本 TiDB Version
:
tiup cluster display <cluster-name>
Cluster type: tidb Cluster name: <cluster-name> Cluster version: v6.1.0
注意
TiUP 及 TiDB 默认会收集使用情况信息,并将这些信息分享给 PingCAP 用于改善产品。若要了解所收集的信息详情及如何禁用该行为,请参见遥测。
本部分介绍使用 TiUP 升级 TiDB 集群遇到的常见问题。
重新执行 tiup cluster upgrade
命令进行升级,升级操作会重启之前已经升级完成的节点。如果不希望重启已经升级过的节点,可以使用 replay
子命令来重试操作,具体方法如下:
使用 tiup cluster audit
命令查看操作记录:
tiup cluster audit
在其中找到失败的升级操作记录,并记下该操作记录的 ID,下一步中将使用 <audit-id>
表示操作记录 ID 的值。
使用 tiup cluster replay <audit-id>
命令重试对应操作:
tiup cluster replay <audit-id>
可以指定 --force
,升级时会跳过 PD transfer leader
和 TiKV evict leader
过程,直接重启并升级版本,对线上运行的集群性能影响较大。命令如下:
tiup cluster upgrade <cluster-name> <version> --force
可通过 TiUP 安装对应版本的 ctl
组件来更新相关工具版本:
tiup install ctl:v6.1.0