openGauss升级方案、版本、影响以及约束要求介绍

升级前必读

• 升级方案

• 升级前的版本要求（升级路径）

• 升级影响和升级约束

升级方案

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

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

当前支持的升级模式为就地升级和灰度升级。升级方式的策略又分为大版本升级和小版本升级。版本号不变的升级方式为小版本升级，否则就是大版本升级。

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

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

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

升级前的版本要求

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

表 1 升级前的版本要求（升级路径）

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

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.0.0之前的版本中使用了MOT表，则不支持升级到openGauss2.0.0版本。

• 升级过程中，请勿在当前机器上安装其他opengGauss数据库集群。