2. 首页 > 国产数据库教程 > OceanBase教程 > 正文

OceanBase教程FG052-OceanBase版本升级实战

教程整理：风哥教程  |  更新时间：2026-01-29  |  教程分类：OceanBase教程  |  文档学习：28

本文档风哥主要介绍OceanBase数据库版本升级相关知识，包括OceanBase版本升级的概念与类型、OceanBase升级路径与版本兼容性、OceanBase滚动升级原理、OceanBase升级前规划与准备、OceanBase升级前检查、OceanBase滚动升级操作、OceanBase升级后验证等内容，风哥教程参考OceanBase官方文档升级指南、运维手册等内容编写，适合DBA人员在学习和测试中使用，如果要应用于生产环境则需要自行确认。

Part01-基础概念与理论知识

1.1 OceanBase版本升级的概念与类型

OceanBase版本升级是指将数据库软件从一个版本更新到另一个版本的过程。根据升级的范围和影响，可以分为不同类型。更多视频教程www.fgedu.net.cn

OceanBase版本升级类型：

  • 补丁升级：相同版本内的补丁更新，如V4.2.1 BP1升级到BP2，风险最低
  • 小版本升级：版本号第二位变化，如V4.2.x升级到V4.3.x，功能增强
  • 大版本升级：版本号第一位变化，如V3.x升级到V4.x，架构变化较大
  • 滚动升级：逐个Zone升级，业务不中断，推荐方式
  • 停服升级：停止业务后升级，适用于小规模集群

1.2 OceanBase升级路径与版本兼容性

OceanBase版本升级需要遵循特定的升级路径，不是所有版本都可以直接升级。

# OceanBase升级路径规则

1. 支持的升级路径
V4.2.1.x -> V4.2.2.x -> V4.3.0.x -> V4.3.1.x
V4.2.1.x -> V4.3.0.x (直接升级)
V4.1.x -> V4.2.x (需要先升级到V4.2.0)

2. 不支持的升级路径
V3.x -> V4.x (不支持直接升级，需要数据迁移)
V4.0.x -> V4.3.x (需要先升级到V4.2.x)
跨多个大版本升级

3. 版本兼容性检查
– 检查当前版本是否支持升级到目标版本
– 检查集群状态是否正常
– 检查是否有未完成的合并
– 检查参数兼容性

4. 升级前必读
– 查看目标版本的Release Notes
– 了解新特性和已知问题
– 确认业务兼容性
– 准备回滚方案

1.3 OceanBase滚动升级原理

OceanBase滚动升级是分布式数据库特有的高可用升级策略，通过分批次、渐进式的节点更新，确保升级过程中业务不中断。

# 滚动升级核心原理

1. Zone级滚动升级
– OceanBase集群由多个Zone组成
– 逐个Zone进行升级
– 升级某个Zone前，将其Leader切换到其他Zone
– 保证升级过程中始终有可用副本

2. 升级流程，风哥提示：。
Zone1: Leader切换 -> 停止服务 -> 升级软件 -> 启动服务 -> 数据同步 -> Leader恢复
Zone2: Leader切换 -> 停止服务 -> 升级软件 -> 启动服务 -> 数据同步 -> Leader恢复
Zone3: Leader切换 -> 停止服务 -> 升级软件 -> 启动服务 -> 数据同步 -> Leader恢复

3. 数据一致性保障
– 使用Paxos协议保证数据一致性
– 升级过程中保持多数派副本可用
– 自动处理版本兼容性问题
– 支持新旧版本混合运行

4. 业务影响
– 业务几乎无感知
– 可能有短暂的性能波动
– Leader切换时可能有毫秒级延迟
– 整体可用性保持在99.99%以上

风哥提示：滚动升级是OceanBase的核心优势之一，可以实现业务零停机的版本升级。但升级前必须做好充分的准备工作，包括备份、检查、回滚方案等。

Part02-生产环境规划与建议

2.1 OceanBase升级前规划与准备

OceanBase升级前需要进行详细的规划和准备，确保升级过程顺利进行。

# 升级前规划清单

1. 升级目标确定，学习交流加群风哥微信: itpux-com。
– 确定当前版本：V4.2.1.6
– 确定目标版本：V4.3.0.0
– 确认升级路径：V4.2.1.6 -> V4.3.0.0
– 了解版本差异：查看Release Notes

