印刻数据库

外观

OceanBase 大版本升级 ​

升级前准备 ​

1. 版本规划 ​

确定目标版本 ​

  • 从 OceanBase 官方网站获取目标大版本
  • 查看版本发布说明，了解版本变更内容
  • 评估版本变更对现有业务的影响

版本兼容性检查 ​

  • 检查目标版本与当前版本的兼容性
  • 检查应用程序与目标版本的兼容性
  • 检查第三方工具与目标版本的兼容性

2. 环境准备 ​

测试环境准备 ​

  • 创建与生产环境一致的测试环境
  • 在测试环境中验证升级过程和结果
  • 测试应用程序在目标版本上的兼容性

生产环境准备 ​

  • 确保生产环境硬件满足目标版本的要求
  • 检查生产环境操作系统和依赖库版本
  • 准备足够的磁盘空间用于升级

3. 数据备份 ​

全量备份 ​

sql
-- 创建全量备份
BACKUP TENANT <tenant-name>;

-- 验证备份完整性
SELECT * FROM oceanbase.GV$OB_BACKUP_VALIDATION;

增量备份 ​

sql
-- 创建增量备份
BACKUP TENANT <tenant-name> INCREMENTAL FROM LATEST FULL;

日志备份 ​

sql
-- 确保日志备份正常运行
SHOW BACKUP LOG STATUS;

4. 升级工具准备 ​

下载升级包 ​

bash
# 从官方网站下载升级包
wget https://mirrors.aliyun.com/oceanbase/community/stable/el/7/x86_64/oceanbase-ce-<target-version>.rpm

# 验证升级包完整性
md5sum oceanbase-ce-<target-version>.rpm

准备升级工具 ​

  • 确保 OBD 工具版本兼容
  • 准备好升级脚本和工具
  • 准备好回滚工具和脚本

升级流程 ​

1. 升级前检查 ​

集群状态检查 ​

sql
-- 查看集群状态
SHOW CLUSTER STATUS;

-- 查看节点状态
SELECT svr_ip, status, zone FROM oceanbase.GV$OB_SERVERS;

-- 查看分区副本状态
SELECT * FROM oceanbase.GV$OB_PARTITION_REPLICA WHERE status != 'NORMAL';

数据一致性检查 ​

sql
-- 检查数据一致性
ALTER SYSTEM CHECK DATA CONSISTENCY;

2. 执行升级 ​

升级方式选择 ​

  • 滚动升级：适用于部分大版本升级，停机时间短，但风险较高
  • 离线升级：适用于所有大版本升级，风险较低，但停机时间长
  • 灰度升级：先升级部分节点，验证后再升级其他节点

离线升级流程 ​

  1. 停止业务：停止所有访问 OceanBase 集群的业务
  2. 备份数据：确保所有数据已备份
  3. 停止集群：停止整个 OceanBase 集群
  4. 安装新版本：在所有节点上安装新版本包
  5. 升级数据：执行数据升级脚本
  6. 启动集群：启动 OceanBase 集群
  7. 验证升级：验证集群状态和数据完整性
  8. 恢复业务：恢复业务访问

具体操作 ​

bash
# 1. 停止集群
obd cluster stop <cluster-name>

# 2. 安装新版本包
yum localinstall -y oceanbase-ce-<target-version>.rpm

# 3. 升级数据
obd cluster upgrade <cluster-name> --target-version <target-version>

# 4. 启动集群
obd cluster start <cluster-name>

# 5. 查看升级状态
obd cluster display <cluster-name>

3. 升级 OBProxy ​

升级 OBProxy ​

bash
# 停止 OBProxy 服务
sudo systemctl stop obproxy

# 安装新版本包
yum localinstall -y obproxy-<target-version>.rpm

# 启动 OBProxy 服务
sudo systemctl start obproxy

# 验证 OBProxy 状态
sudo systemctl status obproxy

# 验证 OBProxy 版本
obproxy -v

升级后验证 ​

1. 集群状态验证 ​

基本状态检查 ​

sql
-- 查看集群状态
SHOW CLUSTER STATUS;

-- 查看节点状态
SELECT svr_ip, status, zone, build_version FROM oceanbase.GV$OB_SERVERS;

-- 查看分区副本状态
SELECT * FROM oceanbase.GV$OB_PARTITION_REPLICA WHERE status != 'NORMAL';

数据一致性验证 ​

sql
-- 检查数据一致性
ALTER SYSTEM CHECK DATA CONSISTENCY;

-- 验证数据完整性
SELECT * FROM oceanbase.GV$OB_DATA_CHECKSUM;

2. 功能验证 ​

基本功能验证 ​

