content/zh/post/shine/openGauss升级指导书.md · angryart/blog

+++
title = "openGauss升级指导书"

date = "2020-12-31"

tags = ["openGauss升级指导书"]

archives = "2020-12"

author = "shine"

summary = "openGauss升级指导书"

img = "/zh/post/shine/title/img28.png"

times = "8:30"

+++

**概述**

本文档介绍了升级、回滚流程以及具体的操作指导，同时提供了常见的问题解答及故障处理方法。

**修改记录**

文档版本|发布日期|修改说明
--|--|--
01|2020-12-31|第一次正式发布

[toc]

# 1升级前必读
## 1.1升级方案

本文指导用户根据openGauss提供的新特性和数据库现状，确定是否对现有系统进行升级。
    当前支持的升级模式为就地升级。
    就地升级：升级期间需要停止业务，一次性升级所有节点。

## 升级路径

> openGauss的升级路径如表1-1所示

表1-1升级路径

版本|升级说明
--|--
openGauss1.0.1版本及之前的版本|可以升级到1.0.1之前的任意版本
openGauss1.0.1版本|升级到openGauss1.1.0之后的版本

>说明

升级前的版本可以使用如下命令查看：
    gsql -V | --version

## 升级影响和约束
>升级过程中需要注意以下事项
- 升级操作不能和节点替换、扩容、缩容同时执行
- 不支持虚拟IP
- 升级过程中，不允许对wal_level, max_connection, max_prepared_transactions, max_locks_per_transaction这四个GUC参数的值进行修改。如果修改，会导致回滚后，集群启动异常
- 需要在数据库无业务的情况下进行升级
- 升级前保证集群正常。可以通过gs_om -t status查询，查询结果的cluster_state为normal代表数据库正常
- 升级前保证数据库互信正常
- 升级前后，数据库的部署方式（配置文件）不能发生变化
- 升级前要保证操作系统处于健康状态，通过gs_checkos工具可以完成操作系统状态检查
- 数据库运行正常且主DN的数据完全同步到备DN
- 升级过程中不允许打开kerberos开关
- 不要擅自修改安装包中解压出来的version.cfg文件
- 如果升级过程中出现异常导致升级失败，需要用户手动执行回滚，必须回滚成功才能执行下一次升级
- 升级回滚成功后，升级期间设置的GUC参数将失效，建议用户升级过程中尽量不要手动修改guc参数值，对修改的值在升级操作执行完成后建议进行double check
- 升级回滚成功后，若想执行其他om操作，需要保证om代码与内核代码版本一致。使用gsql -V(查询内核版本)和gs_om -V(查询om版本)进行查询对比
- 升级成功后，若系统表相对于老版本新增了字段，使用\d命令查看表时，无法查看到新增字段，select表可以查到
- 升级前需要设置guc参数enable_stream_replication值为on

# 2 就地升级说明

## 2.1 就地升级流程

>升级流程执行时间估计

表2-1 升级流程执行时间估计

- 说明
```
本文档中的描述的时间仅供参考，实际操作时间以现场情况为准
```

## 2.2 就地升级前准备与检查
### 2.2.1 升级前准备与检查清单

> 表2-2-1 升级前准备清单

### 2.2.2 收集节点信息

```
联系数据库管理员，获取数据库涉及节点的名称、IP地址、root、omm用户密码等环境信息
```
### 2.2.3 备份数据

```
升级一旦失败，有可能会影响到业务的正常开展。提前备份数据，就可以在风险发生后，尽快恢复业务
```
### 2.2.4 获取升级包

