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

网友投稿 906 2022-05-29

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

3.4      升级集群

3.4.1     升级集群(9%)报错sssd服务启动失败

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

升级集群(9%)报错sssd服务启动失败

查看报错的详细信息

查看update-manager的日志,提示ldapclient失败

查看ldapclient的日志

手动拉起sssd服务失败

触发了os的dbus和systemd的bug导致临时资源不可用。

重启有问题节点的OS(确认manager节点正常)。

3.4.2     升级集群到35%报错,启动kerberosServer报错

【GaussDB(DWS)】【C80SPC600->C80SPC800】

升级集群到35%报错,启动kerberosServer报错

未执行preset导致环境上sudo脚本无config_coredump_dir方法。

按升级指导书重新执行preset步骤,然后界面重试。

3.4.3      升级集群(42%)报错 The cluster's static configuration does not match the new configuration file,cn个数前后台不一致

【GaussDB(DWS)】【C80SPC312->8.0.0.1】

升级集群(42%)报错 The cluster's static configuration does not match the new configuration file

后台有3个cn 前台只有2个 前后台cn不一致

现场之前在前台做增删cn,失败了未做处理,导致前后台配置不一致。

手动修改主cms_server节点的mppdb-install-config.xml文件,增加cn配置信息,保持与后台集群实际情况一致,然后界面重试。

3.4.4      升级集群(42%)报错 The cluster's static configuration does not match the new configuration file,配置完全错乱

【GaussDB(DWS)】【C80SPC311->C80SPC800】

升级集群(42%)报错 The cluster's static configuration does not match the new configuration file :

通过发回来的静态配置文件和xml文件对比,6个数据节点 从现场反馈的集群状态看前三个节点成一个环,后3个节点成一个环,现在升级时下发的xml文件里面是6个节点整体成一个环了 配置完全对不上。

查看C80SPC600目录的xml文件是与静态配置文件一致,手动将该xml文件拷贝到800的xml文件目录(集群所有节点),前台重试正常。升级完成后在FI前台做下同步配置。

升级时FIM下发的xml文件成环信息与集群实际情况不符,导致升级失败。

手动将C80SPC600目录的xml文件拷贝到800的xml文件目录(集群所有节点),前台重试正常。升级完成后在FI前台做下同步配置。

3.4.5      升级集群失败(42%):报SCP /opt/huawei/Bigdata/mppdb/gtm/gtm.control:Permission denied

【GaussDB(DWS)】【C80SPC300->8.0.0.1】

升级集群失败(42%):报SCP  /opt/huawei/Bigdata/mppdb/gtm/gtm.control_b: Permission denied

由于现场在备份 /opt/huawei/Bigdata/mppdb/gtm/gtm.control文件使用root用户备份,导致 /opt/huawei/Bigdata/mppdb/gtm/目录下含有非omm用户的文件。

修改文件gtm.control_b 属主为omm:wheel规避。

3.4.6      升级集群(42%)报错报读alarm_Item.conf文件失败

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

C80SPC300在升级8.0.0.1的过程中,在升级集群阶段报Failed to read: /opt/huawei/Bigdata/mppdb/core/bin/alarmItem.conf文件失败,如下:

检查报错节点的alarmItem.conf文件,发现文件里只有告警的信息,缺少alarm_component配置项,导致无法解析文件。

将cn数据目录下的postgrs.conf文件中的alarm_component=/opt/huawei/Bigdata/mppdb/snas_cm_cmd加入到报错节点的

/opt/huawei/Bigdata/mppdb/core/bin/alarmItem.conf文件末尾,保存后再update-sevice点击重试。

3.4.7      升级集群到87%报错MPPDB升级服务数据报错

【GaussDB(DWS)】【C80SPC600->C80SPC800】

升级集群到87%报错MPPDB升级服务数据报错:

查看日志/var/log/Bigdata/mpp/upgrade/upgrade.log,报错:

stopMPPDB failed.

从日志上下文分析,此时数据库内核升级已完成,是在后续停止集群时报错。

使用gs_ssh -c "ps ux |grep mppdb"  查看未正常停止的进程是一个cn实例

登录该实例所在节点kill -9 pid将该cn杀掉,然后界面点击重试。