sql
-- 执行基本 SQL 操作
SELECT 1;

-- 创建测试表并插入数据
CREATE TABLE test_upgrade (id INT PRIMARY KEY, name VARCHAR(100));
INSERT INTO test_upgrade VALUES (1, 'test');
SELECT * FROM test_upgrade;
DROP TABLE test_upgrade;

新功能验证 ​

  • 验证目标版本的新功能是否正常工作
  • 验证现有功能在目标版本上是否正常工作
  • 验证 API 兼容性

3. 性能验证 ​

性能测试 ​

bash
# 使用 sysbench 进行性能测试
sysbench oltp_read_write --mysql-host=<host> --mysql-port=<port> --mysql-user=<user> --mysql-password=<password> --mysql-db=<db> --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=<host> --mysql-port=<port> --mysql-user=<user> --mysql-password=<password> --mysql-db=<db> --tables=10 --table-size=1000000 --threads=64 --time=300 run

性能对比 ​

  • 对比升级前后的性能指标
  • 验证性能是否符合预期
  • 定位性能 regression

升级失败处理 ​

1. 升级失败原因分析 ​

查看升级日志 ​

bash
# 查看 OceanBase 日志
tail -f /home/admin/oceanbase/log/observer.log

# 查看 OBD 升级日志
obd cluster logs <cluster-name> observer

常见失败原因 ​

  • 版本兼容性问题
  • 数据格式不兼容
  • 配置参数不兼容
  • 硬件或资源不足
  • 网络连接问题

2. 回滚操作 ​

回滚流程 ​

  1. 停止集群：停止当前升级失败的集群
  2. 卸载新版本：卸载新版本包
  3. 安装旧版本：安装旧版本包
  4. 恢复数据：从备份中恢复数据
  5. 启动集群：启动旧版本集群
  6. 验证回滚：验证集群状态和数据完整性
  7. 恢复业务：恢复业务访问

具体操作 ​

bash
# 1. 停止集群
obd cluster stop <cluster-name>

# 2. 卸载新版本包
yum remove -y oceanbase-ce-<target-version>

# 3. 安装旧版本包
yum localinstall -y oceanbase-ce-<old-version>.rpm

# 4. 恢复数据
obd cluster restore <cluster-name> --backup-dir <backup-dir>

# 5. 启动集群
obd cluster start <cluster-name>

# 6. 验证回滚
obd cluster display <cluster-name>

升级后优化 ​

1. 配置优化 ​

调整配置参数 ​

  • 根据目标版本的最佳实践调整配置参数
  • 启用目标版本的新功能
  • 优化性能相关配置

2. 数据优化 ​

数据迁移和转换 ​

  • 迁移和转换不兼容的数据格式
  • 优化数据存储结构
  • 重建索引和统计信息

3. 应用优化 ​

应用程序调整 ​

  • 调整应用程序以适应目标版本的变化
  • 优化应用程序以利用目标版本的新功能
  • 修复应用程序与目标版本的兼容性问题

常见问题（FAQ） ​

Q1: 大版本升级需要多长时间？ ​

A1: 大版本升级的时间取决于多种因素，包括集群规模、数据量、硬件性能等。一般来说，大版本升级需要数小时到数天的时间，包括升级前准备、升级执行和升级后验证等阶段。

Q2: 大版本升级有哪些风险？ ​

A2: 大版本升级的风险包括：

  • 数据丢失或损坏
  • 业务中断
  • 应用程序兼容性问题
  • 性能 regression
  • 升级失败无法回滚

Q3: 如何降低大版本升级的风险？ ​

A3: 降低大版本升级风险的方法：

  • 在测试环境中进行充分的测试和验证
  • 制定详细的升级计划和回滚计划
  • 备份所有数据，确保数据安全
  • 选择合适的升级时间和方式
  • 准备充分的资源和人员
  • 逐步升级，先升级部分节点或功能

Q4: 大版本升级后如何处理兼容性问题？ ​

A4: 处理大版本升级后兼容性问题的方法：

  • 调整应用程序以适应目标版本的变化
  • 使用兼容性模式或兼容层
  • 修复应用程序中的兼容性问题
  • 逐步迁移应用程序到新的 API

Q5: 如何选择大版本升级的方式？ ​

A5: 选择大版本升级方式的考虑因素：

  • 业务需求：根据业务对停机时间的要求选择升级方式
  • 集群规模：大规模集群建议使用滚动升级或灰度升级
  • 风险承受能力：风险承受能力低的情况下建议使用离线升级
  • 版本特性：根据目标版本的特性选择合适的升级方式
  • 资源情况：根据可用的资源和人员选择升级方式