2. 环境准备
– 下载升级包：oceanbase-4.3.0.0-xxx.el7.x86_64.rpm
– 准备升级工具：upgrade_checker.py、upgrade_pre.py等
– 检查磁盘空间：确保有足够的空间存放升级包和日志
– 检查网络：确保各节点间网络通畅

3. 备份准备
– 全量物理备份
– 系统表备份
– 配置文件备份
– 租户数据备份

4. 时间窗口规划
– 选择业务低峰期
– 预留充足的升级时间
– 预留回滚时间
– 通知相关业务方

5. 人员准备
– 确定升级负责人
– 准备技术支持人员
– 通知业务值班人员
– 建立应急沟通渠道

2.2 OceanBase升级风险评估

OceanBase升级前需要进行全面的风险评估，识别潜在风险并制定应对措施。

# 风险评估清单

1. 技术风险
┌─────────────────┬─────────┬─────────────────────────────┐
│ 风险项 │ 风险等级│ 应对措施 │
├─────────────────┼─────────┼─────────────────────────────┤，学习交流加群风哥QQ113257174。
│ 升级失败 │ 高 │ 准备回滚方案，保留备份 │
│ 数据不一致 │ 高 │ 升级前数据校验，升级后验证 │
│ 性能下降 │ 中 │ 准备参数调优方案 │
│ 兼容性问题 │ 中 │ 提前测试业务兼容性 │
│ 网络中断 │ 低 │ 检查网络冗余，准备应急方案 │
└─────────────────┴─────────┴─────────────────────────────┘

2. 业务风险
– 升级期间业务中断风险
– 升级后业务异常风险
– 数据丢失风险
– 性能不达标风险

3. 风险评估方法
– 在测试环境模拟升级
– 进行充分的回归测试
– 评估业务影响范围
– 制定风险应对预案

4. 风险接受标准
– 升级失败可以回滚
– 数据可以恢复
– 业务中断时间可接受
– 性能下降在可接受范围

2.3 OceanBase升级回滚策略

OceanBase升级必须制定完善的回滚策略，以应对升级失败的情况。

# 回滚策略

1. 回滚触发条件
– 升级过程中出现严重错误
– 升级后业务无法正常运行
– 升级后性能严重下降
– 发现严重兼容性问题

2. 回滚方式，更多视频教程www.fgedu.net.cn。

方式一：版本回滚（推荐）
– 将已升级的Zone回退到原版本
– 适用于升级过程中发现问题
– 需要保留原版本的二进制文件

方式二：数据恢复
– 使用备份数据恢复
– 适用于升级完成后发现问题
– 需要完整的数据备份

3. 回滚步骤

# 停止升级流程
$ ./upgrade_post.py –stop

# 回滚已升级的Zone
$ ./upgrade_rollback.py –zone=zone1

# 验证回滚结果
$ ./upgrade_checker.py –check

# 恢复业务
# 通知业务方验证

4. 回滚注意事项
– 回滚前必须停止升级流程
– 回滚过程中业务会受影响
– 回滚后需要验证数据完整性
– 记录回滚原因，分析改进

生产环境建议：升级前必须做好完整的备份，包括数据备份和配置备份。升级过程中要密切监控集群状态，发现问题及时处理。学习交流加群风哥微信: itpux-com

Part03-生产环境项目实施方案

3.1 OceanBase升级前检查

3.1.1 集群健康状态检查

，更多学习教程公众号风哥教程itpux_com。

# 1. 检查集群状态
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.DBA_OB_SERVERS;”

+—————+———-+——-+———-+————–+—————-+
| SVR_IP | SVR_PORT | ZONE | STATUS | STOP_TIME | START_SERVICE_TIME |
+—————+———-+——-+———-+————–+—————-+
| 192.168.1.101 | 2882 | zone1 | ACTIVE | NULL | 2024-01-15 |
| 192.168.1.102 | 2882 | zone2 | ACTIVE | NULL | 2024-01-15 |
| 192.168.1.103 | 2882 | zone3 | ACTIVE | NULL | 2024-01-15 |
+—————+———-+——-+———-+————–+—————-+

