diff --git "a/content/zh/post/shine/figures/\345\215\207\347\272\247\346\265\201\347\250\213\345\233\276.png" "b/content/zh/post/shine/figures/\345\215\207\347\272\247\346\265\201\347\250\213\345\233\276.png" new file mode 100644 index 0000000000000000000000000000000000000000..61269ac24d324281efc6118cd27087a2d63dd345 Binary files /dev/null and "b/content/zh/post/shine/figures/\345\215\207\347\272\247\346\265\201\347\250\213\345\233\276.png" differ diff --git "a/content/zh/post/shine/openGauss\345\215\207\347\272\247\346\214\207\345\257\274\344\271\246.md" "b/content/zh/post/shine/openGauss\345\215\207\347\272\247\346\214\207\345\257\274\344\271\246.md" index 15864b035c69c1ba715e4afcab1c7e4e7082f854..4973377c603a83dd2fb805ac2cd08c32e7c1eb78 100644 --- "a/content/zh/post/shine/openGauss\345\215\207\347\272\247\346\214\207\345\257\274\344\271\246.md" +++ "b/content/zh/post/shine/openGauss\345\215\207\347\272\247\346\214\207\345\257\274\344\271\246.md" @@ -1,250 +1,579 @@ +++ -title = "openGauss升级指导书" -date = "2020-12-31" +title = "openGauss升级指导书" -tags = ["openGauss升级指导书"] +date = "2021-03-09" -archives = "2020-12" +tags = ["openGauss升级指导书"] -author = "shine" +archives = "2021-03" + +author = "shine" summary = "openGauss升级指导书" img = "/zh/post/shine/title/img28.png" -times = "8:30" +times = "15:40" +++ -**概述** +# 前 言 + +## 概述 + +本文档详细的描述了版本升级、回滚流程、以及具体的操作指导，同时提供了常见的问题解答及故障处理方法。 + +## 读者对象 + +本文档主要适用于升级的操作人员。操作人员必须具备以下经验和技能： + +- 熟悉当前网络的组网和相关网元的版本信息。 +- 有该设备维护经验，熟悉设备的操作维护方式。 + + +# 升级前必读 + + +## 升级方案 + +本节为指导用户选择升级方式。 + +用户根据openGauss提供的新特性和数据库现状，确定是否对现有系统进行升级。 + +当前支持的升级模式为就地升级和灰度升级。升级方式的策略又分为大版本升级和小版本升级。 + +用户挑选升级方式后，系统会自动判断并选择合适的升级策略。 + +就地升级：升级期间需停止业务进行，一次性升级所有节点。 + +灰度升级：灰度升级支持全业务操作，也是一次性升级所有节点。\(openGuass1.1.0版本之后的版本支持该功能\) + +## 升级前的版本要求（升级路径） + +openGauss升级版本要求如[表1](#table7961729)所示。 + +**表 1** 升级前的版本要求（升级路径） + + + + + + + + + + + + + + + + +

版本

+

升级说明

+

openGauss1.0.1版本之前的版本

+

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

+

openGauss1.0.1版本

+

可以升级到openGauss1.1.0版本

+

openGauss1.1.0版本之后的版本

+

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

+
+ + +>![](public_sys-resources/icon-note.gif) **说明：** +>升级前版本，可以通过执行如下工具查看。 +> +>``` +>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时不允许升级。 + +# # 升级 + + +## 升级流程 + +本章介绍升级到该版本的主要升级过程。 + +**图 1** 升级流程图 + + +>![](public_sys-resources/icon-note.gif) **说明：** +>本文档中描述的时间仅供参考，实际操作时间以现场情况为准。 + +**表 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小时

+
+ +>![](public_sys-resources/icon-note.gif) **说明：** +>“耗时”依不同环境（包括现场数据量、服务器性能等原因）会存在一定差异。 + +### 收集节点信息 + +联系数据库系统管理员，获取数据库涉及节点的节点名称、节点IP地址。节点的root、omm用户密码等环境信息。如[表1](#toc218487220)。 + +**表 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代表数据库正常。 + + +## 提交升级 + +升级完成后，如果验证也没问题。接下来就可以提交升级。 + +>![](public_sys-resources/icon-note.gif) **说明：** +>一旦提交操作完成，则不能再执行回滚操作。 + +#### 操作步骤 + +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 + ``` + + >![](public_sys-resources/icon-note.gif) **说明：** + >- 如果数据库异常，需要强制回滚，可以使用如下命令。 + > ``` + > gs_upgradectl -t auto-rollback -X /opt/software/GaussDB_Kernel/clusterconfig.xml --force + > ``` + +3. 查看回滚之后的版本号。 + + ``` + gs_om -V | --version + ``` - 本文档介绍了升级、回滚流程以及具体的操作指导，同时提供了常见的问题解答及故障处理方法。 -**修改记录** +# 异常处理 -文档版本|发布日期|修改说明 ---|--|-- -01|2020-12-31|第一次正式发布 +如果升级失败，请按照如下方式进行处理： -[toc] +1. 排查是否有环境问题。 -# 1升级前必读 -## 1.1升级方案 + 如磁盘满、网络故障等，或者升级包、升级版本号是否正确。排除问题后，可以尝试重入升级。 - 本文指导用户根据openGauss提供的新特性和数据库现状，确定是否对现有系统进行升级。 - 当前支持的升级模式为就地升级。 - 就地升级：升级期间需要停止业务，一次性升级所有节点。 +2. 如果没有发现环境问题，或者重入升级失败，需要收集相关日志，找技术支持工程师定位。 -## 升级路径 + 收集日志命令： -> 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-3小时|对业务无影响|升级前检查和备份数据、获取软件包等操作 -就地升级操作|业务空闲期|耗时主要集中在数据库的启动和停止以及每个database的系统对象的修改。升级操作耗时一般不会超过30分钟|与操作时常一致，一般不会超过30分钟|依据指导书执行升级，该操作要求暂停业务 -就地升级验证|业务空闲期|约30分钟|与操作时常一致，约30分钟|- -提交升级|业务空闲期|提交升级耗时一般不超过10分钟|与操作时常一致，约10分钟|- -就地升级版本回滚|业务空闲期|版本回滚耗时一般不会超过30分钟|与操作时常一致，约30分钟|- - -- 说明 -``` -本文档中的描述的时间仅供参考，实际操作时间以现场情况为准 -``` - -## 2.2 就地升级前准备与检查 -### 2.2.1 升级前准备与检查清单 - -> 表2-2-1 升级前准备清单 - - -序号|升级准备项目|准备内容|建议起始时间|耗时 ---|--|--|--|-- -1|手机节点信息|收集到数据库涉及节点的名称、IP地址、root、omm用户密码等环境信息|升级前一天|1小时 -2|备份数据|提前备份数据|升级前一天|2小时 -3|获取升级包|获取待升级包|升级前一天|0.5小时 -4|健康检查|使用gs_checkos工具完成操作系统状态检查|升级前一天|0.5小时 -5|检查数据库节点磁盘使用率|查看磁盘使用率|升级前一天|0.5小时 -6|检查数据库状态|使用gs_om工具完成数据库状态检查|升级前|0.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 验证项目的检查表 - -序号|验证项目|检查标准 ---|--|-- -1|版本查询|查询升级后版本是否正确 -2|健康检查|使用gs_checkos工具完成操作系统状态检查 -3|数据库状态|使用gs_om工具完成数据库状态检查 - -### 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' -如果条件允许，建议保留环境 -``` + **gs\_collector --begin-time=**'_20200724 00:00_' **--end-time=**'_20200725 00:00_' + 如果条件允许，建议保留环境。