从 v5.4 到 v6.5 的平滑过渡指南
引言
作为分布式数据库领域的明星产品，TiDB 的版本迭代速度一直保持着每半年一个稳定版本的节奏。本文将详细记录一次真实的 TiDB 集群从 v5.4 升级到 v6.5 的完整过程，涵盖升级前的风险评估、具体操作步骤、遇到的问题及解决方案，以及升级后的性能验证。
一、升级前的准备工作
1. 版本差异分析
首先需要详细阅读 TiDB 官方发布的 v6.5 Release Notes，重点关注以下内容：
- 兼容性变更：SQL语法、系统变量、配置参数的变化
- 新特性评估：如新增的
Column Pruning优化、Pipeline Engine等 - 废弃功能：确认无正在使用的废弃特性
2. 环境检查清单
bash
# 集群状态检查
tiup cluster display <cluster-name>
# 组件版本验证
tiup list tidb --version | grep v5.4
# 资源使用监控
watch -n 1 "tiup ctl:v5.4.0 pd -u http://${pd_ip}:2379 store"
3. 备份策略制定
采用双重备份方案：
-
逻辑备份：使用
dumpling工具全量导出bash dumpling -h ${tidb_ip} -P 4000 -u root -p ${password} \ -o /data/backup/ --filetype sql --filter '*.*' -
物理备份：通过
BR工具备份bash tiup br backup full --pd ${pd_ip}:2379 --storage "local:///data/br_backup"
二、升级实施过程
1. 分阶段升级策略
采用"PD → TiKV → TiDB → TiFlash"的顺序，每个组件升级间隔不少于30分钟。
阶段一：PD 升级
bash
tiup cluster upgrade <cluster-name> v6.5.0 --pd.tag=v6.5.0
遇到的问题：
- 升级后出现
etcd member health check failed错误 - 解决方案：检查PD节点间的网络延迟，发现某节点到其他节点的延迟超过100ms，调整网络配置后恢复
阶段二：TiKV 升级
bash
tiup cluster upgrade <cluster-name> v6.5.0 --tikv.tag=v6.5.0
关键操作：
- 升级前手动触发
Compact操作减少SST文件数量 - 监控
Store size和Region health指标
阶段三：TiDB 升级
bash
tiup cluster upgrade <cluster-name> v6.5.0 --tidb.tag=v6.5.0
配置变更：
toml
# config/tidb.toml 新增配置
[performance]
max-procs = 16
stmt-summary.enable = true
stmt-summary.refresh-interval = 1800
2. 灰度发布实践
选择业务低峰期，先升级1个TiDB节点作为灰度节点，验证：
- 连接池兼容性
- 慢查询日志格式变化
- 监控指标命名规范变更
三、升级后验证
1. 功能验证
SQL兼容性测试：
sql
-- 测试新特性：窗口函数支持
SELECT
department_id,
employee_name,
salary,
AVG(salary) OVER (PARTITION BY department_id) as avg_salary
FROM employees;
配置生效检查：
bash
tiup ctl:v6.5.0 tidb -u http://${tidb_ip}:10080 config show max-procs
2. 性能基准测试
使用sysbench进行对比测试：
| 指标 | v5.4 | v6.5 | 提升幅度 |
|---|---|---|---|
| QPS | 12,345 | 14,892 | +20.6% |
| 平均延迟(ms) | 8.1 | 6.7 | -17.3% |
| 99%延迟(ms) | 45 | 38 | -15.6% |
3. 监控指标对比
重点关注：
- TiKV：
grpc_message_count和raftstore_append_log_duration - PD：
schedule_operator_finish_count和region_heartbeat_report_count - TiDB：
query_duration和cop_process_duration
四、常见问题解决方案
1. 升级后连接失败
现象：应用日志报Connection refused错误
排查步骤：
- 检查TiDB服务状态：
systemctl status tidb-server - 验证端口监听：
netstat -tulnp | grep 4000 - 检查防火墙规则：
iptables -L -n
根本原因：v6.5默认启用了TLS加密，而客户端未配置证书
解决方案：
toml
# config/tidb.toml
[security]
ssl-ca = "/path/to/ca.pem"
ssl-cert = "/path/to/tidb.pem"
ssl-key = "/path/to/tidb-key.pem"
2. 监控数据中断
现象：Prometheus中TiDB指标出现断层
解决方案：
-
检查
node_exporter和blackbox_exporter服务状态 -
验证
pushgateway配置：yaml # prometheus.yml scrape_configs: - job_name: 'tidb' static_configs: - targets: ['pushgateway:9091'] -
重启相关服务：
systemctl restart prometheus
五、升级后优化建议
-
参数调优：
toml # config/tikv.toml [rocksdb] max-background-jobs = 8 [raftdb] max-background-jobs = 4 -
新特性启用：
sql -- 开启代价优化 SET GLOBAL tidb_enable_cost_based_optimizer = ON; -- 启用分区表动态裁剪 SET GLOBAL tidb_partition_prune_mode = 'dynamic'; -
慢查询优化：
sql -- 识别高频慢查询 SELECT query, count(*) as cnt FROM information_schema.slow_query GROUP BY query ORDER BY cnt DESC LIMIT 10;
总结
本次升级从v5.4到v6.5共耗时3小时15分钟，期间业务无感知，升级后系统稳定性提升明显，QPS提升20%以上。关键经验包括：
- 严格遵循官方升级文档，不跳过任何验证步骤
- 采用分阶段灰度升级策略
- 提前准备回滚方案（保留旧版本二进制文件）
- 升级后进行全面性能基准测试
TiDB的滚动升级特性极大降低了升级风险，但充分的准备和验证仍然是成功的关键。建议每季度进行一次小版本升级，每年进行一次大版本升级，以持续获得性能优化和新特性。