3.4.8      升级集群到89%报错备份元数据2h超时

【GaussDB(DWS)】【C80SPC600->C80SPC800】

某局点升级集群到89%报错备份元数据步骤超时失败:Timed out, Killed by signal 9

C80以上版本采用就地升级方式,期间会备份各个实例的元数据,元数据量越大备份时间越长,且备份超时时间为2h,当实例元数据特别大,备份时间超过2h,就会导致超时报错回滚。

登录主cm_server节点,手动调长2h超时时间为4h后重试

${BIGDATA_HOME}/FusionInsight_MPPDB_V100R002C80SPC800/install/FusionInsight-MPPDB-2.8.0/package/MPPDB/script/util/Common.py

TIMEOUT_PSSH_INPLACE_UPGRADE = 7200  改为  TIMEOUT_PSSH_INPLACE_UPGRADE = 14400

3.4.9      升级集群(89%)报错update catalog failed

【GaussDB(DWS)】【C80SPC311->C80SPC800】

升级集群89%步骤报错update catalog failed:

分析报错09节点的gs_local日志,报错为连接丢失

查看第一个cn的pg_log日志,发现当时有客户业务还在跑。

现场没有按照升级指导书执行禁用白名单隔离业务步骤,升级过程中仍然有业务接入,导致升级执行sql超时失败。

待报错回滚后,按照升级指导书禁用白名单隔离业务,然后重新执行升级。

3.4.10    升级集群失败,mppdb升级服务数据报错

【GaussDB(DWS)】【C80SPC600->C80SPC800】

升级集群在启动新集群阶段超时,过程中查看集群状态主备dn均已启动,从备dn未启动:

排查system-call日志有报错max_wal_senders must be less than max_connections

排查从备实例postgresql.conf配置文件,max_wal_senders和max_connections参数值均为100

查看日志

max_wal_senders值配置不合理导致从备dn启动失败。

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

将max_wal_senders 值改为默认值 4然后重试。

3.4.11    升级集群过程中报错The value 256 is outside the valid range for parameter "max_coordinators"

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

在C80SPC300升级8.0.0.1的过程中,在升级集群阶段报错,报错为The value 256 is outside the valid range for parameter "max_coordinators",如下:

max_coordinators设置过大导致。

将max_coordinators修改为默认值10,在upds页面重试。

3.4.12    升级集群在启动新集群阶段所有备dn都是pending状态,启动超时

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

在C80SPC300在升级8.0.0.1,在升级集群阶段所有备dn都是pending状态,导致集群无法正常启动,升级失败

查看备dn的日志,有端口被使用的报错:Cannot assign requested address.Maybe port 25518 is used,run 'netstat -anop |grep 25518' or 'lsof -i:25518',具体如下:

查询端口,未被占用

查询备dn的postgresql.conf文件,确认listen_addresses和local_bind_address不一致,如下:

检查报错节点的alarmItem.conf文件,发现文件里只有告警的信息,缺少alarm_component配置项,导致无法解析文件。

将所有备dn的local_bind_address修改的和listen_addresses一致,然后在页面点击重试。

3.4.13    升级集群在启动新集群阶段cn启动失败

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

升级集群在启动新集群阶段cn启动失败

lvs的浮动ip没有和cn绑定导致,初步判断是lvs的启动没有写入操作系统启动项导致集群CN启动失败。

1.以root用户身份登录服务器,执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量;

2.执行gs_loadbalance更新负载均衡配置

