外观
TiDB 升级准备
TiDB 升级是一项重要的运维操作，需要充分的准备工作以确保升级过程顺利进行，避免对业务造成影响。本文将详细介绍 TiDB 升级前的准备工作，包括升级前检查、升级计划制定、环境准备、数据备份和升级前测试等。
升级准备的重要性
- 降低风险：充分的准备工作可以降低升级风险，避免升级过程中出现意外情况
- 减少 downtime：合理的准备可以减少升级对业务的影响，缩短 downtime
- 确保回滚：准备充分的回滚方案，确保在升级失败时能够快速恢复
- 提高成功率：详细的计划和准备可以提高升级成功率
升级前检查
1. 集群状态检查
bash
# 检查集群状态
tiup cluster display <cluster-name>
# 检查集群健康状态
tiup cluster check <cluster-name> --cluster
# 检查节点状态
tiup cluster check <cluster-name> --node <node-ip:port>2. 版本兼容性检查
bash
# 查看当前集群版本
tiup cluster display <cluster-name> | grep Version
# 检查目标版本与当前版本的兼容性
# 参考官方文档：https://docs.pingcap.com/zh/tidb/stable/upgrade-tidb-using-tiup3. 组件状态检查
bash
# 检查 TiDB 状态
mysql -h <tidb-host> -P 4000 -u root -e "SELECT VERSION();"
# 检查 TiKV 状态
tiup ctl tikv --host <tikv-host>:20160 status
# 检查 PD 状态
tiup ctl pd -u http://<pd-host>:2379 status4. 数据一致性检查
bash
# 检查 Region 健康状态
tiup ctl pd -u http://<pd-host>:2379 region check
# 检查 TiKV 副本状态
tiup ctl pd -u http://<pd-host>:2379 store5. 资源使用检查
bash
# 检查 CPU 使用率
top
# 检查内存使用率
free -h
# 检查磁盘空间
df -h
# 检查网络状态
netstat -tuln升级计划制定
1. 升级时间选择
- 业务低峰期：选择业务低峰期进行升级，减少对业务的影响
- 预留足够时间：预留足够的时间进行升级，包括升级过程和验证时间
- 避免关键业务时段：避免在关键业务时段进行升级，如财务结算、促销活动等
2. 升级方式选择
| 升级方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 滚动升级 | 生产环境 | 影响小，无需停机 | 升级时间较长 |
| 蓝绿部署 | 对 downtime 要求高的场景 | 零 downtime，快速回滚 | 资源消耗大 |
| 灰度升级 | 大规模集群 | 逐步升级，风险可控 | 升级过程复杂 |
3. 升级步骤规划
1. 升级前准备
- 检查集群状态
- 备份数据
- 准备升级环境
2. 升级 PD 组件
- 升级 PD Leader
- 升级其他 PD 节点
3. 升级 TiKV 组件
- 逐个升级 TiKV 节点
- 等待每个节点升级完成并稳定
4. 升级 TiDB 组件
- 逐个升级 TiDB 节点
- 验证 TiDB 服务可用性
5. 升级其他组件
- 升级 TiFlash 组件
- 升级 TiCDC 组件
- 升级监控组件
6. 升级后验证
- 检查集群状态
- 验证业务功能
- 检查性能指标4. 回滚计划制定
- 回滚触发条件：定义回滚触发条件，如升级失败、业务异常等
- 回滚步骤：详细的回滚步骤，包括组件回滚顺序和命令
- 回滚时间：预计回滚所需时间
- 回滚验证：回滚后的验证步骤
环境准备
1. TiUP 环境准备
bash
# 更新 TiUP
tiup update --self
tiup update --all
# 检查 TiUP 版本
tiup --version2. 升级包准备
bash
# 查看可用版本
tiup list tidb
# 下载指定版本（可选）
tiup mirror clone <version> /path/to/mirror3. 测试环境准备
- 搭建测试环境：在测试环境中模拟升级过程
- 数据同步：将生产环境数据同步到测试环境
- 测试升级：在测试环境中进行升级测试
4. 监控环境准备
- 升级监控组件：确保监控组件支持目标 TiDB 版本
- 配置告警：设置升级过程中的告警规则
- 准备监控仪表盘：准备升级过程中需要关注的监控仪表盘
数据备份
1. 全量备份
bash
# 使用 BR 工具进行全量备份
tiup br backup full --pd <pd-host>:2379 --storage "s3://<bucket-name>/<backup-path>" --send-credentials-to-tikv
# 或备份到本地
mkdir -p /path/to/backup
tiup br backup full --pd <pd-host>:2379 --storage "local:///path/to/backup"2. 增量备份
bash
# 查看当前 TSO
tiup ctl pd -u http://<pd-host>:2379 tso now
# 记录当前 TSO，用于增量备份起始点3. 关键数据备份
- 元数据备份：备份集群元数据
- 配置文件备份：备份所有组件的配置文件
- 监控配置备份：备份监控组件的配置
bash
# 备份配置文件
tiup cluster edit-config <cluster-name> > /path/to/config-backup.yaml
# 备份 PD 元数据
tiup ctl pd -u http://<pd-host>:2379 config save > /path/to/pd-config-backup.json升级前测试
1. 兼容性测试
- SQL 兼容性：测试业务 SQL 在新版本中的兼容性
- 驱动兼容性：测试应用程序驱动与新版本的兼容性
- 工具兼容性：测试第三方工具与新版本的兼容性
2. 性能测试
- 基准测试：在测试环境中进行基准测试，对比升级前后的性能
- 压力测试：模拟业务压力，测试升级后的性能表现
- 稳定性测试：长时间运行测试，确保升级后集群稳定
3. 功能测试
- 核心功能测试：测试集群的核心功能是否正常
- 新功能测试：测试新版本的新功能
- 边缘场景测试：测试边缘场景下的功能表现
升级准备清单
1. 集群状态清单
- [ ] 集群所有节点状态正常
- [ ] 所有 Region 状态正常
- [ ] 没有异常告警
- [ ] 资源使用率在正常范围
2. 升级计划清单
- [ ] 确定升级时间窗口
- [ ] 选择合适的升级方式
- [ ] 制定详细的升级步骤
- [ ] 制定回滚计划
- [ ] 明确升级负责人和分工
3. 环境准备清单
- [ ] 更新 TiUP 到最新版本
- [ ] 准备升级包
- [ ] 搭建测试环境
- [ ] 准备监控环境
4. 数据备份清单
- [ ] 完成全量备份
- [ ] 记录增量备份起始点
- [ ] 备份配置文件
- [ ] 备份元数据
5. 测试清单
- [ ] 完成兼容性测试
- [ ] 完成性能测试
- [ ] 完成功能测试
- [ ] 测试回滚流程
常见问题（FAQ）
Q1: 升级前需要停止业务吗？
A1: 对于滚动升级，不需要完全停止业务，但建议在升级过程中减少写入操作，避免对升级过程造成影响。对于蓝绿部署，可以实现零 downtime 升级。
Q2: 升级需要多长时间？
A2: 升级时间取决于集群规模和升级方式：
- 滚动升级：根据节点数量，每个节点升级时间约为 5-10 分钟
- 蓝绿部署：主要取决于数据同步时间
- 灰度升级：时间较长，取决于灰度策略
Q3: 升级失败后如何回滚？
A3: 回滚步骤：
- 停止升级过程
- 按照与升级相反的顺序回滚每个组件
- 恢复备份数据（如果需要）
- 验证集群状态和业务功能
Q4: 升级前需要备份所有数据吗？
A4: 是的，升级前必须进行全量备份，确保在升级失败时能够恢复数据。对于重要业务，建议同时备份配置文件和元数据。
Q5: 如何选择合适的升级方式？
A5: 选择升级方式的建议：
- 生产环境优先选择滚动升级
- 对 downtime 要求高的场景选择蓝绿部署
- 大规模集群选择灰度升级
- 测试环境可以选择快速升级
Q6: 升级前需要检查哪些关键指标？
A6: 升级前需要检查的关键指标：
- 集群状态：所有节点状态正常
- Region 状态：所有 Region 状态正常
- 资源使用率：CPU、内存、磁盘使用率在正常范围
- 性能指标：QPS、TPS、延迟等正常
- 告警状态：没有未处理的严重告警
通过充分的升级准备，可以降低 TiDB 升级风险，确保升级过程顺利进行，减少对业务的影响。升级准备工作越充分，升级成功率越高，回滚风险越小。