- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

GaussDB(DWS)线下纯软&ESL集群升级&补丁安装问题处理指南

Song~ 发表于 2023/09/21 14:57:16 2023/09/21

【摘要】升级&补丁过程常见问题，持续更新

1 升级基本原理

1.1 升级总体流程

升级总体流程包括：升级前巡检，升级前准备，升级集群，升级集群后操作。

升级前巡检：使用FusionInsight Tool Prober工具进行升级前检查，如果存在不满足项需要提前修复不满足项。不影响业务，建议放到时间升级窗之前处理，不占用正式升级时间窗。

升级前准备：运维人员按照升级指导书手动操作“升级前准备”各步骤。包括处理告警，部署升级工具等。不影响业务，建议放到升级时间窗之前处理，不占用正式升级时间窗。

升级集群：使用UpdateService升级工具自动化升级GaussDB(DWS)集群各个组件，是升级的核心步骤，需要停止业务。耗时2小时。

升级集群后操作：运维人员按照升级指导书手动操作“升级集群后操作”各个步骤。包括升级后检查，清理升级工具，升级客户端驱动等。耗时2小时。

升级时间窗内操作耗时4小时，预留紧急预案时间4小时。所以现网升级一般建议时间窗申请8小时。

1.2 日志路径

upds日志

/var/log/bigdata/update-service 主oms节点

Manager日志

/var/log/bigdata/controller 主oms节点

/var/log/bigdata/nodeagent 失败节点

数据库日志

/var/log/bigdata/mpp/upgrade 主cms节点

/var/log/Bigdata/mpp/omm/om/gs_upgradectl-xxxx.log 主cms节点

/var/log/Bigdata/mpp/omm/om/gs_local-xxxx.log 所有节点均有

1.3 隔离业务

老版本升级为离线升级(源版本不低于8.1.1，目标版本不低于8.1.3即可在线升级)，需要在升级变更前彻底隔离业务防止对升级过程造成干扰，导致升级失败。可从以下几个方面来隔离业务：

用PuTTY以omm用户登录后台任一个安装有MPPDB实例的节点注释白名单并重启cn。具体操作如下：

source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile

gs_ssh -c "hostname && if [ -f /srv/BigData/mppdb/data1/coordinator/pg_hba.conf ]; then cp -f /srv/BigData/mppdb/data1/coordinator/pg_hba.conf /srv/BigData/mppdb/data1/coordinator/pg_hba.conf_comment; fi "

gs_ssh -c "hostname && if [ -f /srv/BigData/mppdb/data1/coordinator/pg_hba.conf ]; then sed -i '/^[^#].*sha256.*/s/$.*$/#@#@#\1/g' /srv/BigData/mppdb/data1/coordinator/pg_hba.conf; fi "

gs_ssh -c "ps -ef |grep coo|grep -v grep|awk -F ' ' '{print \$2}'|xargs kill -9"

如果存在Database Manager应用，则进入Database Manager应用主页，点击Database Manager主页小卡片右上角的停止监控，暂时关闭Database Manager监控功能。
用PuTTY以omm用户登录后台任一个安装有MPPDB实例的节点，清理后台访问连接和应用连接。具体操作如下：

source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile

gs_ssh -c "ps ux |grep -w gsql |grep -v grep |awk '{print \$2}' |xargs -r kill -9"

gs_ssh -c "ps ux |grep -w ap_agent |grep -v grep |awk '{print \$2}' |xargs -r kill -9"

1.4 gs_upgradectl升级流程

gs_upgradectl升级总体上分为升级、回滚、提交三大块。

升级：将二进制文件和系统表升级到目标版本。详细过程较长，但从逻辑上可划分为三阶段：

1) 升级前置。主要就是检查升级的各项前提条件是否满足，备份各种配置文件和数据，调整集群配置已满足下一步做升级的条件；

2) 升级。首先将二进制文件替换为目标版本，然后拉起集群，完成系统表升级；

3) 升级后置。进行基本的检查，确保升级到目标版本后基本功能正常。