gs_loadbalance -t reload -U omm -X  ${BIGDATA_HOME}/FusionInsight_MPPDB_8.0.0/*_*_MPPDBServer/etc/mppdb-install-config.xml   --lvs-addr=xxx

3.4.14    升级集群在启动新集群阶段cm_server启动失败

【GaussA 8.0.0.1】【C80SPC305->8.0.0.1】

升级集群在启动新集群阶段cm_server启动失败

查看主cms节点:/var/log/Bigdata/mpp/omm/om/gs_upgradectl*.log日志,有集群启动失败的报错

查看集群状态,有个备cms节点没拉起来,如下:

查看该节点的cm_agent日志,有如下报错:

该节点的cm_server.pid文件为root用户,删除后在界面重试正常。

cm_server.pid为root用户导致备cm_server没拉起来,集群启动失败。

手动删除cm_server.pid后正常拉起,前台重试正常。

3.4.15    升级集群在启动新集群阶段cn、dn处于down unknown状态启动失败

【Gauss A C80SPC800】【C80SPC208->C80SPC800】

升级集群在启动新集群阶段cn、dn处于down unknown状态启动失败。查看失败节点的system-call日志,有报错FATAL: invalid value for parameter "max_stack_depth":2048

操作系统stack size值设置2048,小于最低要求3072导致cn、dn启动报错。

修改操作系统的stack size值,并kill 节点上om_monitor、nodeagent进程使得进程中的值也生效,然后界面重试。

1、修改操作系统的stack size值

修改/etc/security/limits.conf中stack的soft值为8192 如下所示

*       soft    stack   8192

*       hard    stack   8192

2、kill om_monitor、nodeagent进程

ps -ef |grep om_monitor |grep -v grep

ps -ef |grep nodeagent |grep -v grep

kill -9 pid  --pid替换为上面查到的om_monitor、nodeagent进程pid

3、确认om_monitor、nodeagent进程已被正常拉起且stack size值刷新为修改后的值

ps -ef |grep om_monitor |grep -v grep

ps -ef |grep nodeagent |grep -v grep

cat /proc/pid/limits   --pid替换为上面查到的om_monitor、nodeagent进程pid

3.4.16    C80SPC310升级8.0.0.1在升级集群阶段,报Can not found sequence value in GTM

【GaussA 8.0.0.1】【C80SPC310->8.0.0.1】

集群c80spc310升级8.0.0.1在升级集群阶段,报Can not found sequence value in GTM,如下:

由于8.0以前版本的seq在gtm上存储的信息比较多,alter操作等将会导致gtm上的sequence信息残留以及有可能出现gtm上sequence丢失。

当gtm中的sequence信息与cn中sequence信息不一致时,就会在启动集群阶段报错,具体分为如下两种情况:

1)GTM中的sequence比CN上的少导致在升级过程中对老的sequence生成sequence时在gtm.control文件和gtm.sequence文件中查找不到报错;

2)GTM中有sequence,而CN上没有sequence导致gtm.sequence文件没有更新,使用新二进制读取老格式的数据报错。

所有GTM上的sequence需要从数据库的CN去恢复,查找所有使用该sequence的表,取最大值+20000当做该sequence修复后的当前值。

1)在所有数据库上创建以下函数

create or replace procedure find_seq(dbname text)

as

seq_name    varchar(1000);

tablename   varchar(1000);

columnname  varchar(1000);

schemanname varchar(1000);

schmaname   varchar(1000);

rel_oid     Oid;

adnum       int;

cur_max_seq int;

max_seq     int;

start_value bigint;

increment_by bigint;

max_value bigint;

min_value bigint;

cache_value bigint;

is_cycled  bool;

is_cycled_str char(1);

is_called  bool;

is_called_str char(1);

type ref_cur_type is ref cursor;

my_cur ref_cur_type;

my_cur_seq_name ref_cur_type;

my_cur_rel_att_name ref_cur_type;

my_cur_max_seq_num ref_cur_type;

my_seq_info ref_cur_type;

sqlstr varchar(1000);

sqlstr2 varchar(2560);

sqlstr3 varchar(2560);

sqlstr4 varchar(2560);

begin

open my_cur for 'select c.relname, n.nspname from pg_class c, pg_namespace n where c.relnamespace = n.oid AND c.relkind = ''S''';

fetch my_cur into seq_name, schmaname;

while my_cur%found loop

-- dbms_output.put_line(seq_name);

max_seq = 0;

sqlstr='select adrelid, adnum from pg_attrdef where adsrc like ''%' || seq_name || '%''';

open my_cur_seq_name for sqlstr;

fetch my_cur_seq_name into rel_oid, adnum;

while my_cur_seq_name%found loop

-- dbms_output.put_line('-> ('||rel_oid || ' , ' || adnum || ')');

cur_max_seq = 0;

sqlstr2  = 'select c.relname as tablename, a.attname, n.nspname as columname from pg_class c, pg_attribute a, pg_namespace n where c.relnamespace = n.oid and c.oid = a.attrelid and a.attrelid = ' || rel_oid || ' and a.attnum = ' || adnum || ';';

open my_cur_rel_att_name for sqlstr2;

fetch my_cur_rel_att_name into tablename, columnname, schemanname;

while my_cur_rel_att_name%found loop

--     dbms_output.put_line('-> ('|| tablename || ' , ' || columnname || ')');

sqlstr3 = 'select max(' || columnname || ') from ' || schemanname || '.' ||tablename || ';';

open my_cur_max_seq_num for sqlstr3;

fetch my_cur_max_seq_num into cur_max_seq;

if (cur_max_seq > max_seq) then

max_seq = cur_max_seq;

end if;

close my_cur_max_seq_num;

fetch my_cur_rel_att_name into tablename, columnname;

end loop;

close my_cur_rel_att_name;

fetch my_cur_seq_name into rel_oid, adnum;

end loop;

close my_cur_seq_name;

-- dbms_output.put_line(seq_name || ' max value : ' || max_seq);

sqlstr4 = 'select start_value, increment_by, max_value, min_value, cache_value, is_cycled, is_called from ' || schmaname || '.' || seq_name;

open my_seq_info for sqlstr4;

fetch my_seq_info into start_value, increment_by, max_value, min_value, cache_value, is_cycled, is_called;

while my_seq_info%found loop

if (is_cycled) then

is_cycled_str = 't';

else

is_cycled_str = 'f';

end if;

is_called_str = 't';

max_seq = max_seq + 20000;

dbms_output.put_line(dbname || '.'|| schmaname || '.' ||seq_name || '\00' || E'\t' || max_seq || E'\t' || start_value || E'\t' || increment_by || E'\t' || min_value || E'\t'|| max_value || E'\t' || is_cycled_str || E'\t' || is_called_str || E'\t' || '1');

fetch my_seq_info into start_value, increment_by, max_value, min_value, cache_value, is_cycled, is_called;

end loop;

close my_seq_info;

fetch my_cur into seq_name, schmaname;

end loop;

close my_cur;

end;

/

2)获取所有数据库列表

source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile

gsql -p 25308 postgres -r -t -c "select datname from pg_database where datname not in ('template1', 'template0', 'template2', 'information_schema');" > datname.txt

3)生成新的sequence信息

cat datname.txt | while read LINE

do

if [ -z "$LINE" ]; then

echo "skip"

else

gsql -p 25308 $LINE -r -c "call find_seq('$LINE');" 2>gtm_contrl.txt.$LINE

fi

done

4)停止主备gtm(主备两个节点)

cm_ctl stop -n nodeid -D gtmpath

5)重建gtm.control文件

1. 备份gtm.control文件

2. 保存gtm.control文件的前3行信息

head -n 3 gtm.control > gtm.control.tmp

3. sequence 同步到gtm.control.tm

cat datname.txt | while read LINE

do

if [ -z "$LINE" ]; then

echo "skip"

else

cat gtm_contrl.txt.$LINE >> gtm.control.tmp

fi

done

6)发送gtm.control.tmp到gtm的主备目录

scp gtm.control.tmp ...

7)启动gtm节点(主备两个节点)

cm_ctl start -n nodeid -D datapath

3.4.17    升级集群在确认阶段报错静态配置文件不匹配

【GaussA 8.0.0.1】【C80SPC300->8.0.0.1】

在升级确认时报错,如下:

查看主cms节点:/var/log/Bigdata/mpp/omm/om/gs_upgradectl*.log,有报静态配置文件不一致的报错:

查看对应报错节点的/opt/huawei/Bigdata/FusionInsight_MPPDB_*/*_MPPDBServer/etc/mppdb-install-config.xml对应的cooNum为3个,但是通过cm_ctl query -Cv查出来的cn个数为2个

