本文档风哥主要介绍TiDB滚动升级的实战全流程，包括滚动升级的概念、原理、优势、升级前准备、滚动升级计划、注意事项、升级步骤、监控、验证、实战案例、故障处理和性能影响等内容，风哥教程参考TiDB官方文档滚动升级相关内容编写，适合DBA人员在学习和测试中使用，如果要应用于生产环境则需要自行确认。更多视频教程www.fgedu.net.cn
Part01-基础概念与理论知识
1.1 滚动升级的概念
滚动升级是指在不中断服务的情况下，逐个升级TiDB集群中的各个组件，从而实现集群版本的平滑升级：学习交流加群风哥微信: itpux-com
- 逐个升级：按照一定的顺序，逐个升级集群中的节点，而不是同时升级所有节点
- 服务不中断：在升级过程中，集群仍然保持服务可用，业务不受影响
- 平滑过渡：升级过程中，集群的状态逐渐从旧版本过渡到新版本
1.2 滚动升级的原理
滚动升级的原理是利用TiDB集群的高可用性特性，在升级过程中保持集群的服务可用：
## 1. 集群高可用性
– TiDB集群由多个节点组成，包括PD、TiKV和TiDB节点
– 每个组件都有多个副本，确保单点故障不会影响整个集群
– 升级过程中，只升级部分节点，其他节点仍然正常工作
## 2. 升级顺序
– 按照PD → TiKV → TiDB的顺序进行升级
– 先升级非Leader节点，再升级Leader节点
– 确保每个组件在升级过程中始终有可用节点
## 3. 服务负载均衡
– 在升级过程中，负载均衡器会将流量引导到可用的节点
– 确保业务请求始终能够被处理
– 避免升级中的节点接收新的请求
## 4. 数据一致性
– 升级过程中，集群会保持数据一致性
– 使用Raft协议确保数据的复制和同步
– 确保升级前后数据不丢失
1.3 滚动升级的优势
滚动升级相比传统的停机升级具有以下优势：
## 1. 服务不中断
– 升级过程中业务继续运行，不需要停机
– 避免了因升级导致的业务中断
– 适合对可用性要求高的生产环境
## 2. 风险可控
– 逐个节点升级，出现问题时影响范围小风哥提示：
– 可以及时发现和解决问题
– 必要时可以回滚单个节点
## 3. 平滑过渡
– 升级过程平滑，不会对业务造成冲击
– 系统性能不会出现明显波动
– 用户体验不受影响
## 4. 灵活性高
– 可以在业务低峰期进行升级
– 可以根据实际情况调整升级速度
– 支持不同版本之间的滚动升级
Part02-生产环境规划与建议
2.1 升级前准备
滚动升级前的准备工作：
## 1. 备份数据
– 使用BR工具备份全量数据：
br backup full –pd “192.168.1.10:2379” –storage “local:///tidb/backup”
– 备份配置文件：
cp -r /tidb/app/pd/conf /tidb/backup/pd_conf
cp -r /tidb/app/tikv/conf /tidb/backup/tikv_conf
cp -r /tidb/app/tidb/conf /tidb/backup/tidb_conf
## 2. 检查集群状态
– 检查PD状态：
pd-ctl -u http://192.168.1.10:2379 status
– 检查TiKV状态：
tikv-ctl status –host 192.168.1.20:20160
– 检查TiDB状态：
mysql -h 192.168.1.10 -P 4000 -u root -e “SHOW STATUS LIKE ‘tidb_version’;”
## 3. 检查系统资源
– 检查磁盘空间：
df -h
– 检查内存使用：
free -h
– 检查CPU负载：
top
## 4. 准备升级包
– 下载目标版本的安装包：
wget https://download.pingcap.org/tidb-6.1.1-linux-amd64.tar.gz
– 解压安装包：
tar -xzf tidb-6.1.1-linux-amd64.tar.gz
– 验证安装包完整性：
sha256sum tidb-6.1.1-linux-amd64.tar.gz
## 5. 制定升级计划
– 确定升级时间窗口：选择业务低峰期
– 制定升级顺序：PD → TiKV → TiDB
– 分配升级任务：明确各节点的升级顺序和负责人
– 准备回滚方案：出现问题时的应急措施
## 6. 通知相关人员
– 通知业务方：升级时间和可能的影响
– 通知运维团队：升级计划和注意事项
– 通知开发团队：可能的兼容性问题
2.2 滚动升级计划
滚动升级的详细计划：
## 1. 升级顺序
– **PD集群**：先升级非Leader节点，再升级Leader节点
– **TiKV集群**：按照负载顺序升级，先升级负载较低的节点
– **TiDB集群**：按照负载顺序升级，先升级负载较低的节点
– **其他组件**：最后升级监控、TiFlash、TiCDC等组件
## 2. 升级时间预估
– **PD节点**：每个节点约5-10分钟
– **TiKV节点**：每个节点约10-15分钟
– **TiDB节点**：每个节点约5-10分钟
– **监控组件**：约5分钟
– **总时间**：根据集群规模而定，一般为1-3小时
## 3. 升级步骤
– **PD升级**：停止服务 → 替换二进制文件 → 启动服务 → 验证状态
– **TiKV升级**：停止服务 → 替换二进制文件 → 启动服务 → 验证状态
– **TiDB升级**：停止服务 → 替换二进制文件 → 启动服务 → 验证状态
– **监控升级**：停止服务 → 替换二进制文件 → 启动服务 → 验证状态
## 4. 监控计划
– **升级前**：记录当前监控指标作为基准
– **升级中**：实时监控集群状态和性能指标
– **升级后**：验证监控指标是否正常
– **异常处理**：设置监控告警，及时发现和处理异常学习交流加群风哥QQ113257174
2.3 滚动升级注意事项
滚动升级过程中的注意事项：
## 1. 版本兼容性
– 确保目标版本与当前版本兼容
– 查看官方文档中的版本兼容性说明
– 避免跨多个主版本的升级
## 2. 集群状态
– 升级前确保集群状态正常
– 确保所有节点都处于健康状态
– 避免在集群有故障时进行升级
## 3. 网络连接
– 确保网络连接稳定
– 避免在网络不稳定时进行升级
– 确保升级过程中网络不会中断
## 4. 资源使用
– 确保升级过程中有足够的系统资源
– 避免在系统负载过高时进行升级
– 预留足够的磁盘空间用于升级
## 5. 业务影响
– 选择业务低峰期进行升级
– 提前通知业务方可能的影响
– 准备应急方案，应对可能的业务异常
## 6. 回滚计划
– 制定详细的回滚计划
– 确保在升级失败时能够快速回滚
– 测试回滚流程，确保回滚操作有效
Part03-生产环境项目实施方案
3.1 滚动升级步骤
3.1.1 PD集群滚动升级
## 1. 检查PD集群状态
$ pd-ctl -u http://192.168.1.10:2379 status
# 输出示例
{
“header”: {
“cluster_id”: 1234567890
},
“pd”: {
“id”: 1,
“name”: “pd-1”,
“client_urls”: “http://192.168.1.10:2379”,
“peer_urls”: “http://192.168.1.10:2380”,
“version”: “6.1.0”
},
“members”: [
{
“id”: 1,
“name”: “pd-1”,
“client_urls”: “http://192.168.1.10:2379”,
“peer_urls”: “http://192.168.1.10:2380”
},
{
“id”: 2,
“name”: “pd-2”,
“client_urls”: “http://192.168.1.11:2379”,
“peer_urls”: “http://192.168.1.11:2380”
},
{
“id”: 3,
“name”: “pd-3”,
“client_urls”: “http://192.168.1.12:2379”,
“peer_urls”: “http://192.168.1.12:2380”
}
],
“leader”: {
“id”: 1,
“name”: “pd-1”,
“client_urls”: “http://192.168.1.10:2379”,
“peer_urls”: “http://192.168.1.10:2380”
}
}
## 2. 升级非Leader PD节点（pd-2）
### 2.1 停止PD服务
$ systemctl stop pd@2
### 2.2 替换PD二进制文件
$ cp /tidb/upgrade/tidb-6.1.1-linux-amd64/pd-server /tidb/app/pd/bin/
### 2.3 启动PD服务
$ systemctl start pd@2
### 2.4 验证PD状态
$ pd-ctl -u http://192.168.1.11:2379 status
# 输出示例
{
“header”: {
“cluster_id”: 1234567890
},
“pd”: {
“id”: 2,
“name”: “pd-2”,
“client_urls”: “http://192.168.1.11:2379”,
“peer_urls”: “http://192.168.1.11:2380”,
“version”: “6.1.1”
}
}
## 3. 升级非Leader PD节点（pd-3）
### 3.1 停止PD服务
$ systemctl stop pd@3
### 3.2 替换PD二进制文件
$ cp /tidb/upgrade/tidb-6.1.1-linux-amd64/pd-server /tidb/app/pd/bin/
### 3.3 启动PD服务
$ systemctl start pd@3
### 3.4 验证PD状态
$ pd-ctl -u http://192.168.1.12:2379 status
# 输出示例
{
“header”: {
“cluster_id”: 1234567890
},
“pd”: {
“id”: 3,
“name”: “pd-3”,
“client_urls”: “http://192.168.1.12:2379”,
“peer_urls”: “http://192.168.1.12:2380”,
“version”: “6.1.1”
}
}
## 4. 升级Leader PD节点（pd-1）
### 4.1 停止PD服务
$ systemctl stop pd@1
### 4.2 替换PD二进制文件
$ cp /tidb/upgrade/tidb-6.1.1-linux-amd64/pd-server /tidb/app/pd/bin/
### 4.3 启动PD服务
$ systemctl start pd@1
### 4.4 验证PD状态
$ pd-ctl -u http://192.168.1.10:2379 status
# 输出示例
{
“header”: {
“cluster_id”: 1234567890
},
“pd”: {
“id”: 1,
“name”: “pd-1”,
“client_urls”: “http://192.168.1.10:2379”,
“peer_urls”: “http://192.168.1.10:2380”,
“version”: “6.1.1”
}
}
## 5. 验证PD集群状态
$ pd-ctl -u http://192.168.1.10:2379 status
# 输出示例
{
“header”: {
“cluster_id”: 1234567890
},
“members”: [
{
“id”: 1,
“name”: “pd-1”,
“client_urls”: “http://192.168.1.10:2379”,
“peer_urls”: “http://192.168.1.10:2380”,
“version”: “6.1.1”
},
{
“id”: 2,
“name”: “pd-2”,
“client_urls”: “http://192.168.1.11:2379”,
“peer_urls”: “http://192.168.1.11:2380”,
“version”: “6.1.1”
},
{
“id”: 3,
“name”: “pd-3”,
“client_urls”: “http://192.168.1.12:2379”,
“peer_urls”: “http://192.168.1.12:2380”,
“version”: “6.1.1”
}
],
“leader”: {
“id”: 1,
“name”: “pd-1”,
“client_urls”: “http://192.168.1.10:2379”,
“peer_urls”: “http://192.168.1.10:2380”
}
}
3.1.2 TiKV集群滚动升级
## 1. 检查TiKV集群状态
$ pd-ctl -u http://192.168.1.10:2379 store
# 输出示例
{
“count”: 3,
“stores”: [
{
“store”: {
“id”: 1,
“address”: “192.168.1.20:20160”,
“state”: 0,
“version”: “6.1.0”,
“leader_count”: 100,
“region_count”: 1000
}
},
{
“store”: {
“id”: 2,
“address”: “192.168.1.21:20160”,
“state”: 0,
“version”: “6.1.0”,
“leader_count”: 95,
“region_count”: 998
}
},
{
“store”: {
“id”: 3,
“address”: “192.168.1.22:20160”,
“state”: 0,
“version”: “6.1.0”,
“leader_count”: 98,
“region_count”: 1002
}
}
]
}
## 2. 升级TiKV节点（store 2）
### 2.1 停止TiKV服务
$ systemctl stop tikv@2
### 2.2 替换TiKV二进制文件
$ cp /tidb/upgrade/tidb-6.1.1-linux-amd64/tikv-server /tidb/app/tikv/bin/
### 2.3 启动TiKV服务
$ systemctl start tikv@2
### 2.4 验证TiKV状态
$ tikv-ctl status –host 192.168.1.21:20160
# 输出示例
{
“server”: {
“version”: “6.1.1”,
“git_hash”: “abcdef1234567890”,
“start_timestamp”: 1620000000,
“uptime”: “10m”
},
“store”: {
“id”: 2,
“state”: “Up”,
“capacity”: “100GB”,
“available”: “80GB”,
“leader_count”: 95,
“region_count”: 998
}
}
## 3. 升级TiKV节点（store 3）
### 3.1 停止TiKV服务
$ systemctl stop tikv@3
### 3.2 替换TiKV二进制文件
$ cp /tidb/upgrade/tidb-6.1.1-linux-amd64/tikv-server /tidb/app/tikv/bin/
### 3.3 启动TiKV服务
$ systemctl start tikv@3
### 3.4 验证TiKV状态
$ tikv-ctl status –host 192.168.1.22:20160
# 输出示例
{
“server”: {
“version”: “6.1.1”,
“git_hash”: “abcdef1234567890”,
“start_timestamp”: 1620000000,
“uptime”: “10m”
},
“store”: {
“id”: 3,
“state”: “Up”,
“capacity”: “100GB”,
“available”: “80GB”,
“leader_count”: 98,
“region_count”: 1002
}
}
## 4. 升级TiKV节点（store 1）
### 4.1 停止TiKV服务
$ systemctl stop tikv@1
### 4.2 替换TiKV二进制文件
$ cp /tidb/upgrade/tidb-6.1.1-linux-amd64/tikv-server /tidb/app/tikv/bin/
### 4.3 启动TiKV服务
$ systemctl start tikv@1
### 4.4 验证TiKV状态
$ tikv-ctl status –host 192.168.1.20:20160
# 输出示例
{
“server”: {
“version”: “6.1.1”,
“git_hash”: “abcdef1234567890”,
“start_timestamp”: 1620000000,
“uptime”: “10m”
},
“store”: {
“id”: 1,
“state”: “Up”,
“capacity”: “100GB”,
“available”: “80GB”,
“leader_count”: 100,
“region_count”: 1000
}
}
## 5. 验证TiKV集群状态
$ pd-ctl -u http://192.168.1.10:2379 store
# 输出示例
{
“count”: 3,
“stores”: [
{
“store”: {
“id”: 1,
“address”: “192.168.1.20:20160”,
“state”: 0,
“version”: “6.1.1”,
“leader_count”: 100,
“region_count”: 1000
}
},
{
“store”: {
“id”: 2,
“address”: “192.168.1.21:20160”,
“state”: 0,
“version”: “6.1.1”,
“leader_count”: 95,
“region_count”: 998
}
},
{
“store”: {
“id”: 3,
“address”: “192.168.1.22:20160”,
“state”: 0,
“version”: “6.1.1”,
“leader_count”: 98,
“region_count”: 1002
}
}
]
}
3.1.3 TiDB集群滚动升级
## 1. 检查TiDB集群状态
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SHOW STATUS LIKE ‘tidb_version’;”
# 输出示例
+—————+——–+
| Variable_name | Value |
+—————+——–+
| tidb_version | 6.1.0 |
+—————+——–+
## 2. 升级TiDB节点（tidb-2）
### 2.1 停止TiDB服务
$ systemctl stop tidb@2
### 2.2 替换TiDB二进制文件
$ cp /tidb/upgrade/tidb-6.1.1-linux-amd64/tidb-server /tidb/app/tidb/bin/
### 2.3 启动TiDB服务
$ systemctl start tidb@2
### 2.4 验证TiDB状态
$ mysql -h 192.168.1.11 -P 4000 -u root -e “SHOW STATUS LIKE ‘tidb_version’;”
# 输出示例
+—————+——–+
| Variable_name | Value |
+—————+——–+
| tidb_version | 6.1.1 |
+—————+——–+
## 3. 升级TiDB节点（tidb-3）
### 3.1 停止TiDB服务
$ systemctl stop tidb@3
### 3.2 替换TiDB二进制文件
$ cp /tidb/upgrade/tidb-6.1.1-linux-amd64/tidb-server /tidb/app/tidb/bin/
### 3.3 启动TiDB服务
$ systemctl start tidb@3
### 3.4 验证TiDB状态
$ mysql -h 192.168.1.12 -P 4000 -u root -e “SHOW STATUS LIKE ‘tidb_version’;”
# 输出示例
+—————+——–+
| Variable_name | Value |
+—————+——–+
| tidb_version | 6.1.1 |
+—————+——–+
## 4. 升级TiDB节点（tidb-1）
### 4.1 停止TiDB服务
$ systemctl stop tidb@1
### 4.2 替换TiDB二进制文件
$ cp /tidb/upgrade/tidb-6.1.1-linux-amd64/tidb-server /tidb/app/tidb/bin/
### 4.3 启动TiDB服务
$ systemctl start tidb@1
### 4.4 验证TiDB状态
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SHOW STATUS LIKE ‘tidb_version’;”
# 输出示例
+—————+——–+
| Variable_name | Value |
+—————+——–+
| tidb_version | 6.1.1 |
+—————+——–+
## 5. 验证TiDB集群状态
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SELECT * FROM information_schema.cluster_info;”
# 输出示例
+——–+—————–+—————+——–+———————+
| TYPE | INSTANCE | STATUS | VERSION | START_TIME |
+——–+—————–+—————+——–+———————+
| tidb | 192.168.1.10:4000 | ONLINE | 6.1.1 | 2024-01-01 10:00:00 |
| tidb | 192.168.1.11:4000 | ONLINE | 6.1.1 | 2024-01-01 10:05:00 |
| tidb | 192.168.1.12:4000 | ONLINE | 6.1.1 | 2024-01-01 10:10:00 |
| tikv | 192.168.1.20:20160 | ONLINE | 6.1.1 | 2024-01-01 10:15:00 |
| tikv | 192.168.1.21:20160 | ONLINE | 6.1.1 | 2024-01-01 10:20:00 |
| tikv | 192.168.1.22:20160 | ONLINE | 6.1.1 | 2024-01-01 10:25:00 |
| pd | 192.168.1.10:2379 | ONLINE | 6.1.1 | 2024-01-01 10:30:00 |
| pd | 192.168.1.11:2379 | ONLINE | 6.1.1 | 2024-01-01 10:35:00 |
| pd | 192.168.1.12:2379 | ONLINE | 6.1.1 | 2024-01-01 10:40:00 |
+——–+—————–+—————+——–+———————+
3.2 滚动升级监控
滚动升级过程中的监控：
## 1. 集群状态监控
– **PD状态**：
$ pd-ctl -u http://192.168.1.10:2379 status
– **TiKV状态**：
$ pd-ctl -u http://192.168.1.10:2379 store
– **TiDB状态**：
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SELECT * FROM information_schema.cluster_info;”
## 2. 性能监控
– **CPU使用率**：
$ top
– **内存使用**：
$ free -h
– **磁盘IO**：
$ iostat -x 1
– **网络流量**：
$ iftop
## 3. 业务监控
– **响应时间**：
$ ab -n 1000 -c 100 http://192.168.1.10:8080/
– **错误率**：
$ curl -s http://192.168.1.10:8080/health
– **QPS**：
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SHOW GLOBAL STATUS LIKE ‘Queries’;”
## 4. 监控平台
– **Prometheus**：http://192.168.1.10:9090
– **Grafana**：http://192.168.1.10:3000
– **TiDB Dashboard**：http://192.168.1.10:2379/dashboard
## 5. 告警设置
– **PD告警**：leader选举失败、集群状态异常
– **TiKV告警**：store下线、leader数量异常
– **TiDB告警**：连接数过高、SQL执行异常
– **系统告警**：CPU使用率过高、内存不足、磁盘空间不足
3.3 滚动升级验证
滚动升级后的验证：
## 1. 版本验证
– **PD版本**：
$ pd-ctl -u http://192.168.1.10:2379 status | grep version
– **TiKV版本**：
$ tikv-ctl status –host 192.168.1.20:20160 | grep version
– **TiDB版本**：
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SHOW STATUS LIKE ‘tidb_version’;”
## 2. 集群状态验证
– **PD集群**：
$ pd-ctl -u http://192.168.1.10:2379 status
– **TiKV集群**：
$ pd-ctl -u http://192.168.1.10:2379 store
– **TiDB集群**：
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SELECT * FROM information_schema.cluster_info;”
## 3. 数据完整性验证
– **检查数据量**：
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SELECT COUNT(*) FROM fgedu_users;”
– **检查数据内容**：
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SELECT * FROM fgedu_users ORDER BY create_time DESC LIMIT 5;”
– **检查索引**：
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SHOW INDEX FROM fgedu_users;”
## 4. 业务功能验证
– **运行测试用例**：
$ ./run_business_test.sh
– **检查API响应**：
$ curl -s http://192.168.1.10:8080/api/users
– **检查SQL执行**：
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SELECT * FROM fgedu_orders WHERE user_id = 1000;”
## 5. 性能验证
– **运行基准测试**：
$ sysbench –test=oltp_read_write –db-driver=mysql –mysql-host=192.168.1.10 –mysql-port=4000 –mysql-user=root –mysql-password= –mysql-db=fgedudb –tables=1 –table-size=1000000 –threads=16 –time=60 run
– **检查响应时间**：
$ ab -n 1000 -c 100 http://192.168.1.10:8080/
– **检查资源使用**：
$ top
$ free -h
$ iostat -x 1
Part04-生产案例与实战讲解
4.1 滚动升级实战
4.1.1 滚动升级实战案例
## 1. 环境信息
– **集群规模**：3节点PD + 3节点TiKV + 3节点TiDB
– **当前版本**：6.1.0
– **目标版本**：6.1.1
– **升级时间**：业务低峰期（凌晨2:00-4:00）
## 2. 升级前准备
### 2.1 备份数据
$ br backup full –pd “192.168.1.10:2379” –storage “local:///tidb/backup”
# 输出示例
2024-01-01 01:30:00.000 INFO [backup] full backup start
2024-01-01 01:30:00.000 INFO [backup] backup metadata
2024-01-01 01:30:01.000 INFO [backup] backup data
2024-01-01 01:35:00.000 INFO [backup] backup success
### 2.2 检查集群状态
$ pd-ctl -u http://192.168.1.10:2379 status
$ pd-ctl -u http://192.168.1.10:2379 store
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SHOW STATUS LIKE ‘tidb_version’;”
## 3. 开始滚动升级
### 3.1 升级PD集群
– 升级pd-2（非Leader）：成功
– 升级pd-3（非Leader）：成功
– 升级pd-1（Leader）：成功
### 3.2 升级TiKV集群
– 升级tikv-2（负载较低）：成功
– 升级tikv-3（负载较低）：成功
– 升级tikv-1（负载较高）：成功
### 3.3 升级TiDB集群
– 升级tidb-2（负载较低）：成功
– 升级tidb-3（负载较低）：成功
– 升级tidb-1（负载较高）：成功
## 4. 升级后验证
### 4.1 版本验证
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SELECT * FROM information_schema.cluster_info;”
# 输出示例
+——–+—————–+—————+——–+———————+
| TYPE | INSTANCE | STATUS | VERSION | START_TIME |
+——–+—————–+—————+——–+———————+
| tidb | 192.168.1.10:4000 | ONLINE | 6.1.1 | 2024-01-01 02:30:00 |
| tidb | 192.168.1.11:4000 | ONLINE | 6.1.1 | 2024-01-01 02:25:00 |
| tidb | 192.168.1.12:4000 | ONLINE | 6.1.1 | 2024-01-01 02:20:00 |
| tikv | 192.168.1.20:20160 | ONLINE | 6.1.1 | 2024-01-01 02:15:00 |
| tikv | 192.168.1.21:20160 | ONLINE | 6.1.1 | 2024-01-01 02:10:00 |
| tikv | 192.168.1.22:20160 | ONLINE | 6.1.1 | 2024-01-01 02:05:00 |
| pd | 192.168.1.10:2379 | ONLINE | 6.1.1 | 2024-01-01 02:00:00 |
| pd | 192.168.1.11:2379 | ONLINE | 6.1.1 | 2024-01-01 01:55:00 |
| pd | 192.168.1.12:2379 | ONLINE | 6.1.1 | 2024-01-01 01:50:00 |
+——–+—————–+—————+——–+———————+
### 4.2 数据完整性验证
$ mysql -h 192.168.1.10 -P 4000 -u root -e “SELECT COUNT(*) FROM fgedu_users;”
# 输出示例
+———-+
| COUNT(*) |
+———-+
| 500000 |
+———-+
### 4.3 业务功能验证
$ ./run_business_test.sh
# 输出示例
Test 1: User registration – PASS
Test 2: Order creation – PASS
Test 3: Payment processing – PASS
Test 4: Inventory management – PASS
Test 5: Report generation – PASS
All business tests passed!
### 4.4 性能验证
$ sysbench –test=oltp_read_write –db-driver=mysql –mysql-host=192.168.1.10 –mysql-port=4000 –mysql-user=root –mysql-password= –mysql-db=fgedudb –tables=1 –table-size=1000000 –threads=16 –time=60 run
# 输出示例
sysbench 1.0.20 (using system LuaJIT 2.0.5)
Running the test with following options:
Number of threads: 16
Initializing random number generator from current time
Initializing worker threads…
Threads started!
SQL statistics:
queries performed:
read: 160000
write: 45714
other: 22857
total: 228571
transactions:
total: 11428 (190.47 per sec.)
time spent:
total: 60.0000s
waiting on locks: 0.0000s
Threads fairness:
events (avg/stddev): 714.2500/12.34
execution time (avg/stddev): 60.0000/0.00
## 5. 升级总结
– **升级时间**：2小时（从01:30到03:30）
– **服务中断**：无
– **业务影响**：无
– **升级成功**：所有节点均成功升级到6.1.1版本
– **性能表现**：升级后性能与升级前基本一致，无明显波动
4.2 滚动升级故障处理
滚动升级过程中的故障处理：
## 1. PD节点启动失败
– **问题描述**：PD节点升级后无法启动
– **原因分析**：配置文件不兼容、二进制文件损坏、端口被占用
– **解决方案**：
– 检查配置文件，确保与目标版本兼容
– 重新下载并验证二进制文件
– 检查端口占用情况，释放端口
– 查看PD日志，分析具体错误信息
## 2. TiKV节点启动失败
– **问题描述**：TiKV节点升级后无法启动
– **原因分析**：数据目录损坏、配置文件错误、资源不足
– **解决方案**：
– 检查TiKV日志，分析具体错误信息
– 验证数据目录完整性
– 调整配置文件参数
– 确保系统资源充足
## 3. TiDB节点启动失败
– **问题描述**：TiDB节点升级后无法启动
– **原因分析**：配置文件错误、端口被占用、依赖库缺失
– **解决方案**：
– 检查TiDB日志，分析具体错误信息
– 检查配置文件参数
– 检查端口占用情况
– 安装缺失的依赖库
## 4. 集群状态异常
– **问题描述**：升级后集群状态异常
– **原因分析**：网络问题、节点间通信失败、数据不一致
– **解决方案**：
– 检查网络连接
– 检查节点间通信
– 运行集群健康检查
– 必要时进行数据修复
## 5. 业务功能异常
– **问题描述**：升级后业务功能异常
– **原因分析**：SQL语法不兼容、API变更、配置参数变更
– **解决方案**：
– 检查SQL语法，修改不兼容的语句
– 更新客户端API
– 调整配置参数
– 测试业务功能，确保正常运行
## 6. 回滚操作
– **触发条件**：升级过程中出现严重错误，无法继续
– **回滚步骤**：
– 停止当前升级操作
– 恢复备份的二进制文件
– 重启服务
– 验证集群状态
– 分析失败原因，重新制定升级计划
4.3 滚动升级性能影响
滚动升级对性能的影响：
## 1. 升级过程中的性能影响
– **CPU使用率**：短暂升高（10-20%），升级完成后恢复正常
– **内存使用**：短暂升高（5-10%），升级完成后恢复正常
– **磁盘IO**：升高（20-30%），主要用于二进制文件替换和数据同步
– **网络流量**：升高（15-25%），主要用于节点间通信和数据同步
– **响应时间**：轻微增加（5-10%），升级完成后恢复正常
– **QPS**：轻微下降（5-10%），升级完成后恢复正常
## 2. 升级后的性能变化
– **版本优化**：新版本可能包含性能优化，性能可能有所提升
– **配置调整**：新版本可能需要调整配置参数以获得最佳性能
– **兼容性**：新版本可能与某些应用程序存在兼容性问题，影响性能
## 3. 性能优化建议
– **升级前**：
– 调整集群参数，提高系统稳定性
– 清理不必要的数据，减少数据同步时间
– 确保系统资源充足
– **升级中**：
– 监控性能指标，及时发现异常
– 调整升级速度，避免性能波动过大
– 优先升级负载较低的节点
– **升级后**：
– 运行性能测试，验证系统性能
– 调整配置参数，优化系统性能
– 监控系统状态，确保性能稳定
## 4. 性能测试案例
– **测试环境**：3节点PD + 3节点TiKV + 3节点TiDB
– **测试工具**：sysbench
– **测试场景**：oltp_read_write
– **测试结果**：
– 升级前：190.47 transactions/sec
– 升级中：175.32 transactions/sec（下降约8%）
– 升级后：195.68 transactions/sec（提升约3%）
## 5. 性能监控建议
– **实时监控**：使用Prometheus和Grafana实时监控性能指标
– **基准测试**：升级前后运行基准测试，比较性能变化
– **业务监控**：监控业务响应时间和错误率
– **告警设置**：设置性能告警，及时发现性能问题
Part05-风哥经验总结与分享
5.1 最佳实践
滚动升级的最佳实践：
- 充分准备：在升级前做好充分的准备工作，包括备份数据、检查集群状态、准备升级包等
- 制定计划：制定详细的升级计划，包括升级顺序、时间窗口、回滚方案等
- 监控到位：在升级过程中密切监控集群状态和性能指标，及时发现和解决问题
- 验证完整：升级后进行全面的验证，确保集群状态正常、数据完整、业务功能正常
- 循序渐进：按照PD → TiKV → TiDB的顺序进行升级，逐个节点升级，确保服务不中断
- 选择时机：选择业务低峰期进行升级，减少对业务的影响
- 测试演练：在测试环境进行升级演练，确保升级过程顺利
- 文档记录：详细记录升级过程，包括遇到的问题和解决方案，为后续升级提供参考
5.2 常见问题与解决方案
滚动升级过程中的常见问题与解决方案：
## 1. 节点启动失败
– **问题**：升级后节点无法启动
– **原因**：配置文件不兼容、二进制文件损坏、端口被占用
– **解决**：检查配置文件、重新下载二进制文件、释放端口
## 2. 集群状态异常
– **问题**：升级后集群状态异常
– **原因**：网络问题、节点间通信失败、数据不一致
– **解决**：检查网络连接、运行集群健康检查、修复数据不一致
## 3. 业务功能异常
– **问题**：升级后业务功能异常
– **原因**：SQL语法不兼容、API变更、配置参数变更
– **解决**：修改SQL语句、更新客户端API、调整配置参数
## 4. 性能下降
– **问题**：升级后性能下降
– **原因**：配置参数不优化、新特性不适应、数据同步开销
– **解决**：调整配置参数、关闭不必要的新特性、等待数据同步完成
## 5. 升级时间过长
– **问题**：升级过程时间过长
– **原因**：集群规模大、数据量多、网络速度慢
– **解决**：优化升级顺序、增加网络带宽、选择合适的升级时间
## 6. 回滚失败
– **问题**：升级失败后回滚操作失败
– **原因**：备份不完整、回滚步骤错误、系统状态异常
– **解决**：确保备份完整、按照正确的回滚步骤操作、分析系统状态
5.3 升级技巧
滚动升级的实用技巧：
## 1. 升级顺序技巧
– **PD升级**：先升级非Leader节点，再升级Leader节点，避免影响集群调度
– **TiKV升级**：按照负载顺序升级，先升级负载较低的节点，减少对业务的影响
– **TiDB升级**：按照负载顺序升级，先升级负载较低的节点，确保业务请求能够被处理
## 2. 时间窗口选择
– **业务低峰期**：选择业务量最小的时间段进行升级
– **维护窗口**：利用已有的维护窗口进行升级
– **节假日**：选择节假日进行升级，减少对业务的影响
## 3. 监控技巧
– **实时监控**：使用Prometheus和Grafana实时监控集群状态和性能指标
– **告警设置**：设置合理的告警阈值，及时发现和解决问题
– **日志分析**：实时分析节点日志，及时发现异常情况
## 4. 故障处理技巧
– **快速定位**：通过日志和监控快速定位问题原因
– **及时回滚**：当出现严重问题时，及时执行回滚操作
– **分步排查**：按照PD → TiKV → TiDB的顺序排查问题
– **沟通协调**：及时与相关人员沟通，协调解决问题
## 5. 性能优化技巧
– **升级前优化**：清理不必要的数据，调整配置参数，提高系统稳定性
– **升级中优化**：调整升级速度，避免性能波动过大
– **升级后优化**：运行性能测试，调整配置参数，优化系统性能
## 6. 文档记录技巧
– **详细记录**：记录升级过程中的每一步操作和结果
– **问题记录**：记录遇到的问题和解决方案
– **经验总结**：总结升级经验，为后续升级提供参考
– **模板化**：创建升级模板，提高后续升级的效率
本文档详细介绍了TiDB滚动升级的实战全流程，包括滚动升级的概念、原理、优势、升级前准备、滚动升级计划、注意事项、升级步骤、监控、验证、实战案例、故障处理和性能影响等内容。通过本文档的学习，读者可以掌握TiDB滚动升级的完整流程和最佳实践，确保升级过程的顺利进行。学习交流加群风哥QQ113257174
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
联系我们
在线咨询：
微信号：itpux-com
工作日：9:30-18:30，节假日休息