# 2. 检查合并状态
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.CDB_OB_ZONE_MAJOR_COMPACTION;”

+——-+————+—————-+———————+
| ZONE | STATUS | IS_SUSPENDED | LAST_FINISH_TIME |
+——-+————+—————-+———————+
| zone1 | IDLE | FALSE | 2024-01-20 03:00:00 |
| zone2 | IDLE | FALSE | 2024-01-20 03:00:00 |
| zone3 | IDLE | FALSE | 2024-01-20 03:00:00 |
+——-+————+—————-+———————+

# 3. 检查租户状态
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.DBA_OB_TENANTS;”

+———–+————-+————-+——–+
| TENANT_ID | TENANT_NAME | TENANT_TYPE | STATUS |
+———–+————-+————-+——–+
| 1 | sys | SYS | NORMAL |，from DB视频:www.itpux.com。
| 1001 | fgedu_tenant| USER | NORMAL |
| 1002 | meta | META | NORMAL |
+———–+————-+————-+——–+

# 4. 检查数据同步状态
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.GV$OB_LOG_STAT;”

+—————+———-+———–+—————+
| SVR_IP | SVR_PORT | TENANT_ID | LS_ID |
+—————+———-+———–+—————+
| 192.168.1.101 | 2882 | 1001 | 1 |
| 192.168.1.102 | 2882 | 1001 | 1 |
| 192.168.1.103 | 2882 | 1001 | 1 |
+—————+———-+———–+—————+

3.1.2 使用upgrade_checker.py检查

# 运行升级前检查脚本
$ cd /ob/app/oceanbase/etc
$ python upgrade_checker.py -h192.168.1.101 -P2881 -uroot@sys -p******

[2024-01-20 10:00:00] INFO: Starting upgrade checker…
[2024-01-20 10:00:01] INFO: Checking cluster status…
[2024-01-20 10:00:02] INFO: Cluster status: NORMAL
[2024-01-20 10:00:03] INFO: Checking tenant status…
[2024-01-20 10:00:04] INFO: All tenants are NORMAL
[2024-01-20 10:00:05] INFO: Checking compaction status…
[2024-01-20 10:00:06] INFO: Compaction status: IDLE
[2024-01-20 10:00:07] INFO: Checking log sync status…
[2024-01-20 10:00:08] INFO: Log sync status: NORMAL
[2024-01-20 10:00:09] INFO: Checking parameter compatibility…
[2024-01-20 10:00:10] INFO: Parameter check passed
[2024-01-20 10:00:11] INFO: Checking system variables…
[2024-01-20 10:00:12] INFO: System variables check passed
[2024-01-20 10:00:13] INFO: All checks passed!
[2024-01-20 10:00:13] INFO: Cluster is ready for upgrade.

# 检查输出结果
# 如果所有检查都通过，会显示”All checks passed!”
# 如果有检查失败，需要根据提示修复问题

3.1.3 备份检查

# 1. 执行全量备份
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM BACKUP DATABASE;”

Query OK, 0 rows affected

# 2. 检查备份状态
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.CDB_OB_BACKUP_JOBS;”

+——–+———–+————-+——–+———-+———————+
| JOB_ID | TENANT_ID | TENANT_NAME | STATUS | BACKUP_SET_ID | START_TIME |
+——–+———–+————-+——–+———-+———————+
| 1001 | 1001 | fgedu_tenant| SUCCESS| 100 | 2024-01-20 09:00:00 |
+——–+———–+————-+——–+———-+———————+

# 3. 备份配置文件
$ mkdir -p /backup/ob_upgrade/20240120
$ cp /ob/app/oceanbase/etc/observer.cnf /backup/ob_upgrade/20240120/
$ cp -r /ob/app/oceanbase/etc /backup/ob_upgrade/20240120/etc_backup

# 4. 验证备份完整性
$ ls -lh /backup/ob_upgrade/20240120/

-rw-r–r– 1 admin admin 2.5K Jan 20 09:30 observer.cnf
drwxr-xr-x 3 admin admin 4.0K Jan 20 09:30 etc_backup

3.2 OceanBase滚动升级操作

3.2.1 升级前准备

# 1. 设置升级标志
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM SET enable_upgrade=true;”

Query OK, 0 rows affected

