原文来源：https://tidb.net/blog/923e18c3
作者：脚本小王子 、Ethan_chen
一、概述
当前我们生产 TiDB 集群版本为 v5.3.0，需要升级到 v7.5.2 解决我们生产环境中遇到的问题，并使用上新功能提高集群性能及降低维护成本。
由于升级版本跨度大，在生产升级前，我们阅读了从 V5.3.0 到 7.5.2 的所有 Release（这很重要），并记录下相关的影响项以及一些对自己有价值的新特性，然后先在自己搭建的虚拟机环境做相关验证。
数据库作为最底层的核心组件，稳定性是至关重要，因此我们制定的升级路径为：【个人环境 (工作电脑上搭建的虚拟机) 升级测试】 -> 【开发环境升级验证】 -> 【测试环境升级验证】 -> 【生产环境升级】。
开发环境升级完成后，让开发同学使用一周左右确保没有问题，然后再对测试环境进行升级。测试环境是最接近生产的环境，因此最容易在此处暴露出问题，我们就是在此步发现 CDC 的 maxwell 格式和老版本格式不一致的问题，避免了一次升级导致业务不可用的严重故障。测试环境升级完成观察约两周左右，再对生产环境进行升级。
值得注意的是，在相同的版本下，通过升级达到该版本和直接搭建该版本的默认参数是不一样的。为了保证生产升级前要把问题全暴露出来，我们选择从第一次搭建的版本开始升级。例如我们是从 v4.0.4 开始使用 TiDB，然后升级到 v4.0.10，再到现在的 v5.3.0，因此我们在非生产环境做验证时，先搭建 v4.0.4，然后再一路升级到 v5.3.0，此时再把虚拟机保存一个快照，便于反复测试 v5.3.0 到 v7.5.2 的升级验证。
建议在升级前把 show global variables 和 show config 的内容全保存下来，这样做的好处是升级后当有一些负面影响，可以通过对比升级前后的变量及配置，比较快速的定位到问题（例如升级后的备份速度明显变慢，经对比发现 backup.num-threads 由原来的 8 自动变更为 2 导致）
备份永远是 DBA 最后的王牌，我们在生产环境真正升级前，先制定了全备和增量的备份策略，并应用在另外一个备用集群中，虽然最终没启用备用集群，但因为有它的存在，我们的升级中遇到问题也不致于乱了阵脚，还有选择试一试的勇气。
通过版本升级，我们主要达到以下目的：
1.1、解决现版本的 bug
(1)、解决备份时间过长 及 增量备份、还原太慢问题（目前采用 tibinlog 还原很慢）。
(2)、ticdc 会卡死的问题（v6.5.8 解决了非常多的 ticdc 问题）。
(3)、解决对指定 ip 段的用户每次登录日志都报错“Failed to get user record”, 导致产生大量日志的问题。
(4)、解决 tidb-server OOM 后加载统计信息很慢导致业务无法恢复的问题。
在 TiDB 启动阶段，初始统计信息加载完成之前执行的 SQL 可能有不合理的执行计划，从而影响性能。为了避免这种情况，从 v7.1.0 开始，TiDB 引入了配置项 force-init-stats。可以控制 TiDB 启动时是否在统计信息初始化完成后再对外提供服务。该配置项从 v7.2.0 起默认开启。
(5)、修复将 FLOAT 列改为 DOUBLE 列后查询结果有误的问题（v5.3.1 修复）。
(6)、修复了查询 INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY 表导致 TiDB 服务器 OOM 的问题，在 Grafana dashboard 中查看慢查询记录的时候可能会触发该问题 #33893（5.3.2 重要 bug 修复【官方不建议使用该版本】）。
1.2、新增功能有利于提高性能及降低维护成本
(1)、6.3.0 支持自动分区。
(2)、7.1.0 支持分区重组（分区拆分合并）。
(3)、TiDB 在 v6.0.0 版本中引入了缓存表功能。
(4)、6.2.0 支持 point-in-time recovery (PITR)，允许恢复备份集群的历史任意时间点的快照。
(5)、从 v7.4.0 开始，TiDB 支持在 GROUP BY 子句中使用 WITH ROLLUP 修饰符和 GROUPING 函数。
(6)、支持统计信息采集配置持久化 tidb_persist_analyze_options（5.4.0 新加功能）。
(7)、优化备份对集群的影响。
(8)、在 6.0.0 中，对内存悲观锁进行优化，可以有效降低 10% 延迟，提升 10% QPS。
二、升级后的性能表现
(1)、集群的稳定性提高：升级到 7.5.2 后，TiDB 集群 OOM 的次数相比之前大幅度下降。
(2)、TiKV 组件内也会自动 GC，不需要重启 TiKV 节点来帮助 GC 回收 region。
(3)、使用表 TTL (Time To Live，生存时间) 清理过期数据 ，减少了使用脚本处理过期数据造成的数据库压力。
(4)、如下图所示，本次升级后数据库的响应时间及 TiDB server 内存都得到优化。
三、升级演练（非生产环境升级）
3.1、 升级前检查
3.1.1、停止相关定时作业
停止包含有备份、还原、ddl 操作的所有定时作业
3.1.2、检查 server-version
server-version 的值设置为空或者当前 TiDB 真实的版本值，避免出现非预期行为
mysql> show config where name like '%server-version%';+------+---------------------+----------------+-------+| Type | Instance | Name | Value |+------+---------------------+----------------+-------+| tidb | 192.168.68.129:4000 | server-version | || tidb | 192.168.68.128:4000 | server-version | |+------+---------------------+----------------+-------+2 rows in set, 1 warning (0.07 sec)
复制代码
3.1.3、系统架构检查
在 Linux AMD64 架构的硬件平台部署 TiFlash 时，CPU 必须支持 AVX2 指令集，执行以下命令有输出：
cat /proc/cpuinfo | grep avx2
复制代码
在 Linux ARM64 架构的硬件平台部署 TiFlash 时，CPU 必须支持 ARMv8 架构，执行以下命令有输出：
cat /proc/cpuinfo | grep 'crc32' | grep 'asimd'
复制代码
注意：对于虚拟机搭建的自测环境不支持 avx2 的情况，可以通过修改 tiflash 启动脚本绕过【生产环境务必支持 avx2】，但该文件会在升级过程中会被覆盖还原，最后导致升级不成功，因此需要在升级过程中不断的检查该文件是否被覆盖，如果被覆盖了要及时修改回来，此时可以拷贝以下脚本在所有 TiFlash 节点上执行，以实现实时监控并修改【注意，以下脚本务必在执行升级前先执行】：
function update_tiflash_script(){ # run_tiflash.sh 脚本所在路径【【【【【注意要根据实际情况修改此路径】】】】】】 scripts_path='/data/tidb-deploy/tiflash-9000/scripts' now=`date +%F%T | sed -r 's/-|://g'` # 备份原脚本 cp ${scripts_path}/run_tiflash.sh ${scripts_path}/run_tiflash.sh.${now} while [ 1 = 1 ]; do echo "正在监控‘${scripts_path}/run_tiflash.sh’文件，升级完成后请按“ctrl + c”停止本脚本" isExist=`cat ${scripts_path}/run_tiflash.sh | grep 'required_cpu_flags' | wc -l` if [ "${isExist}" != "0" ]; then isModifed=`cat ${scripts_path}/run_tiflash.sh | grep 'required_cpu_flags="avx"' | wc -l` if [ "${isModifed}" = "0" ]; then echo "Not found 'required_cpu_flags=\"avx\"', try modify..." # 先把原来的注释掉 sed -i 's/required_cpu_flags=/# required_cpu_flags=&/g' ${scripts_path}/run_tiflash.sh # 然后进行修改 sed -i '/# required_cpu_flags=/i\ required_cpu_flags="avx"' ${scripts_path}/run_tiflash.sh fi fi sleep 0.5 done}update_tiflash_script
复制代码
另外，此处修改虽然可以绕过因 TiFlash 升级失败而导致的整个集群升级失败的问题，但是成功升级集群后，TiFlash 仍然因为不支持 avx2 而启动失败。
参考：https://asktug.com/t/topic/1021704/22
3.1.4、Prometheus 问题
升级 v5.3 之前版本的集群到 v5.3 及后续版本时，默认部署的 Prometheus 会从 v2.8.1 升级到 v2.27.1，v2.27.1 提供更多的功能并解决了安全风险。Prometheus v2.27.1 相对于 v2.8.1 存在 Alert 时间格式变化，详情见 Prometheus commit。
3.2、开始升级
3.2.1、升级 TiUP 版本
tiup 版本不低于 1.11.3
tiup update --selftiup --version
复制代码
3.2.2、升级 TiUP Cluster 版本
tiup cluster 版本不低于 1.11.3
tiup update clustertiup cluster --version
复制代码
3.2.3、确保无 ddl 操作
mysql> admin show ddl;+------------+--------------------------------------+---------------------+--------------+--------------------------------------+-------+| SCHEMA_VER | OWNER_ID | OWNER_ADDRESS | RUNNING_JOBS | SELF_ID | QUERY |+------------+--------------------------------------+---------------------+--------------+--------------------------------------+-------+| 100 | cad28f9e-dcda-4782-8e14-c792604d4275 | 192.168.68.128:4000 | | cad28f9e-dcda-4782-8e14-c792604d4275 | |+------------+--------------------------------------+---------------------+--------------+--------------------------------------+-------+1 row in set (0.01 sec)
复制代码
注意：升级过程中勿进行 ddl 操作
3.2.4、确保无备份和还原操作
mysql> show backups;Empty set (0.00 sec)mysql> show restores;Empty set (0.00 sec)
复制代码
3.2.5、检查当前集群的健康状况
[root@localhost ~]# tiup cluster check tidb-test --clusterChecking updates for component cluster... Timedout (after 2s)+ Download necessary tools...... <此处忽略若干日志>Checking region status of the cluster tidb-test...All regions are healthy.[root@localhost ~]#
复制代码
执行结束后，最后会输出 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” 后再继续升级。
如果有错误，可以先尝试自动修复：
tiup cluster check tidb-test --cluster --apply
复制代码
3.2.6、升级 TiDB 集群
tiup cluster upgrade tidb-test v7.5.2
复制代码
此时需要重启各组件：
[root@localhost ~]# tiup cluster upgrade tidb-test v7.5.2Before the upgrade, it is recommended to read the upgrade guide at https://docs.pingcap.com/tidb/stable/upgrade-tidb-using-tiup and finish the preparation steps.This operation will upgrade tidb v5.3.0 cluster tidb-test to v7.5.2:will upgrade and restart component " tiflash" to "v7.5.2",will upgrade and restart component " cdc" to "v7.5.2",will upgrade and restart component " pd" to "v7.5.2",will upgrade and restart component " tikv" to "v7.5.2",will upgrade and restart component " pump" to "v7.5.2",will upgrade and restart component " tidb" to "v7.5.2",will upgrade and restart component " drainer" to "v7.5.2",will upgrade and restart component " prometheus" to "v7.5.2",will upgrade and restart component " grafana" to "v7.5.2",will upgrade component "node-exporter" to "",will upgrade component "blackbox-exporter" to "".Do you want to continue? [y/N]:(default=N) y
复制代码
3.2.7、升级 br
（1）升级前备份
开发环境升级前的 br 备份（即步骤 3.2.6 之前做备份）
[tidb@localhost ~]$ br backup full --pd "192.168.100.164:2379" -s "local:///nfs/full_20240701" --log-file backup_full.logDetail BR log in backup_full.logFull backup <---------------------------------------------------------------------------------------------------------------------\..............................................................................................> 55.57%{"level":"warn","ts":"2024-07-01T16:19:11.501+0800","caller":"clientv3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"endpoint://client-1a1b68b6-4fbb-423c-806b-a471b994fbad/192.168.100.164:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = context deadline exceeded"}Full backup <-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%Checksum <----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%[2024/07/01 16:37:57.134 +08:00] [INFO] [collector.go:65] ["Full backup success summary"] [total-ranges=8105] [ranges-succeed=8105] [ranges-failed=0] [backup-checksum=5m34.229454455s] [backup-fast-checksum=578.178902ms] [backup-total-ranges=12445] [total-take=30m12.00797445s] [BackupTS=450840825721257986] [total-kv=2812160710] [total-kv-size=221.7GB] [average-speed=122.3MB/s] [backup-data-size(after-compressed)=47.51GB] [Size=47506313613][tidb@localhost ~]$
复制代码
共耗时 30m12 秒，备份文件为 47.5G
（2）升级 br
# 下载地址：wget https://download.pingcap.org/tidb-community-toolkit-v7.5.2-linux-amd64.tar.gztar xvzf tidb-community-toolkit-v7.5.2-linux-amd64.tar.gzcd tidb-community-toolkit-v7.5.2-linux-amd64tar xvzf br-v7.5.2-linux-amd64.tar.gzcp br /usr/bin# 尝试备份su - tidbbr backup full --pd "192.168.100.164:2379" -s "local:///nfs/full_20240701_2" --log-file backup_full_2.log
复制代码
（3）升级 br 后备份
# backup.num-threads=2时[tidb@localhost ~]$ time br backup full --pd "192.168.100.164:2379" -s "local:///nfs/full_20240701_2" --log-file backup_full_2.logDetail BR log in backup_full_2.logFull Backup <----.................................................................................................................................................................................................................> 1.68%{"level":"warn","ts":"2024-07-01T20:02:02.873855+0800","logger":"etcd-client","caller":"v3@v3.5.10/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0001e6700/192.168.100.164:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = context deadline exceeded"}Full Backup <---/.................................................................................................................................................................................................................> 1.69%{"level":"warn","ts":"2024-07-01T20:19:33.890588+0800","logger":"etcd-client","caller":"v3@v3.5.10/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0001e6700/192.168.100.164:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = context deadline exceeded"}Full Backup <----\................................................................................................................................................................................................................> 1.98%Full Backup <----/................................................................................................................................................................................................................> 1.98%Full Backup <-----................................................................................................................................................................................................................> 1.98%Full Backup <----\................................................................................................................................................................................................................> 1.99%Full Backup <----|................................................................................................................................................................................................................> 1.99%Full Backup <---------------------------------------------\......................................................................................................................................................................> 21.39%{"level":"warn","ts":"2024-07-01T20:59:41.485154+0800","logger":"etcd-client","caller":"v3@v3.5.10/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0001e6700/192.168.100.164:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = context deadline exceeded"}Full Backup <-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%Checksum <----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%[2024/07/01 22:12:29.231 +08:00] [INFO] [collector.go:77] ["Full Backup success summary"] [total-ranges=8111] [ranges-succeed=8111] [ranges-failed=0] [backup-fast-checksum=1.012687562s] [backup-checksum=7m47.96059744s] [backup-total-ranges=12509] [total-take=2h12m22.072926235s] [BackupTS=450844481438089217] [total-kv=2812160811] [total-kv-size=221.7GB] [average-speed=27.91MB/s] [backup-data-size(after-compressed)=50.03GB] [Size=50026772216] real 132m31.496suser 1m27.695ssys 1m2.156s # backup.num-threads=4时[tidb@localhost ~]$ time br backup full --pd "192.168.100.164:2379" -s "local:///nfs/full_20240701_3" --log-file backup_full_3.logDetail BR log in backup_full_3.logFull Backup <-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%Checksum <----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%[2024/07/02 00:09:55.013 +08:00] [INFO] [collector.go:77] ["Full Backup success summary"] [total-ranges=8104] [ranges-succeed=8104] [ranges-failed=0] [backup-checksum=7m5.51865244s] [backup-fast-checksum=932.893636ms] [backup-total-ranges=12509] [total-take=40m7.219175349s] [backup-data-size(after-compressed)=50.03GB] [Size=50026756234] [BackupTS=450847779061760014] [total-kv=2812160813] [total-kv-size=221.7GB] [average-speed=92.09MB/s] real 40m7.655suser 0m46.710ssys 0m34.209s
复制代码
# 使用 ratelimit 参数时[tidb@localhost ~]$ time br backup full --pd "192.168.100.164:2379" -s "local:///nfs/full_20240701_4" --ratelimit 128 --log-file backup_full_4.logDetail BR log in backup_full_4.log[2024/07/02 00:11:52.901 +08:00] [WARN] [backup.go:312] ["setting `--ratelimit` and `--concurrency` at the same time, ignoring `--concurrency`: `--ratelimit` forces sequential (i.e. concurrency = 1) backup"] [ratelimit=134.2MB/s] [concurrency-specified=4]Full Backup <-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%Checksum <----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%[2024/07/02 01:28:02.552 +08:00] [INFO] [collector.go:77] ["Full Backup success summary"] [total-ranges=8104] [ranges-succeed=8104] [ranges-failed=0] [backup-checksum=7m9.190860539s] [backup-fast-checksum=1.025710248s] [backup-total-ranges=12509] [total-take=1h16m9.669375594s] [total-kv=2812160813] [total-kv-size=221.7GB] [average-speed=48.51MB/s] [backup-data-size(after-compressed)=50.03GB] [Size=50026756230] [BackupTS=450848440988729349] real 76m9.965suser 1m3.750ssys 0m49.402s
复制代码
（4）升级前后备份对比
3.3、报错处理
3.3.1、报错 1
Error: init config failed: 192.168.68.128:9093: transfer from /data/tidb-deploy/alertmanager-9093/conf/alertmanager.yml to /data/tidb-deploy/alertmanager-9093/conf/alertmanager.yml failed: failed to scp /data/tidb-deploy/alertmanager-9093/conf/alertmanager.yml to tidb@192.168.68.128:/data/tidb-deploy/alertmanager-9093/conf/alertmanager.yml: Process exited with status 1
复制代码
解决方法：先把通过缩容把 alertmanager 干掉，然后再升级
tiup cluster scale-in tidb-test --node 192.168.68.128:9093
复制代码
3.3.2、报错 2
Error: failed to get leader count 192.168.68.129: metric tikv_raftstore_region_count{type="leader"} not found
复制代码
先手工尝试能否获取这个信息：
[root@localhost ~]# curl -sl 192.168.68.129:20180/metrics | grep 'tikv_raftstore_region_count{type="leader"}'tikv_raftstore_region_count{type="leader"} 3
复制代码
有输出说明是可以获取的，此时在之前的基础上继续跑，需要先看跑到哪里：
[root@localhost ~]# tiup cluster auditID Time Command-- ---- -------gqmyWYvCwwx 2024-05-23T18:46:36+08:00 /root/.tiup/components/cluster/v1.15.1/tiup-cluster check ./topology.yamlgqmz0wgydxj 2024-05-23T18:47:39+08:00 /root/.tiup/components/cluster/v1.15.1/tiup-cluster check ./topology.yaml......grCGsxGpBfj 2024-06-26T17:48:19+08:00 /root/.tiup/components/cluster/v1.15.2/tiup-cluster display tidb-testgrCGG9LP9dp 2024-06-26T17:51:27+08:00 /root/.tiup/components/cluster/v1.15.2/tiup-cluster scale-in tidb-test --node 192.168.68.128:9093grCGT8Nzntq 2024-06-26T17:54:40+08:00 /root/.tiup/components/cluster/v1.15.2/tiup-cluster display tidb-testgrCGYsZn30J 2024-06-26T17:55:56+08:00 /root/.tiup/components/cluster/v1.15.2/tiup-cluster upgrade tidb-test v7.5.2grCHxJRwQ3s 2024-06-26T18:04:30+08:00 /root/.tiup/components/cluster/v1.15.2/tiup-cluster audit可以看到是执行到ID为 grCGYsZn30J 的地方，此时我们继续执行：[root@localhost ~]# tiup cluster replay grCGYsZn30JWill replay the command `tiup cluster upgrade tidb-test v7.5.2`Do you want to continue? [y/N]: (default=N) y......Upgraded cluster `tidb-test` successfully
复制代码
参考：https://docs.pingcap.com/zh/tidb/v7.5/upgrade-tidb-using-tiup#41-%E5%8D%87%E7%BA%A7%E6%97%B6%E6%8A%A5%E9%94%99%E4%B8%AD%E6%96%AD%E5%A4%84%E7%90%86%E5%AE%8C%E6%8A%A5%E9%94%99%E5%90%8E%E5%A6%82%E4%BD%95%E7%BB%A7%E7%BB%AD%E5%8D%87%E7%BA%A7
3.3.3、报错 3
[root@localhost ~]# tiup cluster upgrade tidb-test v7.5.2Before the upgrade, it is recommended to read the upgrade guide at https://docs.pingcap.com/tidb/stable/upgrade-tidb-using-tiup and finish the preparation steps.This operation will upgrade tidb v5.3.0 cluster tidb-test to v7.5.2:will upgrade and restart component " tiflash" to "v7.5.2",will upgrade and restart component " cdc" to "v7.5.2",will upgrade and restart component " pd" to "v7.5.2",will upgrade and restart component " tikv" to "v7.5.2",will upgrade and restart component " pump" to "v7.5.2",will upgrade and restart component " tidb" to "v7.5.2",will upgrade and restart component " drainer" to "v7.5.2",will upgrade and restart component " prometheus" to "v7.5.2",will upgrade and restart component " grafana" to "v7.5.2",will upgrade component "node-exporter" to "",will upgrade component "blackbox-exporter" to "".Do you want to continue? [y/N]:(default=N) yUpgrading cluster... ...... <此处忽略若干的日志> - Generate config blackbox_exporter -> 192.168.68.128 ... Done+ [ Serial ] - UpgradeClusterUpgrading component tiflash Restarting instance 192.168.68.132:9000 Error: failed to restart: 192.168.68.132 tiflash-9000.service, please check the instance's log(/data/tidb-deploy/tiflash-9000/log) for more detail.: timed out waiting for port 3930 to be started after 2m0s Verbose debug logs has been written to /root/.tiup/logs/tiup-cluster-debug-2024-06-28-21-40-11.log.[root@localhost ~]#
复制代码
经查 tiflash 日志，发现是不支持 avx2
重启集群后发现很多节点起不来
除 TiFlash 外 (由于不支持 avx2)，其他逐个节点起来后正常。
四、生产环境升级
4.1、确定升级方案
4.2、前期准备
(1)、系统架构检查，在 Linux AMD64 架构的硬件平台部署 TiFlash 时，CPU 必须支持 AVX2 指令集
# 在 Linux AMD64 架构的硬件平台部署 TiFlash 时，CPU 必须支持 AVX2 指令集，执行以下命令有输出：
cat /proc/cpuinfo | grep avx2
复制代码
# 在 Linux ARM64 架构的硬件平台部署 TiFlash 时，CPU 必须支持 ARMv8 架构，执行以下命令有输出：
cat /proc/cpuinfo | grep 'crc32' | grep 'asimd'
复制代码
(2)、TiDB 瘦身（清除过期的历史数据，减少重启 TiDB 时迁移 Leader 所消耗的时间）
(3)、重启 TiKV 以释放空间（此处由于 5.3.0 版本 TiKV 无法释放空间，需要重启才能释放空间）
(4)、重建 Prometheus（解决因共用 Prometheus，tiup 失去 Prometheus 控制权问题）
(5)、修改统计作业中 ddl 语句（此处由于升级期间，如果有 ddl 语句执行会导致升级失败）
(6)、取得所有授权语句并应用于新集群（链接附件为源码, 密码为 tidb）
(7)、给出新集群的各节点的 CPU、内存、磁盘信息（运维申请服务器）
(8)、编写升级后 ticdc 的 toml 文件（因原来的 maxwell 格式和新版本的 maxwell 格式不兼容，故需要重做 ticdc）
4.3、升级前准备
由于本次是跨大版本的升级，做好最坏打算的前期工作。提前准备一套备用集群，配置与生产环境相同，并且将生产环境的全量备份还原到备用集群上。
(1)、中午开启集群备份
(2)、申请新集群服务器
(3)、注释掉一切维护作业（包括归档、备份、统计信息处理）
(4)、新集群搭建
(5)、新集群 br 搭建在其中一台 pd 服务器上执行
(6)、新集群挂载 OSS（用于备份还原）
(7)、新集群全备还原
参考：有效性测试时，全备还原耗时 149 分钟
# br restore full --pd 新集群pd的ip:2379 -s local://备份路径 --log-file restorefull.log# 【【【注意要替换文件名】】】br restore full --pd host_ip:2379 -s local:///dbbak/tidbFullBak/mg_tidb_full_20240717130001 --log-file restorefull.log
复制代码
(8)、老集群做第一次增量备份
# 取得上一次备份的TS 【【【注意要修改备份文件夹】】】LAST_BACKUP_TS=`br validate decode --field="end-version" -s local:///dbbak/tidbFullBak/mg_tidb_full_20240717130001 | tail -n1`echo $LAST_BACKUP_TS# 开始增量备份br backup full\ --pd host_ip:2379 \ --ratelimit 128 \ -s local:///dbbak/tidbFullBak/mg_tidb_incr_20240717_1 \ --lastbackupts ${LAST_BACKUP_TS}
复制代码
(9)、新集群做第一次增量还原
注：如果第一次增量备份很快的话，可以不需做这次还原，而是真正升级前再基于全备做一次增量备份
br restore full --pd host_ip:2379 -s local:///dbbak/tidbFullBak/mg_tidb_incr_20240717_1 --log-file restoreincr.log
复制代码
4.4、升级集群及组件
4.4.1、回收所有 ddl 权限
4.4.2、再做一次增量备份
# 取得上一次备份的TS 【【【注意要修改备份文件夹】】】# 基于上次增量再做增量LAST_BACKUP_TS=`br validate decode --field="end-version" -s local:///dbbak/tidbFullBak/mg_tidb_incr_20240717_1 | tail -n1`echo $LAST_BACKUP_TS# 【以上1、2只选一个，视具体情况决定】# 开始增量备份br backup full\ --pd host_ip:2379 \ --ratelimit 128 \ -s local:///dbbak/tidbFullBak/mg_tidb_incr_20240717_2 \ --lastbackupts ${LAST_BACKUP_TS}
复制代码
4.4.3、升级集群
4.4.3.1、系统检查
(1)、停止包含有备份、还原、ddl 操作的所有定时作业
(2)、server-version 的值设置为空或者当前 TiDB 真实的版本值，避免出现非预期行为
mysql> show config where name like '%server-version%';+------+---------------------+----------------+-------+| Type | Instance | Name | Value |+------+---------------------+----------------+-------+| tidb | 192.168.68.129:4000 | server-version | || tidb | 192.168.68.128:4000 | server-version | |+------+---------------------+----------------+-------+2 rows in set, 1 warning (0.07 sec)
复制代码
4.4.3.2、升级 TiUP 版本
tiup 版本不低于 1.11.3
tiup update --selftiup --version
复制代码
4.4.3.3、升级 TiUP Cluster 版本
tiup cluster 版本不低于 1.11.3
tiup update clustertiup cluster --version
复制代码
4.4.3.4、确保无 ddl 操作
mysql> admin show ddl;+------------+--------------------------------------+---------------------+--------------+--------------------------------------+-------+| SCHEMA_VER | OWNER_ID | OWNER_ADDRESS | RUNNING_JOBS | SELF_ID | QUERY |+------------+--------------------------------------+---------------------+--------------+--------------------------------------+-------+| 100 | cad28f9e-dcda-4782-8e14-c792604d4275 | 192.168.68.128:4000 | | cad28f9e-dcda-4782-8e14-c792604d4275 | |+------------+--------------------------------------+---------------------+--------------+--------------------------------------+-------+1 row in set (0.01 sec)
复制代码
确保 RUNNG_JOBS 无值
注意：升级过程中勿进行 ddl 操作
4.4.3.5、确保无备份和还原操作
mysql> show backups;Empty set (0.00 sec)mysql> show restores;Empty set (0.00 sec)
复制代码
4.4.3.6、检查当前集群的健康状况
[root@localhost ~]# tiup cluster check mg-tidb --clusterChecking updates for component cluster... Timedout (after 2s)+ Download necessary tools．．．．．．Checking region status of the cluster tidb-test...All regions are healthy.[root@localhost ~]#
复制代码
执行结束后，最后会输出 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” 后再继续升级。
如果有错误，可以先尝试自动修复：
tiup cluster check mg-tidb --cluster --apply
复制代码
4.4.3.7、删除 ticdc 作业，并记录当前时间
当时时间为：xxxx:xxx:xxx
# 删除cdc: 表 xxx_cmdinfo（其它表依次类推）cdc cli changefeed remove --changefeed-id cmdinfo-kafka --pd=http://host_ip:2379,http://host_ip:2379,http://host_ip:2379 --force
复制代码
# 删除任务后会保留任务的同步状态信息 24 小时（主要用于记录同步的 checkpoint），24 小时内不能创建同名的任务。如果希望彻底删除任务信息，可以指定 –force 或 -f 参数删除，删除后 changefeed 的所有信息都会被清理，可以立即创建同名的 changefeed。
4.3.8、升级 TiDB 集群
tiup cluster upgrade mg-tidb v7.5.2
复制代码
需要重启各组件：
[root@localhost ~]# tiup cluster upgrade mg-tidb v7.5.2Before the upgrade, it is recommended to read the upgrade guide at https://docs.pingcap.com/tidb/stable/upgrade-tidb-using-tiup and finish the preparation steps.This operation will upgrade tidb v5.3.0 cluster tidb-test to v7.5.2:will upgrade and restart component " tiflash" to "v7.5.2",will upgrade and restart component " cdc" to "v7.5.2",will upgrade and restart component " pd" to "v7.5.2",will upgrade and restart component " tikv" to "v7.5.2",will upgrade and restart component " pump" to "v7.5.2",will upgrade and restart component " tidb" to "v7.5.2",will upgrade and restart component " drainer" to "v7.5.2",will upgrade and restart component " prometheus" to "v7.5.2",will upgrade and restart component " grafana" to "v7.5.2",will upgrade component "node-exporter" to "",will upgrade component "blackbox-exporter" to "".Do you want to continue? [y/N]:(default=N) y
复制代码
4.4、升级 ticdc
原 ticdc 为 maxwell 格式，输出到 kafka 时每条记录独立一行，升级到 v7.5.2 后，多条记录对应一行，因此需要重做 ticdc，并改为 canal-json 格式
4.4.1、升级 ticdc
# 查看 changefeed (V5.3.0的命令)，确认之前的 changefeed 已经删除tiup cdc cli changefeed list --pd=host_ip:2379# 输出为 [] 则表示全删除# 升级cdc到7.5.2版本tiup update cdc:v7.5.2# 查看 changefeed (V7.5.2的命令)，tiup cdc cli changefeed list --server=host_ip:8300
复制代码
4.4.2、创建 changefeed
# 重新创建ticdc-xxx_cmdinfo 表tiup cdc cli changefeed create \ --server=172.16.5.9:8300 \ --sink-uri="kafka://xxx.xxx.xxx.xxx:9092/ticdc_xxx_cmdinfo?protocol=canal-json&kafka-version=2.4.1&partition-num=6&max-message-bytes=67108864&replication-factor=1" \ --changefeed-id="xxx-cmdinfo-kafka" \ --config=xxx_cmdinfo.toml
复制代码
4.4.3、更新数据，追回升级过程中丢失的 ticdc 数据
取出 4.4.3.7、删除 ticdc 作业，并记录当前时间”记录的时间，并适当再往前调 10 分钟，然后对相关表在这个时间及之后的数据做一次更新（例如对一个无关重要的字段做更新，此处对 create_time 加 1 秒）
update xxx_cmdinfo set create_time = date_add(create_time, interval +1 second) where create_time > 'xxx:xx:xx';
复制代码
4.4.4、修改 kafka 的消费代码
由于 ticdc 写到 kafka 的格式也发现变化，因此需要修改相关的 kafka 消费代码，格式差异见“5.1、升级到 V7.5.2 版本后 ticdc 同步到 kafka 的 maxwell 格式 josn 记录异常”
4.5、升级 br
# 下载地址：
wget https://download.pingcap.org/tidb-community-toolkit-v7.5.2-linux-amd64.tar.gztar xvzf tidb-community-toolkit-v7.5.2-linux-amd64.tar.gzcd tidb-community-toolkit-v7.5.2-linux-amd64tar xvzf br-v7.5.2-linux-amd64.tar.gzcp br /usr/bin# 尝试备份# su - tidb# br backup full --pd "host_ip:2379" -s "local:///nfs/full_20240701_2" --log-file backup_full_2.log
复制代码
4.6、恢复回收的 ddl 权限
执行前面备份的权限，以恢复回收的 ddl 权限
五、升级期间遇到的问题
5.1、升级到 V7.5.2 版本后 ticdc 同步到 kafka 的 maxwell 格式 josn 记录异常
升级后，ticdc 同步到 kafka 的 maxwell 格式，从 kafka 消费下来，v5.3.0 是每条记录一行，v7.5.2 是多条记录一行，且一行内的的多条记录是没分隔符的。
要使消费下来，每条记录为一行，需要将升级后的 v7.5.2 的 ticdc 同步到 kafka 的输出格式改为 canal-json 格式，而 v5.3.0 是没有 canal-json 格式的。
==========insert==============# maxwell的insert格式(升级前){"database":"test","table":"t","type":"insert","ts":1637823163,"data":{"create_time":"2018-01-01 00:00:00","dept":1,"id":1,"last_login_time":"2018-03-01 12:00:00","name":"user_1"}}# json-canal的insert格式(升级后){"id":0,"database":"test","table":"t","pkNames":["id"],"isDdl":false,"type":"INSERT","es":1721044339113,"ts":1721044339899,"sql":"","sqlType":{"id":4,"dept":-6,"name":12,"create_time":93,"last_login_time":93},"mysqlType":{"dept":"tinyint","name":"varchar","create_time":"datetime","last_login_time":"datetime","id":"int"},"old":null,"data":[{"id":"1","dept":"1","name":"user_1","create_time":"2018-01-01 00:00:00","last_login_time":"2018-03-01 12:00:00"}]} ==========update==============# maxwell的update格式(升级前){"database":"test","table":"t","type":"update","ts":1637824161,"data":{"create_time":"2021-11-25 15:09:21","dept":1,"id":1,"last_login_time":"2018-03-01 12:00:00","name":"user_1"},"old":{"create_time":"2018-01-01 00:00:00"}}# json-canal的insert格式(升级后){"database": "test", "table": "t", "type": "update","ts":1637824161,"data": {"create_time":"2021-11-25 15:09:21","dept":1,"id":1,"last_login_time":"2018-03-01 12:00:00","name":"user_1"},"old":{"create_time":"2018-01-01 00:00:00"}} ==========delete==============# maxwell的delete格式(升级前){"database":"test","table":"t","type":"delete","ts":1637824320,"old":{"create_time":"2021-11-25 15:10:46","dept":1,"id":1,"last_login_time":"2018-03-01 12:00:00","name":"user_1"}}# maxwell的delete格式(升级后){"database": "test", "table": "t", "type": "delete","ts":1637824161,"data": {"create_time":"2021-11-25 15:09:21","dept":1,"id":1,"last_login_time":"2018-03-01 12:00:00","name":"user_1"},"old":{"create_time":"2018-01-01 00:00:00"}}
复制代码
解决方案：此处我们是开发修改消费 kafka 的代码进行解决。在升级前停止 TiCDC 同步，并且等待 kafka 内 topic 消费完，确定数据到最新值后，升级 TiDB 集群，升级后将新的消费代码上线。
参考：https://asktug.com/t/topic/1005840?replies_to_post_number=2
5.2、单个 PD 节点无法启动问题
通过 TiDB 社区老师的建议指导，阅读源码才得知，PD 的启动与环境变量有关。PD 节点启动前回先去获取环境变量是否有配置，后再启动节点。由于我们先前为了方便 DM 的使用，修改了环境变量导致，导致 PD 启动需要获取环境变量而导致的无法启动。
以下图一为服务器的环境变量、图二为 PD 的源码。
图一：
图二：
5.3、备份还原
新集群的搭建默认参数 new_collations_enabled_on_first_bootstrap 为 true，然而我们从 v5.3.0 版本升级为 v7.5.2 版本后参数 new_collations_enabled_on_first_bootstrap 为 false，参数不对应，备份还原不成功。
需要在新建集群的时候将 new_collations_enabled_on_first_bootstrap 设为 false 才能正确进行全量还原。（该参数只有在集群搭建的时候设置才有效）
六、升级后遗留的问题
目前我们 7.5.2 版本的 TiDB Dashboard 流量可视化有问题，某个表一旦产生流量后，后面即使没有读写操作都会一直显示有流量，这导致失去了利用流量可视化定位问题的核武器，目前还在寻找解决方法。
详情请参考 asktug：https://asktug.com/t/topic/1029492/1
七、总结
此次 TiDB 集群升级的历程，犹如一场充满挑战与收获的冒险。在这个过程中，我真切地领悟到了精心规划与充分准备所蕴含的巨大价值。与 TiDB 社区的互动交流及反馈，如同开启了一扇通往未来的窗户，让我看到了这款产品持续进步的无限可能。我坚信，在不断前行的道路上，TiDB 必将为用户呈上更为稳定、高效且易用的数据库解决方案。与此同时，我满心期待着在未来的日子里，能与社区携手并肩，共同探寻更多提升性能、降低成本的有效途径。
特别感谢下 @升级导师 - 军军、@升级导师 - 刘培梁、@表妹和群里各位大佬们的鼎力支持。
评论