openGauss升级指导书

2021-03-09 shine

前 言

概述

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

读者对象

本文档主要适用于升级的操作人员。操作人员必须具备以下经验和技能:

  • 熟悉当前网络的组网和相关网元的版本信息。
  • 有该设备维护经验,熟悉设备的操作维护方式。

升级前必读

升级方案

本节为指导用户选择升级方式。

用户根据openGauss提供的新特性和数据库现状,确定是否对现有系统进行升级。

当前支持的升级模式为就地升级和灰度升级。升级方式的策略又分为大版本升级和小版本升级。

用户挑选升级方式后,系统会自动判断并选择合适的升级策略。

就地升级:升级期间需停止业务进行,一次性升级所有节点。

灰度升级:灰度升级支持全业务操作,也是一次性升级所有节点。(openGauss1.1.0版本之后的版本支持该功能)

升级前的版本要求(升级路径)

openGauss升级版本要求如表1所示。

表 1 升级前的版本要求(升级路径)

版本

升级说明

openGauss1.0.1版本之前的版本

可以升级到openGauss1.0.1之前的任意版本

openGauss1.0.1版本

可以升级到openGauss1.1.0版本

openGauss1.1.0版本之后的版本

可以升级到openGauss1.1.0之后的任意版本

说明: 升级前版本,可以通过执行如下工具查看。

gsql -V | --version

升级影响和升级约束

升级过程需要注意以下事项。

  • 升级操作不能和扩容、缩容同时执行。
  • 不支持虚拟IP。
  • 升级过程中,不允许对wal_level,max_connections,max_prepared_transactions,max_locks_per_transaction这四个GUC参数的值进行修改。如果修改,会导致回滚后实例启动异常。
  • 建议在数据库系统空闲情况下进行升级,尽量避开业务繁忙的时间段(可按照经验判断,如节假日等)。
  • 升级前尽可能保证数据库正常。可以通过gs_om -t status查询,查询结果的cluster_state为Normal代表数据库正常。
  • 升级前保证数据库互信正常,可以在任意节点上,通过ssh hostname命令,连接另外一个节点进行验证。如果各机器间互连不用输入密码,说明互信正常(通常数据库状态正常时,互信一般都是正常的)。
  • 升级前后,数据库的部署方式(配置文件)不能发生变化。升级前会对部署方式进行校验,如果改变,会报错。
  • 升级前要保证操作系统处于健康状态,通过gs_checkos工具可以完成操作系统状态检查。
  • 就地升级需要停止业务,灰度升级支持全业务操作。
  • 数据库运行正常且主DN的数据完全同步到备DN。
  • 升级过程中不允许打开kerberos开关。
  • 请不要修改安装包中解压出来的version.cfg文件。
  • 如果升级过程中出现异常导致升级失败,需用户手动回滚,并且必须回滚成功后才能进行下一次升级。
  • 如果升级回滚成功后,再次升级成功,未提交阶段设置的GUC参数将失效。
  • 执行升级的过程中请不要手动设置GUC参数。
  • 灰度升级中,升级的时候都会产生不超过10s的业务中断
  • 升级过程中,必须保持内核版本与om版本一致才可执行om操作。这里的一致是指,内核代码和om代码都来自同一个软件包。如果执行了升级包的前置脚本却没有升级,或者升级回滚后没有执行基线包的前置脚本,就会造成内核代码和om代码的不一致。
  • 升级过程中如果系统表新增了字段,升级后通过\d命令将查看不到这些新增的字段。此时通过select命令可以查到这些新增的字段。
  • 升级需要guc参数enable_stream_replication=on,该参数为off时不允许升级。
  • 灰度升级中,业务并发要小于200并发读加200并发写的情况。
  • 若在openGauss2.1.0之前的版本中使用了MOT表,则不支持升级到openGauss2.1.0版本。
  • 执行gs_upgradectl -t auto-upgrade 之后,没有提交之前,不能执行快照生成,即升级过程中不能执行快照生成。

# 升级

升级流程

本章介绍升级到该版本的主要升级过程。

图 1 升级流程图

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

表 1 升级流程执行效率估计

步骤

建议起始时间

耗时(天/小时/分钟)

业务中断时长

备注

升级前准备与检查

升级操作前一天

约2~3小时。

对业务无影响。

升级前检查和备份数据、校验软件包等操作。

升级操作

业务空闲期

耗时主要集中在数据库的启动和停止以及每个database的系统表修改处。升级操作耗时一般不会超过30分钟。

与操作时长一致,一般不会超过30分钟。

依据指导书开始升级。

升级验证

业务空闲期

约30分钟。

与操作时长一致,约30分钟。

-

提交升级

业务空闲期

提交升级耗时一般不超过10分钟。

与操作时长一致,一般不超过10分钟。

-

升级版本回滚

业务空闲期

版本回滚耗时一般不会超过30分钟。

与操作时长一致,一般不会超过30分钟。

-

升级前准备与检查

升级前准备与检查清单

表 1 升级前准备清单

序号

升级准备项目项目

准备内容

建议起始时间

耗时(天/小时/分钟)

1

收集节点信息

收集到数据库涉及节点的名称、IP地址,root、omm用户密码等环境信息。

升级前一天

1小时

2

设置root用户远程登录

设置配置文件,允许root用户远程登录。

升级前一天

2小时

3

备份数据

参考《管理员指南》中的“备份与恢复”章节进行。

升级前一天

备份数据量和方案不同,耗时也不同

4

获取并校验升级包

获取升级软件包,进行完整性校验。

升级前一天

0.5小时

5

健康检查

使用gs_checkos工具完成操作系统状态检查。

