tiup升级tidb

TiDB升级方案

一、现有有集群信息

集群机器

机器IP	TiDB组件	备注
11.11.10.1	pd、tidb
11.11.10.2	pd、tidb
11.11.10.3	pump
11.11.10.4	tikv
11.11.10.5	tikv
11.11.10.6	tikv
11.11.10.7	tiup 、prometheus
11.11.10.8	tidb

负载均衡器

11.11.10.10 端口3006 负载TIDB tidb组件的4000端口

主要业务数据库配置配置的是11.11.10.10

二、升级版本信息

版本：6.1.1

1、升级兼容性说明

●TiDB 目前暂不支持版本降级或升级后回退。

●使用 TiDB Ansible 管理的 4.0 版本集群，需要先按照 4.0 版本文档的说明将集群导入到 TiUP (tiup cluster) 管理后，再按本文档说明升级到 6.1.0 版本及后续修订版本。

●若要将 3.0 之前的版本升级至 6.1.0 版本：

a首先通过 TiDB Ansible 升级到 3.0 版本。

b然后按照 4.0 版本文档的说明，使用 TiUP (tiup cluster) 将 TiDB Ansible 配置导入。

c将集群升级至 4.0 版本。

d按本文档说明将集群升级到 6.1.0 版本。

●支持 TiDB Binlog，TiCDC，TiFlash 等组件版本的升级。

●具体不同版本的兼容性说明，请查看各个版本的 Release Note。请根据各个版本的 Release Note 的兼容性更改调整集群的配置。

●升级 v5.3 之前版本的集群到 v5.3 及后续版本时，默认部署的 Prometheus 会从 v2.8.1 升级到 v2.27.1，v2.27.1 提供更多的功能并解决了安全风险。Prometheus v2.27.1 相对于 v2.8.1 存在 Alert 时间格式变化，详情见 Prometheus commit。

2、适用升级路径

●从 TiDB 4.0 版本升级至 TiDB 6.1 及后续修订版本

●从 TiDB 5.0-5.4 版本升级至 TiDB 6.1 及后续修订版本

●从 TiDB 6.0 版本升级至 TiDB 6.1 及后续修订版本

3、升级方式

●不停机升级

○默认的升级 方式，即升级过程中集群仍然可以对外提供服务。升级时会对各节点逐个迁移 leader 后再升级和重启，因此对于大规模集群需要较长时间才能完成整个升级操作。

○滚动升级会逐个升级所有的组件。升级 TiKV 期间，会逐个将 TiKV 上的所有 leader 切走再停止该 TiKV 实例。默认超时时间为 5 分钟（300 秒），超时后会直接停止该实例。

○使用 --force 参数可以在不驱逐 leader 的前提下快速升级集群至新版本，但是该方式会忽略所有升级中的错误，在升级失败后得不到有效提示，请谨慎使用。

○如果希望保持性能稳定，则需要保证 TiKV 上的所有 leader 驱逐完成后再停止该 TiKV 实例，可以指定 --transfer-timeout 为一个更大的值，如 --transfer-timeout 3600，单位为秒。

○若想将 TiFlash 从 5.3 之前的版本升级到 5.3 及之后的版本，必须进行 TiFlash 的停机升级。参考如下步骤，可以在确保其他组件正常运行的情况下升级 TiFlash：

ⅰ关闭 TiFlash 实例：tiup cluster stop -R tiflash

ⅱ使用 --offline 参数在不重启（只更新文件）的情况下升级集群：tiup cluster upgrade --offline

ⅲreload 整个集群：tiup cluster reload 。此时，TiFlash 也会正常启动，无需额外操作。

●停机升级

如果业务有维护窗口可供数据库停机维护，则可以使用停机升级的方式快速进行升级操作。

4、升级时间

三、业务影响范围

业务	负责人

四、升级步骤

0、创建集群内NFS

111.11.10.7 再挂载一块500G ESS磁盘，创建本地NFS，存储tidb集群的快照备份，保留7天，过期后回收释放

# tikv节点和BR节点挂载数据备份NFS目录
mount -t nfs \
 -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 \
11.11.10.7:/mnt/backups-nfs /mnt/tidb-br-backup \
&& df -mh


11.11.10.7:/mnt/backups-nfs /mnt/tidb-br-backup nfs defaults,nodelalloc,noatime 0 0

1、备份

●使用BR冷备份tidb物理存储SST文件到NFS中（大约2个半小时）

○备份

mkdir -p /mnt/tidb-br-backup/20221029
/opt/tidb-toolkit-v5.1.0-linux-amd64/bin/br backup full \
    --pd "11.11.10.1:2379,11.11.10.2:2379" \
    --storage "local:///mnt/tidb-br-backup/20221029" \
    --log-file backupfull20221029.log

○校验备份

/opt/tidb-toolkit-v5.1.0-linux-amd64/bin/br debug checksum \
    --storage 'local:///mnt/tidb-br-backup/20221029' \
    --log-file checksum20221029.log

○增量备份

/opt/tidb-toolkit-v5.1.0-linux-amd64/bin/br debug checksum \
    --storage 'local:///mnt/tidb-br-backup/20221029' \
    --log-file checksum20221029.log

○校验备份

/opt/tidb-toolkit-v5.1.0-linux-amd64/bin/br debug checksum \
    --storage 'local:///mnt/tidb-br-backup/20221029' \
    --log-file checksum20221029.log

• mysql库系统权限表SQL备份

  ○user

  ○db

  ○tables_priv

  ○columns_priv

• 备份tiup数据目录

su - tidb
cp -r .tiup .tiup-bak20221029

2、升级TiUP

tiup mirror set https://tiup-mirrors.pingcap.com
tiup mirror show
tiup update --self
# TiUP命令版本必须大于1.10.0

tiup cluster display zzmed-prod-tidb4

3、升级 TiUP Cluster 版本

tiup list tidb
# 查看支持的TIDB版本

4、修改升级不兼容参数

5、检查当前集群的健康状况

tiup cluster check zzmed-prod-tidb4 --cluster

6、不停机升级 TiDB 集群

tiup cluster check zzmed-prod-tidb4 --cluster

7、升级验证

• 集群验证

tiup cluster display prod-tidb

• 登录Dashboard

  • 是否可登录

• 客户端登录

  • Navicat验证用户登录是否正常

• 数据一致性验证

• 监控告警

  • Grafana监控是否正常

• 业务验证

  • 详见业务影响范围

五、升级失败措施

1、创建备用集群，恢复备份，切换负载均衡

2、重建集群、恢复备份