单机安装包超链接跳转获取安装包 
[安装包](https://opengauss.org/zh/download.html)

### 2.2.5 健康检查
```markdown
通过gs_checkos工具可以完成操作系统健康检查
```
> 前提条件
- 当前的硬件和网络环境正常
- 各主机间root互信状态正常
- 只能使用root用户执行gs_checkos命令
> 操作步骤
- 步骤1 以root用户身份登录服务器
- 步骤2 执行如下命令对服务器的OS参数进行检查
```markdown
gs_checkos -i A
检查服务器的OS参数的目的是为了保证数据库正常通过预安装，并且在安装成功后可以安全高校的运行
```
### 2.2.6 检查数据库节点磁盘使用率
```markdown
数据库节点磁盘使用率低于80%才可以执行升级
```

### 2.2.7 检查数据库状态
> 验证步骤
- 步骤1 以数据库用户登录节点
- 步骤2 执行如下命令查看数据库状态
```markdown
gs_om -t status
```
- 步骤3 保证数据库状态正常

## 2.3 执行就地升级操作
> 操作步骤
- 步骤1 以root用户登录节点
- 步骤2 创建新包目录
```markdown
mkdir -p /opt/software/gaussdb_upgrade
```
- 步骤3 将待升级的安装包上传至目录"/opt/software/gaussdb_upgrade"并解压
- 步骤4 进入安装包解压的script目录下
```markdown
cd /opt/software/gaussdb_upgrade/script
```
- 步骤5 执行前置脚本gs_preinstall
```markdown
./gs_preinstall -U omm -G dbgrp -X /opt/software/open_gauss/clusterconfig.xml
```
- 步骤6 切换至omm用户
```markdown
su - omm
```
- 步骤7 数据库状态正常时，执行以下命令进行升级
```markdown
gs_upgradectl -t auto-upgrade -X /opt/software/open_gauss/clusterconfig.xml
```
## 2.4 就地升级验证
### 2.4.1 验证项目的检查表
> 表2-1 验证项目的检查表

### 2.4.2 就地升级版本查询
> 操作步骤
- 步骤1 以数据库用户登录节点
- 步骤2 执行如下命令查看所有节点的内核版本信息
```
gs_ssh -c "gsql -V"
```

### 2.4.3 检查就地升级数据库状态
> 验证步骤
- 步骤1 以数据库用户登录节点
- 步骤2 执行如下命令查看数据库状态
```markdown
gs_om -t status
查询结果的cluster_state为Normal代表数据库状态正常
```

## 2.5 提交升级
- 说明 升级一旦提交，则不能执行回滚操作
```markdown
升级完成后，如果验证没有问题，接下来就可以提交升级
```
> 操作步骤
- 步骤1 以数据库用户登录节点
- 步骤2 执行如下命令完成升级提交
```markdown
gs_upgradectl -t commit-upgrade -X /opt/software/open_gauss/clusterconfig.xml
```

## 2.6 就地升级版本回滚
> 操作步骤
- 步骤1 以数据库用户登录节点
- 步骤2 执行如下命令完成内核版本回滚
```markdown
gs_upgradectl -t auto-rollback -X /opt/software/open_gauss/clusterconfig.xml
如果数据库状态异常，可以使用强制回滚命令
gs_upgradectl -t auto-rollback -X /opt/software/open_gauss/clusterconfig.xml --force
```
- 步骤3 回滚om版本
```markdown
为了保持内核与om版本一致，需要执行以下旧包的前置命令
```
- 步骤4 检查回滚后的内核与om版本
```markdown
om版本：gs_om -V | --version
内核版本：gsql -V | --version
```
# 3 异常处理
```markdown
如果升级失败，请按照如下方式进行处理
```
- 步骤1 检查是否有环境问题
```markdown
如磁盘满、网络故障等，或者升级包不正确，排查问题后，可以进行升级重入操作
```
- 步骤2 如果没有发现环境问题，或者重入升级失败，需要收集相关日志，找技术支持工程师定位。
```markdown
收集日志命令
gs_collector --begin-time='20201231 00:00' --end-time='20201231 12:00'
如果条件允许，建议保留环境
```

angryart/blog

About

Releases

Contributors

Activities