升级前一天

0.5小时

6

检查数据库节点磁盘使用率

使用df命令查看磁盘使用率。

升级前一天

0.5小时

7

检查数据库状态

使用gs_om工具完成数据库状态检查。

升级前一天

0.5小时

说明: “耗时”依不同环境(包括现场数据量、服务器性能等原因)会存在一定差异。

收集节点信息

联系数据库系统管理员,获取数据库涉及节点的节点名称、节点IP地址。节点的root、omm用户密码等环境信息。如表1

表 1 节点信息

序号

节点名称

节点IP

root用户密码

omm用户密码

备注

1

-

-

-

-

-

备份数据

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

请参考《管理员指南》中的“备份与恢复”章节,完成数据的备份。

获取升级包

https://opengauss.org/zh/download.html在该网站获取想要升级的升级包。

健康检查

通过gs_checkos工具可以完成操作系统状态检查。

前提条件

  • 当前的硬件和网络环境正常。
  • 各主机间root互信状态正常。
  • 只能使用root用户执行gs_checkos命令。

操作步骤

  1. 以root用户身份登录服务器。
  2. 执行如下命令对服务器的OS参数进行检查。

    gs_checkos -i A
    

    检查服务器的OS参数的目的是为了保证数据库正常通过预安装,并且在安装成功后可以安全高效的运行。详细的检查项目请参见《工具参考》中的“服务端工具 > gs_checkos”工具的“表1 操作系统检查项”。

检查数据库节点磁盘使用率

建议数据库节点磁盘使用率低于80%时再执行升级操作。

检查数据库状态

本节介绍数据库状态查询的具体操作。

验证步骤

  1. 以数据库用户(如omm)登录节点,source环境变量。
  2. 执行如下命令查看数据库状态。

    gs_om -t status
    
  3. 保证数据库状态正常。

升级操作

介绍就地升级和灰度升级的详细操作。

操作步骤

  1. 以root身份登录节点。
  2. 创建新包目录。

    mkdir -p /opt/software/gaussdb_upgrade
    
  3. 将需要更新的新包上传至目录“/opt/software/gaussdb_upgrade”并解压。

  4. 进入安装包解压出的script目录下:

    cd /opt/software/gaussdb_upgrade/script
    
  5. 在就地升级或灰度升级前执行前置脚本gs_preinstall。

    ./gs_preinstall -U omm -G dbgrp  -X /opt/software/GaussDB_Kernel/clusterconfig.xml
    
  6. 切换至omm用户。

    su - omm
    
  7. 数据库状态正常时,使用如下命令进行就地升级或者灰度升级。

    示例一:使用gs_upgradectl脚本执行就地升级。

    gs_upgradectl -t auto-upgrade -X /opt/software/GaussDB_Kernel/clusterconfig.xml
    

    示例二:使用gs_upgradectl脚本执行灰度升级。

    gs_upgradectl -t auto-upgrade -X /opt/software/GaussDB_Kernel/clusterconfig.xml --grey
    

升级验证

本章介绍升级完成后的验证操作。给出验证的用例和详细操作步骤。

验证项目的检查表

表 1 验证项目的检查表

序号

验证项目

检查标准

检查结果

1

版本查询

查询升级后版本是否正确

-

2

健康检查

使用gs_checkos工具完成操作系统状态检查。

-

3

数据库状态

使用gs_om工具完成数据库状态检查。

-

升级版本查询

本节介绍版本查询的具体操作。

验证步骤

  1. 以数据库用户(如omm)登录节点,source环境变量。
  2. 执行如下命令查看所有节点的版本信息。

    gs_ssh -c "gsql -V"
    

检查升级数据库状态

本节介绍数据库状态查询的具体操作。

验证步骤

  1. 以数据库用户(如omm)登录节点。
  2. 执行如下命令查看数据库状态。

    gs_om -t status
    

    查询结果的cluster_state为Normal代表数据库正常。

提交升级

升级完成后,如果验证也没问题。接下来就可以提交升级。

说明: 一旦提交操作完成,则不能再执行回滚操作。

操作步骤

  1. 以数据库用户(如omm)登录节点。
  2. 执行如下命令完成升级提交。

    gs_upgradectl -t commit-upgrade  -X /opt/software/GaussDB_Kernel/clusterconfig.xml
    

升级版本回滚

本章介绍版本回滚方法。

操作步骤

  1. 以数据库用户(如omm)登录节点。
  2. 执行如下命令完成版本回滚(回滚内核代码)。回滚完成,如果需要保持内核和om代码的版本一致,可以执行一下旧包的前置命令(参见执行前置脚本gs_preinstall。)。

    gs_upgradectl -t auto-rollback  -X /opt/software/GaussDB_Kernel/clusterconfig.xml
    

    说明: - 如果数据库异常,需要强制回滚,可以使用如下命令。

       gs_upgradectl -t auto-rollback -X /opt/software/GaussDB_Kernel/clusterconfig.xml   --force
    
  3. 查看回滚之后的版本号。

    gs_om -V | --version
    

异常处理

如果升级失败,请按照如下方式进行处理:

  1. 排查是否有环境问题。

    如磁盘满、网络故障等,或者升级包、升级版本号是否正确。排除问题后,可以尝试重入升级。

  2. 如果没有发现环境问题,或者重入升级失败,需要收集相关日志,找技术支持工程师定位。

    收集日志命令:

    gs_collector –begin-time=’20200724 00:00’ –end-time=’20200725 00:00

    如果条件允许,建议保留环境。

【免责声明】本文仅代表作者本人观点,与本网站无关。本网站对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考,由此产生的所有法律责任均由读者本人承担。