GaussDB(DWS)升级问题定位指南

1      升级基本原理

1.1      升级总体流程

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

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

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

升级集群：使用Update Tool升级工具自动化升级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      隔离业务

当前升级为离线升级，需要在升级变更前彻底隔离业务防止对升级过程造成干扰，导致升级失败。可从以下几个方面来隔离业务：

1.    用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"

2.    如果存在Database Manager应用，则进入Database Manager应用主页，点击Database Manager主页小卡片右上角的停止监控，暂时关闭Database Manager监控功能。

3.    用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日志获取具体语句及报错信息。

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/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      常见升级问题

1.      停止老集群失败

·           如果$GAUSSLOG/om/gs_upgradectl*.log日志中有错误码GAUSS_51610，则表示停止老集群错误；

·           停止老集群错误的原因可能包括XLOG追赶慢，UNLOG表太多等。

·           使用cm_ctl stop -m s && cm_ctl start方式重启集群，然后重试升级。

2.      备份元数据超时

如果$GAUSSLOG/om/gs_upgradectl*.log日志中有类似如下报错，说明备份元数据2h超时：

[FAILURE] pdccsbdspsvr051 Timed out, Killed by signal 9

[FAILURE] pdccsbdspsvr410 Timed out, Killed by signal 9

[FAILURE] pdccsbdspsvr408 Timed out, Killed by signal 9

3.      启动新集群失败

·           如果$GAUSSLOG/om/gs_upgradectl*.log日志中有错误码GAUSS_51607，则表示升级过程中启动集群错误；

·           根据gs_upgradectl*.log日志，获取启动集群的起止时间窗。

·           查看时间段内$GAUSSLOG/cm/{om_monitor | cm_agent | cm_server}目录下日志，确定是哪个实例在启动时间窗内未启动。

·           查看对应实例的$GAUSSLOG/pg_log/实例编号/ 下面的日志，获取具体的启动失败原因；

·           启动失败的主要原因包括：

                 i.          cgroup未挂载导致om_monitor拒绝启动集群；

               ii.          端口号被占用导致gaussdb启动失败；

              iii.          内核bug导致gaussdb频繁core dump等。

4.      证书原因导致升级后无法执行作业。

·           具体表现为升级提交时或者升级成功后无法执行DML、DDL操作；

·           具体报错为执行SQL，返回pooler相关错误；

·           如果开启了内部Kerberos认证，则可能为Kerberos认证问题（证书丢失，配置错误，证书过期等），排查并修复Kerberos问题或者关闭内部Kerberos认证；

·           也可能是通讯端口号sctp_port和control_port配置问题。查看执行作业的CN的pg_log日志，获取通讯失败的DN实例，然后打开DN实例的pg_log，搜索“Initialize Communication Layer”日志，查看该DN的通讯端口号是否和静态配置文件里面的一致。