回滚：升级流程任意一步报错均会自动进入回滚流程。回滚时先检查正向升级流程走到哪个步骤，然后从该步骤开始逐步回退到升级前初始状态。

提交：主要就是清理升级过程中产生的临时文件以及各种备份文件，并将升级前调整的配置还原为升级前状态。一旦执行提交操作，则不能再回退。

1.5 备份系统表

备份系统表分两阶段：停集群前连接所有cn和主dn将系统表信息查询并保存在临时文件；停集群后根据临时文件中系统表信息查找并备份实际物理文件。

实际物理文件备份操作在所有节点、节点上所有实例间全并行执行。

单个实例系统表物理文件备份流程：

1) 如下清单中文件夹直接整文件夹备份

['global', 'pg_clog', 'pg_xlog', 'pg_multixact', 'pg_replslot', 'pg_notify', 'pg_subtrans', 'pg_twophase']

2) 遍历每个database：

如果是template0，则备份整个base目录即可；

对于其它database，遍历系统表清单，备份每张系统表的main/vm/fsm文件，以及pg_filenode.map、pg_internal.init。

1.6 升级系统表

升级系统表主要流程为：

1) 集群以升级模式启动；

2) 安装升级辅助函数；

3) 连接第一个cn并执行准备好的升级sql文件；

4) 停集群，以正常模式重新启动集群。

由上述流程可知，如果在升级系统表步骤执行升级sql报错，可排查第一个cn的pg_log日志及gs_local获取具体语句及报错信息。

1.7 回滚系统表

回滚系统表时先进行逻辑回滚，如果不行再进行物理回滚。逻辑回滚与升级系统表流程类似，只是sql文件是对应的回滚sql文件；物理回滚则是将前面备份的各种物理文件还原回来。物理回滚也是所有节点、节点上所有实例全并行执行。

2 升级问题定位思路

2.1 分析步骤

升级工程几个关键步骤有升级manager、升级集群前准备、升级集群、提交。如果过程中报错，日志分析一般顺序为：

/var/log/Bigdata/update-service/runlog/update-manager.log （日志报错前后有post rest请求类似INFO信息，查看controller日志）

->/var/log/Bigdata/controller/controller.log或controller_client.log

->/var/log/Bigdata/mpp/upgrade/upgrade.log

->/var/log/Bigdata/mpp/scriptlog/postinstall.log

->/var/log/Bigdata/mpp/omm/om/gs_upgradectl-xxxx.log

/var/log/Bigdata/mpp/omm/om/gs_local-xxxx.log

数据库升级相关日志分析详细步骤如下：

1、使用omm用户登录主CMS节点，进入/var/log/Bigdata/mpp/upgrade/目录下；

2、查看upgrade.log日志，搜索关键字“GAUSS_5”确认报错位置。

3、如果报错是gs_preinstall，则获取报错的节点并登陆该节点，查看$GAUSSLOG/om/gs_preinstall*.log日志，搜索关键字“GAUSS_5”确认报错的位置并获取具体报错原因。

4、如果报错是gs_upgradectl，则查看$GAUSSLOG/om/gs_upgradectl*.log日志，搜索关键字“GAUSS_5”确认报错的位置并获取具体报错原因。

5、如果报错位置提示各个节点的hostname，则为local脚本报错，需要登录报错的节点，查询该节点的$GAUSSLOG/om/gs_local*.log日志，再次查询关键字“GAUSS_5”确认报错位置，通过对应的错误码来定位详细错误原因。

2.2 常见升级问题

2.2.1 安装upds工具报错

分析：OS为麒麟V10，手动使用root用户解密，解密失败；排查tmp目录发现tmp目录存在t权限，去掉t权限之后，解密正常

解决方案：麒麟V10等欧拉系OS存在tmp目录t权限导致访问tmp目录文件异常的问题，变更前需要去掉t权限，变更后恢复t权限

2.2.2 升级前preinstall报错

分析：这个过程报错一般是系统rpm包进行过升级，导致部分rpm包安装过程的缺失对应依赖环境，导致安装失败

