一、背景
当前TiDB集群版本为：v6.1.2
结合信创需求和稳定性考虑，计划将TiDB集群升级为：v7.1.8-5.4
二、集群信息
集群名称 |
集群版本 |
目标版本 |
升级方式 |
备注 |
|
|---|---|---|---|---|---|
tidb-prod |
v6.1.2 |
v7.1.8-5.4 |
原地升级+备库回滚 |
三、升级计划
3.1 TiDB 升级步骤
环境升级采用原地升级+备库的方式进行，如遇问题可直接切换至备库进行业务操作。
-
搭建备用集群（使用TiCDC进行搭建，版本为：v6.1.2）
-
对旧环境数据进行备份操作（使用Dumpling进行备份，备份版本为：v6.1.2）
-
停止主备同步，记录TSO（防止升级后同步异常）
-
采用原地升级方式升级旧主集群
-
采用原地升级方式升级旧备集群
-
业务切换，对新集群进行业务验证，保证数据库正常使用
- 数据库正常使用，升级完成
- 数据库存在问题，业务切换至备用集群
四、升级环境检查以及操作步骤
4.1 集群健康检查
对集群进行一次整体巡检，确保集群在健康状态下进行升级，重点关注如下：
-
集群实例是否正常运行
- Grafana --> Overview --> Services Port Status
-
Region状态正常，分布均匀
- Grafana --> PD --> Region Healthy
- Grafana --> PD --> Region Label isolation level
- Grafana --> PD --> Balance
-
集群资源使用正常
- Grafana --> TiDB --> Server --> CPU Usage
- Grafana --> TiKV-Details --> Cluster --> CPU
- Grafana --> PD --> Cluster --> CPU Usage
-
集群GC推进正常
- Grafana --> TiKV-Details --> GC --> TiKV Auto GC SafePoint
4.2 server-version检查
升级前检查TiDB version，需要确认server-version是否设置为空或者当前TiDB的真实版本，避免出现非预期行为
SHOW CONFIG WHERE NAME LIKE "%server-version%";
4.3 SPM兼容性检查
升级前将配置的SPM在新版本执行一遍，保证不存在兼容性问题，避免升级过程中出现预期外行为
select concat('explain ',bind_sql,';') from mysql.bind_info where original_sql<>'builtin_pseudo_sql_for_bind_lock';
4.4 DDL检查
- 在升级 TiDB 集群的过程中，请勿执行 DDL 语句，否则可能会出现行为未定义的问题。
- 集群中有 DDL 语句正在被执行时（通常为 ADD INDEX 和列类型变更等耗时较久的 DDL 语句），请勿进行升级操作。在升级前，建议使用 ADMIN SHOW DDL 命令查看集群中是否有正在进行的 DDL Job。如需升级，请等待 DDL 执行完成或使用 ADMIN CANCEL DDL 命令取消该 DDL Job 后再进行升级。
提前检查DDL History 并与业务人员确认
ADMIN SHOW DDL JOBS 100;
4.5 PD leader_priority检查
如果集群设置了 PD leader_priority ，可能因为滚动升级 PD 过程中，出现 evicting PD leader timeout 而导致升级中断，建议在升级前将所有 member leader_priority 调整为与当前 PD Leader 一致，待升级全部完成后再恢复原先的设置。
# 查看 PD 实例的 member name 和优先级设置
pd-ctl member | grep -E 'name|leader_priority'
# 调整 PD 实例的优先级设置
pd-ctl member leader_priority <member_name> <priority>
4.6 TiCDC 同步链路检查（主集群和备集群的同步链路）
查看集群TiCDC同步延迟，确保升级前无延迟情况，防止若需切换备库数据对不上
tiup cdc cli changefeed query -s --pd=http://xxx:2379 --changefeed-id=slave-task
4.7 参数备份
建议提前备份集群 Confiig & Variables
tiup cluster show-config tidb-prod >> config_bak.txt
mysql -h127.0.0.1 -p4000 -u root -p'xx' -Bse"show global variables;" | sort > variable_bak.txt
4.8 关闭原主备同步Binlog任务并记录TSO
tiup cluster stop tidb-prod -R drainer
#连接进入备库进行查询
select * from tidb_binlog.checkpoint;
select tidb_parse_tso(xxxx);
4.8 合并镜像
# 查看当前镜像目录
tiup mirror show
# 解压 v7.1.8-5.4 离线安装包（解压到当前镜像的上一级目录）
tar -zxvf tidb-server-v7.1.8-5.4-linux-amd64.tar.gz
tar -zxvf tidb-toolkit-v7.1.8-5.4-linux-amd64.tar.gz
# 拷贝私钥
cd {当前镜像目录}
cp -rp keys ~/.tiup/
# 合并镜像
tiup mirror merge ../tidb-server-v7.1.8-5.4-linux-amd64
tiup mirror merge ../tidb-toolkit-v7.1.8-5.4-linux-amd64
# 升级 TiUP
tiup update --self
4.9 升级集群
升级时间估算：总分钟数= tidb 节点数*5 +tikv 节点数*5 +tiflash 节点数*4 +ticdc 节点数*5
升级期间业务影响：
TiDB：滚动重启时，当前实例上的应用连接会断开，如果应用没有重连机制，升级完成后需要重启应用；
PD：切换 PD Leader 期间会导致集群短时间不可用（预期不超过 1min）；
TiKV：升级 TiKV 期间，会逐个将 TiKV 上的所有 leader 切走再停止该 TiKV 实例。默认超时时间为 5 分钟（300 秒），超时后会直接停止该实例；如果希望保持性能稳定，则需要保证 TiKV 上的所有 leader 驱逐完成后再停止该 TiKV 实例，可以指定 --transfer-timeout 为一个更大的值，如 --transfer-timeout 3600，单位为秒。
tiup cluster upgrade tidb-prod v7.1.8-5.4 --transfer-timeout 3600
4.10 升级后检查
- 确认各个实例版本是否符合预期
SELECT * FROM INFORMATION_SCHEMA.CLUSTER_INFO;
4.11 升级灾备集群
其他步骤参考4.8 - 4.10操作
tiup cluster upgrade tidb_bak v7.1.8-5.4 --transfer-timeout 3600
4.12 搭建新的主备同步链路（使用TiCDC进行搭建）
# 扩容TiCDC
vi cdc_out.yaml
cdc_servers:
- host: 10.0.x.xx
gc-ttl: 86400
data_dir: "/cdc-data"
tiup cluster scale-out tidb-prod ./cdc_out.yaml
# 创建CDC同步任务
tiup cdc cli changefeed create \
--server=http://10.0.x.xx:8300 \
--sink-uri="mysql://root:xxx@xxxx:xxx/" \
--changefeed-id="slave-task"