此集群之前应该有做过删除cn的操作,前后台配置不一致,手动修改该xml文件,将对应的节点cooNum从1改为0,然后在界面重提通过。

确认成功后,在FI界面找到对应的节点的实例,将cn配置从1改为0,保存后正常,前后台配置一致。

手动修改该xml文件,将对应的节点cooNum从1改为0,然后在界面重提通过。

确认成功后,在FI界面找到对应的节点的实例,将cn配置从1改为0,保存后正常,前后台配置一致。

3.4.18    DWS升级8.0过程中更新系统表失败

【DWS】【8.0.0】

dws集群升级8.0过程中更新系统表失败,日志中报错用户名或密码无效:

带sequence的集群升级系统表过程中会涉及切换database,dws切换database需要交互式输入密码,导致升级系统表失败。

设置cn dn免密登录后重试

gs_guc set -Z coordinator -Z datanode -N all -I all -c 'local   all         all    trust'

3.5      升级后验证

3.5.1      升级C80SPC800后sql on hadoop配置文件被manager刷新重置

【GaussDB(DWS)】【C80SPC600->C80SPC800】

某局点升级C80SPC800后sql on hadoop配置文件被manager刷新重置。从hd侧抽数会报错:

ERROR:Login failed on cn_5001, check your principal and keytab.

