GaussDB(DWS)升级问题定位指南(一)
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的通讯端口号是否和静态配置文件里面的一致。
- 点赞
- 收藏
- 关注作者
评论(0)