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 || '\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卡的策略又会被调整回透写模式。
- 点赞
- 收藏
- 关注作者
评论（0）