解决方案：手动安装失败的rpm包，找到其中无法安装的rpm包，若是因为依赖版本不一致，重新安装对应版本后重试，其他报错节点也同样安装，安装成功后重试

2.2.3 创建工程报错：未知错误

日志：/opt/huawei/Bigdata/update-Service/runlog/update-manager.log

分析：创建工程报错未知错误一般为上传的包与组件不匹配导致，一般是mppdb-monitor组件或DMS-controller组件，卸载组件后重新创建工程即可

查看组件包及版本：sh /opt/huawei/Bigdata/om-server/om/sbin/pack/queryPack.sh，卸载组件:cd ${BIGDATA_HOME}/om-server/om/sbin/pack；./unregister_pack.sh 部件名

2.2.4 验证升级前检查结果失败

分析：此步骤失败大都是巡检结果文件有问题，upds无法正常识别巡检结果文件，从而失败

解决方案：主管理节点执行find /opt/ -name CheckReport*，找到上传的巡检结果文件，手动删除并touch一个新的相同名称的空文件

2.2.5 升级manager进度15%时报错

分析：DeployOMServer步骤失败，查看/var/log/Bigdata/upgrade/upgrade.log，报错：ERROR: Failed to install httpd security certificate。

此类报错一般是由于openssl版本太高或各节点版本不一致导致，登到各节点上切换到omm用户执行ssh -V查看openssl版本，有个节点版本与其他节点不一致；
此节点未单独更新过openssl，故怀疑是环境变量污染导致，排查环境各个变量，发现该节点的/home/omm/.bash_profile中引入了mppdb的环境变量，修改该环境变量后重启该节点nodeagent后重新检查openssl版本恢复正常，重试继续升级

2.2.6 升级manager进度20%失败

分析：DeployPakcageByplatform失败，查看日志：/var/log/Bigdata/update-service/runlog/update-manager.log。日志打印ERROR：SSH catch anexception，此报错为互信问题，手动测试互信没有问题，查看omm用户的ssh密钥文件，发现生成的密钥文件没有加密字段，8.x版本manager强制使用加密密钥，需要重建互信

解决方案：参考产品文档'更新omm用户ssh密钥'章节手动重建所有节点互信后，重启所有节点ssh-sgent进程，测试验证互信没有问题后继续升级

异常密钥：

正常密钥：

2.2.7 升级manager进度40%失败

分析：DeployOMAgent步骤失败，查看失败节点的日志/var/log/Bigdata/upgrade/upgrade.log，验证目录失败。入参为/var/lib/sudo/Bigdata，但是验证打印结果未verify /var/log/lib/sudo/Bigdata path failed。

解决方案：这种目录不一致问题一般是环境上有人做了软链接，将/var/lib指向了/var/log/lib目录，整改软链接，将目录结构恢复正常即可

2.2.8 升级manager进度50%失败

分析：更新备oms失败，查看备oms节点的日志/var/log/Bigdata/upgrade/upgrade.log，报错无法绑定端口，这种一般为操作系统的ipv6协议栈未启用，8.x版本强制使用ipv6协议栈，manager6.5.1升级8.x时未开始ipv6协议栈导致升级失败

解决方案：排查OS是否已开启ipv6，sysctl -a | grep ipv6，若未开启ipv6，需要排查OS并开启ipv6，否则manager无法升级成功

2.2.9 升级集群前准备失败

分析：这种报错一般是升级时漏了步骤未更新sudo脚本，导致执行内核前置preinstall找不到执行脚本，按照升级方案执行更新sudo脚本后重试即可

2.2.10 升级集群前准备失败

与2.2.7章节一样的步骤报错失败。执行内核前置时失败。

分析：内核前置失败，登入集群第一个数据节点查看日志：/var/log/Bigdata/mpp/scriptlog/postinstall.log，报错执行gs_checkos检查未通过，后台手动执行gs_checkos -i A命令，查看异常项，执行gs_checkos -i B进行修复，修复后重试即可