MogDB/openGauss 2.0.1 升级到 3.0

• 升级方案
• gs_upgradectl 介绍
• 数据库升级

随着数据库版本迭代，新特性增加，功能增强，总有一个“点” 会打动你那颗想要做数据库升级的心，但并不是所有的业务系统所使用的数据库都适合升级，需要DBA和业务开发人员充分配合，做好程序适配工作，确定数据库升级的必要性，操作有风险，升级需谨慎

• 禁止直接对生产数据库升级，需要开发测试环境升级后稳定运行一段时间再考虑生产
• 确定好升级方案，预留充足的数据库升级窗口期

升级方案

数据库小版本升级也可以参考补丁升级
数据库大版本升级，常用的升级方式有三种，分别是导入导出、升级工具gs_upgradectl及逻辑复制

• 导入导出：停业务时间与数据量成正比，操作简单风险小
• 升级工具：停业务时间短，但需要对工具各个参数熟练掌握
• 逻辑复制：与导入导出的方式配合使用，提前将历史数据迁移，也可以使用异构数据库数据传输

gs_upgradectl 介绍

本文主要介绍通过gs_upgradectl做版本升级，目前支持就地升级和灰度升级两种升级模式

• 就地升级：升级期间需停止业务进行，一次性升级所有节点。
• 灰度升级：灰度升级支持全业务操作（会产生不超过10s的业务中断），一次性升级所有节点（MogDB2.0.0之后支持）

使用限制

• 升级操作不能和扩容、缩容同时执行。升级前后，数据库的部署方式（配置文件）不能发生变化。
• 不支持虚拟IP。
• 执行升级的过程中请不要手动设置GUC参数。升级前需要确保guc参数enable_stream_replication=on。
• 建议在数据库系统空闲情况下进行升级，尽量避开业务繁忙的时间段（可按照经验判断，如节假日等）。
• 升级前尽可能保证数据库正常。且主DN的数据完全同步到备DN。可以通过gs_om -t status查询。
• 升级前保证数据库互信正常，可以在任意节点上，通过ssh hostname命令，连接另外一个节点进行验证。
• 升级前要保证操作系统处于健康状态，通过gs_checkos工具可以完成操作系统状态检查。
• 请不要修改安装包中解压出来的version.cfg文件。
• 如果升级过程中出现异常导致升级失败，需用户手动回滚，并且必须回滚成功后才能进行下一次升级。
• 升级过程中，必须保持内核版本与om版本一致才可执行om操作。即内核代码和om代码都来自同一个软件包。
• 升级过程中如果系统表新增了字段，升级后通过d命令将查看不到这些新增的字段。此时通过select命令可以查到这些新增的字段。
• 灰度升级中， 业务并发要小于200并发读加200并发写的情况。
• 建议数据库节点磁盘使用率低于80%时再执行升级操作。

命令语法

[om1@node1 ~]$ gs_upgradectl --help gs_upgradectl is a utility to upgrade a cluster. Usage: gs_upgradectl -? | --help gs_upgradectl -V | --version gs_upgradectl -t chose-strategy [-l LOGFILE] gs_upgradectl -t auto-upgrade -X XMLFILE [-l LOGFILE] [--grey] gs_upgradectl -t auto-rollback -X XMLFILE [-l LOGFILE] [--force] gs_upgradectl -t commit-upgrade -X XMLFILE [-l LOGFILE] General options: -?, --help Show help information for this utility, and exit the command line mode. -V, --version Show version information. -t Subcommand for upgrade. It can be chose-strategy, auto-upgrade, auto-rollback, commit-upgrade. -X Path of the XML configuration file of the later version cluster. -l Path of log file. --force Force to rollback when cluster status is not normal --grey Use grey-binary-upgrade