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

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启动失败。

将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 || '

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');

' || 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小时内删除侵权内容。