局点现场hd集群做过迁移,迁移后未在FIM界面上对配置进行更新,导致升级SPC800时下发的还是迁移前的ip。

重新对按照hd迁移后sql on hadoop方案进行配置,将后台刷新成最新的hd侧配置文件后恢复。

3.5.2      升级到C80SPC800后Raid卡缓存策略被重置

【GaussDB(DWS)】【C80SPC600->C80SPC800】

升级过程中修改了raid卡缓存策略,由write back更改为write through,导致升级后业务运行性能下降严重。

C80版本不支持做Preinstall时设置缓存策略,Preinstall成功后diskmgtd进程每次启动的时候会设置一把磁盘缓存策略,默认是透写(高可靠性)。

如果希望修改成回写,需要创建一个标志文件/usr/local/diskmgt/ini/wce,文件中内容为“1”,然后重启diskmgt进程。

升级时候会做Preinstall的升级,Preinstall升级后会重启每个节点的diskmgt进程(每个节点一个),diskmgt进程每次启动的时候会设置一把磁盘缓存策略。

1)    FusionInsight去掉当前在扩容和安装等场景对OS缓存设置的方法:(这是针对以后的扩容或新建场景)

在产品安装包的preinstall目录下 preinstall/script/modules/070.autopart/autopart/inner/diskmgtd 文件中注释掉如下的代码;

${CMD_SUDO_SDPARM} --clear=WCE ${sddisk}

2)    针对集群中已经关闭OS缓存的配置,需要进行打开os缓存并开启raid卡回写模式的操作方法如下:(这是针对当前的整改场景)

新建脚本os_cache_raid.sh,内容如下:

#!/bin/bash

echo "1" >> /usr/local/diskmgt/ini/wce     #标志位设为1

/usr/local/diskmgt/script/diskmgt.sh -r   #重启diskmgt进程,使上面的标志生效并打开os缓存

cd /opt/MegaRAID/storcli              #切换路径到对应工具所在路径下,默认在/opt/MegaRAID/storcli路径下,使用storcli在线操作,要求设备安装storcli工具

./storcli64 /c0/vall set wrcache=wb             #设置所有raid组读写策略为wb(回写)

./storcli64 /c0/vall set iopolicy=direct                #设置所有raid组IO策略为direct

然后在集群内用root用户通过批量执行的脚本工具clustercmd.sh(这个工具的使用说明和前提条件在FusionInsight产品文档中有详细说明),按照需要配置好配置文件中的节点列表后,具体操作样例如下:

./clustercmd.sh  "os_cache_raid.sh"

3)    另外一点,需要注意的是,如果采用改脚本这种方式,由于当前所有版本默认都是关闭OS缓存,后续升级时,也需要把以后待升级的目标版本的preinstall脚本中的代码注释掉,否则升级后OS缓存就又被关闭了,然后raid卡的策略又会被调整回透写模式。

EI企业智能 Gauss AP 数据仓库服务 GaussDB(DWS)

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:游戏编程之九 设计工具之游戏引擎
下一篇:Freebase Data Dump结构初探
相关文章