# 2. 运行upgrade_pre.py
$ python upgrade_pre.py -h192.168.1.101 -P2881 -uroot@sys -p******

[2024-01-20 10:30:00] INFO: Starting upgrade preparation…
[2024-01-20 10:30:01] INFO: Checking upgrade prerequisites…
[2024-01-20 10:30:02] INFO: Disabling rebalancing…
[2024-01-20 10:30:03] INFO: Disabling major compaction…
[2024-01-20 10:30:04] INFO: Upgrade preparation completed.

# 3. 确认禁止的操作
# 升级期间禁止以下操作：
# – DDL操作（CREATE/ALTER/DROP TABLE等）
# – 租户资源调整
# – 副本复制和迁移
# – 手动触发合并

3.2.2 Zone级滚动升级

# 升级zone1

# 1. 切换Leader
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM SWITCH LEADER ZONE=’zone1′;”

Query OK, 0 rows affected

# 2. 停止zone1的observer
$ ssh admin@192.168.1.101
$ cd /ob/app/oceanbase
$ ./bin/observer -stop

stop server success.

# 3. 备份原二进制文件
$ mv /ob/app/oceanbase/bin/observer /ob/app/oceanbase/bin/observer.bak.4216

# 4. 替换新版本二进制
$ cp /soft/oceanbase-4.3.0.0/bin/observer /ob/app/oceanbase/bin/
$ chmod +x /ob/app/oceanbase/bin/observer

# 5. 启动observer
$ ./bin/observer -c /ob/app/oceanbase/etc/observer.cnf

start server success.

# 6. 检查zone1状态
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.DBA_OB_SERVERS WHERE ZONE=’zone1′;”

+—————+———-+——-+———-+
| SVR_IP | SVR_PORT | ZONE | STATUS |
+—————+———-+——-+———-+
| 192.168.1.101 | 2882 | zone1 | ACTIVE |
+—————+———-+——-+———-+

# 7. 等待数据同步
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.GV$OB_LOG_STAT WHERE SVR_IP=’192.168.1.101′;”

# 确认日志同步正常

# 8. 升级zone2（重复上述步骤）
# 升级zone3（重复上述步骤）

3.2.3 升级后处理

# 1. 运行upgrade_post.py
$ python upgrade_post.py -h192.168.1.101 -P2881 -uroot@sys -p******

[2024-01-20 12:00:00] INFO: Starting upgrade post process…
[2024-01-20 12:00:01] INFO: Updating internal tables…
[2024-01-20 12:00:02] INFO: Updating system variables…
[2024-01-20 12:00:03] INFO: Updating system packages…
[2024-01-20 12:00:04] INFO: Running system self-check…
[2024-01-20 12:00:05] INFO: Pushing tenant version…
[2024-01-20 12:00:06] INFO: Upgrade post process completed.

# 2. 关闭升级标志
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM SET enable_upgrade=false;”

Query OK, 0 rows affected

# 3. 恢复自动合并
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM RESUME MERGE;”

Query OK, 0 rows affected

# 4. 恢复负载均衡
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM SET enable_rebalance=true;”

Query OK, 0 rows affected

3.3 OceanBase升级后验证

3.3.1 版本验证

# 1. 检查版本号
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT version();”

+————————————–+
| version() |
+————————————–+
| 4.3.0.0-OceanBase_CE |
+————————————–+

# 2. 检查所有节点版本
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT SVR_IP, BUILD_VERSION FROM oceanbase.GV$OB_SERVERS;”

+—————+———————————-+
| SVR_IP | BUILD_VERSION |
+—————+———————————-+
| 192.168.1.101 | 4.3.0.0-OceanBase_CE |
| 192.168.1.102 | 4.3.0.0-OceanBase_CE |
| 192.168.1.103 | 4.3.0.0-OceanBase_CE |
+—————+———————————-+

# 3. 检查租户版本
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT TENANT_NAME, COMPATIBILITY_MODE, VERSION FROM oceanbase.DBA_OB_TENANTS;”

+————-+——————-+———+
| TENANT_NAME | COMPATIBILITY_MODE| VERSION |
+————-+——————-+———+
| sys | MYSQL | 4.3.0.0 |
| fgedu_tenant| MYSQL | 4.3.0.0 |
+————-+——————-+———+

3.3.2 功能验证

