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

举报
召走小子 发表于 2020/10/29 22:18:53 2020/10/29
【摘要】 介绍了GaussDB(DWS)升级的基本原理及常见问题定位方法。

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

1      升级基本原理

1.1      升级总体流程

                                               image.png

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

升级前巡检:使用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升级流程

image.png

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的通讯端口号是否和静态配置文件里面的一致。


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。