# 1. 基本SQL测试
$ obclient -h192.168.1.101 -P2881 -ufgedu@fgedu_tenant -p -e ”
CREATE TABLE IF NOT EXISTS fgedu_test_upgrade (
id BIGINT PRIMARY KEY,
name VARCHAR(100),
create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO fgedu_test_upgrade VALUES (1, ‘test1’, NOW());
INSERT INTO fgedu_test_upgrade VALUES (2, ‘test2’, NOW());
INSERT INTO fgedu_test_upgrade VALUES (3, ‘test3’, NOW());

SELECT * FROM fgedu_test_upgrade;
”

+—-+——-+———————+
| id | name | create_time |
+—-+——-+———————+
| 1 | test1 | 2024-01-20 14:00:00 |
| 2 | test2 | 2024-01-20 14:00:00 |
| 3 | test3 | 2024-01-20 14:00:00 |
+—-+——-+———————+

# 2. 事务测试
$ obclient -h192.168.1.101 -P2881 -ufgedu@fgedu_tenant -p -e ”
BEGIN;
INSERT INTO fgedu_test_upgrade VALUES (4, ‘test4′, NOW());
UPDATE fgedu_test_upgrade SET name=’updated’ WHERE id=1;
COMMIT;

SELECT * FROM fgedu_test_upgrade WHERE id IN (1, 4);
”

+—-+———+———————+
| id | name | create_time |
+—-+———+———————+
| 1 | updated | 2024-01-20 14:00:00 |
| 4 | test4 | 2024-01-20 14:01:00 |
+—-+———+———————+

# 3. 清理测试表
$ obclient -h192.168.1.101 -P2881 -ufgedu@fgedu_tenant -p -e “DROP TABLE fgedu_test_upgrade;”

Query OK, 0 rows affected

风哥提示：升级后的验证工作非常重要，必须验证版本、功能、性能等各方面都正常后，才能确认升级成功。学习交流加群风哥QQ113257174

Part04-生产案例与实战讲解

4.1 OceanBase V4.2.1升级V4.3.0案例

某金融公司将其生产环境从OceanBase V4.2.1.6升级到V4.3.0.0，以下是详细过程：

# 升级背景
– 当前版本：V4.2.1.6
– 目标版本：V4.3.0.0
– 集群规模：3个Zone，每个Zone 3台服务器，共9台
– 业务类型：金融核心交易系统
– 升级窗口：周六凌晨2:00-6:00

# 升级前准备

1. 环境检查
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.DBA_OB_SERVERS;”

+—————+———-+——-+———-+
| SVR_IP | SVR_PORT | ZONE | STATUS |
+—————+———-+——-+———-+
| 192.168.1.101 | 2882 | zone1 | ACTIVE |
| 192.168.1.102 | 2882 | zone1 | ACTIVE |
| 192.168.1.103 | 2882 | zone1 | ACTIVE |
| 192.168.1.104 | 2882 | zone2 | ACTIVE |
| 192.168.1.105 | 2882 | zone2 | ACTIVE |
| 192.168.1.106 | 2882 | zone2 | ACTIVE |
| 192.168.1.107 | 2882 | zone3 | ACTIVE |
| 192.168.1.108 | 2882 | zone3 | ACTIVE |
| 192.168.1.109 | 2882 | zone3 | ACTIVE |
+—————+———-+——-+———-+

2. 执行全量备份
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM BACKUP DATABASE;”

# 备份完成时间：2:30
# 备份集ID：1001

3. 运行升级检查
$ python upgrade_checker.py -h192.168.1.101 -P2881 -uroot@sys -p******

[2024-01-20 02:00:00] INFO: All checks passed!

# 升级执行

1. 开始升级（2:35）
$ python upgrade_pre.py -h192.168.1.101 -P2881 -uroot@sys -p******

2. 升级zone1（2:40-3:20）
– 切换Leader：2分钟
– 停止服务：1分钟
– 升级软件：5分钟
– 启动服务：2分钟
– 数据同步：30分钟

3. 升级zone2（3:25-4:05）
– 同上流程

4. 升级zone3（4:10-4:50）
– 同上流程

5. 升级后处理（4:55-5:10）
$ python upgrade_post.py -h192.168.1.101 -P2881 -uroot@sys -p******

# 升级结果
– 升级完成时间：5:10
– 业务影响：无感知
– 性能对比：持平
– 升级成功

4.2 OceanBase大规模集群升级案例

某互联网公司的大规模OceanBase集群升级案例：

# 集群规模
– 5个Zone，每个Zone 10台服务器，共50台
– 多个租户，总数据量500TB
– 日均QPS 100万+

# 升级策略

1. 分批升级
– 第一批：zone1（10台）
– 第二批：zone2（10台）
– 第三批：zone3（10台）
– 第四批：zone4（10台）
– 第五批：zone5（10台）

2. 升级脚本
#!/bin/bash
# ob_upgrade.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: http://www.fgedu.net.cn

ZONE=$1
SERVERS=$(cat /ob/scripts/server_list.txt | grep $ZONE | awk ‘{print $1}’)

echo “Starting upgrade for $ZONE…”
echo “Servers: $SERVERS”

# 切换Leader
echo “Switching leader for $ZONE…”
obclient -h192.168.1.101 -P2881 -uroot@sys -p****** -e “ALTER SYSTEM SWITCH LEADER ZONE=’$ZONE’;”

# 逐个升级服务器
for SERVER in $SERVERS; do
echo “Upgrading $SERVER…”

# 停止observer
ssh admin@$SERVER “cd /ob/app/oceanbase && ./bin/observer -stop”

# 备份二进制
ssh admin@$SERVER “mv /ob/app/oceanbase/bin/observer /ob/app/oceanbase/bin/observer.bak”

# 复制新二进制
scp /soft/oceanbase-4.3.0.0/bin/observer admin@$SERVER:/ob/app/oceanbase/bin/
ssh admin@$SERVER “chmod +x /ob/app/oceanbase/bin/observer”

# 启动observer
ssh admin@$SERVER “cd /ob/app/oceanbase && ./bin/observer -c /ob/app/oceanbase/etc/observer.cnf”

# 等待启动
sleep 30

# 检查状态
STATUS=$(obclient -h$SERVER -P2881 -uroot@sys -p****** -e “SELECT STATUS FROM oceanbase.DBA_OB_SERVERS WHERE SVR_IP=’$SERVER’;” | grep -v STATUS)
if [ “$STATUS” = “ACTIVE” ]; then
echo “$SERVER upgrade success”
else
echo “$SERVER upgrade failed”
exit 1
fi
done

echo “$ZONE upgrade completed”

# 执行升级
$ ./ob_upgrade.sh zone1
$ ./ob_upgrade.sh zone2
$ ./ob_upgrade.sh zone3
$ ./ob_upgrade.sh zone4
$ ./ob_upgrade.sh zone5

# 总耗时：约6小时

4.3 OceanBase升级问题处理案例

升级过程中遇到的问题及处理方法：

# 问题1：upgrade_checker.py检查失败

[ERROR] Cluster has unfinished compaction

# 原因：有未完成的合并
# 解决：
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM MAJOR FREEZE;”
# 等待合并完成后再检查

# 问题2：升级后observer无法启动

[ERROR] Failed to start observer: incompatible data format

# 原因：数据格式不兼容
# 解决：
# 1. 回滚到原版本
$ mv /ob/app/oceanbase/bin/observer /ob/app/oceanbase/bin/observer.new
$ mv /ob/app/oceanbase/bin/observer.bak /ob/app/oceanbase/bin/observer
$ ./bin/observer -c /ob/app/oceanbase/etc/observer.cnf

# 2. 检查升级路径是否正确
# 3. 联系OceanBase技术支持

# 问题3：升级后性能下降

# 现象：升级后QPS下降20%
# 原因：新版本的默认参数与业务不匹配

# 解决：
# 1. 检查参数变化
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SHOW PARAMETERS LIKE ‘memory_limit’;”

# 2. 调整参数
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM SET memory_limit=’200G’;”

# 3. 收集统计信息
$ obclient -h192.168.1.101 -P2881 -ufgedu@fgedu_tenant -p -e “ANALYZE TABLE fgedu_order;”

# 问题4：升级后应用连接失败

# 现象：应用报错”Unknown character set”
# 原因：新版本默认字符集变化

# 解决：
# 1. 检查字符集设置
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “SHOW VARIABLES LIKE ‘character_set%’;”

# 2. 修改字符集
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e “ALTER SYSTEM SET character_set_server=’utf8mb4′;”

# 3. 重启应用连接池

生产环境建议：升级过程中遇到问题不要慌张，首先查看日志定位问题，然后根据错误信息采取相应措施。必要时可以回滚到原版本。更多学习教程公众号风哥教程itpux_com

Part05-风哥经验总结与分享

5.1 OceanBase版本升级最佳实践

# 版本升级最佳实践

1. 升级前准备
– 充分阅读Release Notes
– 在测试环境模拟升级
– 准备完整的备份
– 制定详细的升级计划
– 准备回滚方案

2. 升级过程
– 选择业务低峰期
– 严格按照升级步骤执行
– 密切监控集群状态
– 记录升级过程中的问题
– 保持与业务方的沟通

3. 升级后验证
– 验证版本号正确
– 验证基本功能正常
– 验证业务SQL正常
– 验证性能达标
– 持续监控一周

4. 风险控制
– 禁止在升级期间执行DDL
– 禁止在升级期间调整资源
– 保持网络稳定
– 准备应急处理方案

5. 文档记录
– 记录升级过程
– 记录遇到的问题
– 记录解决方法
– 更新运维文档

5.2 OceanBase升级检查清单

# 升级检查清单

## 升级前检查
– [ ] 确认当前版本和目标版本
– [ ] 确认升级路径支持
– [ ] 检查集群状态正常
– [ ] 检查合并状态为IDLE
– [ ] 检查租户状态正常
– [ ] 检查数据同步正常
– [ ] 执行全量备份
– [ ] 备份配置文件
– [ ] 运行upgrade_checker.py
– [ ] 准备升级包
– [ ] 通知业务方

## 升级中检查
– [ ] 设置enable_upgrade=true
– [ ] 运行upgrade_pre.py
– [ ] 逐个Zone升级
– [ ] 检查每个节点状态
– [ ] 检查数据同步
– [ ] 记录升级时间

## 升级后检查
– [ ] 运行upgrade_post.py
– [ ] 设置enable_upgrade=false
– [ ] 检查版本号
– [ ] 检查所有节点版本一致
– [ ] 验证基本SQL
– [ ] 验证事务
– [ ] 验证业务SQL
– [ ] 检查性能指标
– [ ] 恢复合并和负载均衡
– [ ] 通知业务方验证

## 升级后一周检查
– [ ] 检查集群稳定性
– [ ] 检查性能趋势
– [ ] 检查是否有新告警
– [ ] 收集业务反馈
– [ ] 更新运维文档

5.3 OceanBase升级常见问题

# 升级常见问题及解决

Q1: 升级前检查提示”Cluster has unfinished compaction”
A1: 执行ALTER SYSTEM MAJOR FREEZE触发合并，等待合并完成后再升级

Q2: 升级过程中可以执行DDL吗？
A2: 不可以。升级期间禁止执行CREATE/ALTER/DROP TABLE等DDL操作

Q3: 升级失败如何回滚？
A3: 停止升级流程，使用原版本二进制文件替换，重新启动observer

Q4: 升级后需要重启应用吗？
A4: 一般不需要，但建议验证应用连接和SQL执行正常

Q5: 滚动升级会影响业务吗？
A5: 理论上不影响，但可能有毫秒级延迟波动，建议在低峰期执行

Q6: 升级后性能下降怎么办？
A6: 检查参数设置，收集统计信息，必要时联系技术支持

Q7: 可以跨版本升级吗？
A7: 不可以跨大版本升级，必须按照支持的升级路径逐步升级

Q8: 升级后需要重新配置参数吗？
A8: 建议检查新版本参数默认值，根据业务需要调整

Q9: 升级过程中网络中断怎么办？
A9: 网络恢复后继续升级，如果超时可能需要重新开始

Q10: 升级后如何验证数据完整性？
A10: 可以使用checksum或抽样对比的方式验证关键表数据

风哥提示：版本升级是数据库运维的重要工作，必须谨慎对待。做好充分的准备工作，严格按照流程执行，遇到问题冷静处理，就能顺利完成升级任务。from OceanBase视频:www.itpux.com

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息