GaussDB(DWS)扩容问题定位指南（二）
扩容问题定位指南（二）
2 扩容问题定位方法
2.1 扩容问题分类
扩容通常是在“初始化服务和实例”和数据重分布两个步骤报错，可通过查看后台日志排查分析。
2.2 日志分析步骤
1、 如果是在“初始化服务和实例”步骤报错，则使用omm用户登录报错的新扩容节点，查看日志/var/log/Bigdata/mpp/scriptlog/postinstall.log，如果日志文件中没有内容“PreInstall cmd :execPython_preinstallMPP”，则表示扩容流程在FIM初始化阶段报错，排查FIM日志分析；
2、 如果有则继续搜索日志中是否有错误“ PreInstall failed ”，如果能搜到说明配置新节点环境失败，根据日志上下文处理失败问题修复环境；
3、 如果是扩容加节点失败，则使用omm用户登录第一个老节点，进入/var/log/Bigdata/mpp/scriptlog/目录下，查看gs_postinstall_*.log扩容日志文件，根据日志内容判断扩容失败原因。
4、 如果重分布步骤失败，可登陆第一个老节点查看/var/log/Bigdata/mpp/scriptlog/目录下gs_postinstall_*.log扩容日志文件；如果日志显示是gs_redis报错，则登录集群第一个CN节点查看$GAUSSLOG/bin/gs_redis/目录下的gs_redis日志文件，搜索“failed”关键字获取具体的失败原因。
2.3 常见扩容问题
1、 扩容（添加新节点）过程中因为断电、机器reboot、网络闪断导致扩容失败。
· 修复硬件故障，确保GaussDB(DWS)集群所有机器网络连接正常；
· 确保集群所有机器上没有扩容残留进程(gs_expand, gs_dump, gs_dumpall, gsql，gs_redis)。
su - omm
ps ux |grep gs_expand |grep -v grep |awk '{print $2}' |xargs kill -9
ps ux |grep gs_dump |grep -v grep |awk '{print $2}' |xargs kill -9
ps ux |grep gsql |grep -v grep |awk '{print $2}' |xargs kill -9
ps ux |grep gs_redis |grep -v grep |awk '{print $2}' |xargs kill -9
· 在FI Manager页面上，点击扩容“重试”按钮重入扩容。
2、 扩容（添加新节点）过程中启动新集群失败而导致扩容失败。
1、 以omm用户登录部署GaussDB(DWS)集群的任意一个节点，查看未启动的实例。
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
cm_ctl query -Cvd
2、 检查哪个实例状态不正常，是否由于实例端口号冲突导致启动失败。
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
cd $GAUSSLOG/pg_log/异常实例日志目录
grep -nr ‘Is another postmaster’ postgresql-*.log
3、 扩容到元数据导入阶段，元数据导入失败，或者元数据导入耗时超过1小时未完成。
· 查看CMS节点扩容OM日志，执行到Restoring new nodes这一步出现SQL失败，说明导入元数据失败。登陆任一新节点查看具体的sql失败信息：
su - omm
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
cd $GAUSSLOG/om/
ls -trl gs_local*.log
tail -f gs_local*.log
根据日志找到restore失败的SQL语句。
· 分析失败原因，如果确认是SQL语法不支持，导入到新集群失败，需要先回退到老集群，然后删除或者修改不支持的SQL语法。
a) 记录不支持的SQL语句；
b) 在FI Manager界面上点击扩容“回退”按钮，回退到老集群；
使用gsql客户端连接CN节点，删除或者修改不支持SQL语句。
4、 扩容到元数据导出阶段，由于事务锁资源不足，导致元数据导出失败。
· 以omm用户登录CMS主服务器节点。执行如下命令：
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
grep -nr "You might need to increase max_locks_per_transaction" $GAUSSLOG/bin/gs_dump/gs_dump -*-current.log
若上述命令执行有结果输出，则说明GaussDB(DWS)集群中因事务锁不足导致扩容dump失败。
· 获取GaussDB(DWS)的行存表、列存表、分区表、外表、索引、视图等数据库对象的数量。max_locks_per_transaction * (max_connections + max_prepared_transactions) 必须大于对象个数。
在GaussDB(DWS)集群任意一个节点，参照如下命令，修改GUC参数配置：
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
gs_guc set -Z coordinator -N all -I all -c 'max_connections = 1024' -c 'max_prepared_transactions = 1000' -c 'max_locks_per_transaction = 1024'
gs_guc set -Z datanode -N all -I all -c 'max_connections = 3000' -c 'max_prepared_transactions = 1000' -c 'max_locks_per_transaction = 1024'
cm_ctl stop && cm_ctl start
如果元数据导出阶段耗时超过1小时未完成，在GaussDB(DWS)集群任意一个节点，通过如下方法查看dump进度：
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
cd $GAUSSLOG/bin/gs_dumpall/
grep -nr "objects have been dumped" gs_dumpall-*-current.log
5、 后台下发执行扩容重分布命令失败
· 如果失败日志中不存在’If you want to check the progress of redistribution, please check the log file on’内容,说明还未开始重分布，根据失败报错提示查询原因并处理,如果日志存在If you want to check the progress of redistribution, please check the log file on’内容，查看日志提示的对应节点上重分布日志gs_redis-XXX.log。
· 查看gs_redis-XXX.log日志里面的错误信息，
1）如果错误信息提示：memory is temporarily unavailable，修改重分布并发度，重试下发扩容重分布命令。
2) 如果提示连接DN失败，检查对应DN的状态并修复，然后重试下发扩容重分布。
3）如果提示出现磁盘损坏，修复磁盘，如果无法修复可以进行节点替换。
3 扩容常见案例
3.1 添加主机
3.1.1 添加主机时识别出来的主机业务ip都是两个
发生版本
【GaussDB(DWS)】【C80SPC310】
问题描述
添加主机的时候识别出来的主机业务ip都是两个，如下：
问题分析
节点上的/etc/hosts有问题，一个主机名对应两个ip
解决方案
将/etc/hosts修改为“业务ip 主机名”的形式，重新添加主机。
3.1.2 扩容或重装主机时在第一步校验参数失败报Failed to verify nodes connection错误
发生版本
【GaussDB(DWS)】【6.5.1.5】
问题描述
1、扩容主机失败，有如下提示信息：
#发现节点未完成# Could not verify `ecdsa-sha2-nistp256` host key with fingerprint `31:90:be:5c:92:a4:62:90:7d:9a:d2:c2:4e:4f:d6:2a` for `xxx.xxx.xxx.xxx` on port 22 while Connecting via SSH to xxx.xxx.xxx.xxx using username root.
2、重装主机失败，提示：
重装主机失败，详细错误信息: Failed to verify nodes connection. Maybe the password is incorrect or the network is abno
问题分析
待扩容或重装节点的HOSTKEY变更（重装OS或者重新生成HOSTKEY可能会导致HOSTKEY变更）。
解决方案
1、使用PuTTY工具，以omm用户登录主管理节点。
2、执行vi /var/log/Bigdata/controller/controller_nodesetup.log命令，搜索“HOST_KEY_NOT_VERIFIABLE”关键字，有如下报错信息：
SSH Command Exectuion failed
3、执行vi ${BIGDATA_HOME}/om-server/om/etc/om/known_hosts命令，删除文件中包含待扩容或者重装节点主机名或者ip地址的行。
4、执行sh ${CONTROLLER_HOME}/sbin/restart-controller.sh命令重启controller，然后重新进行扩容或者重装主机。
3.1.3 添加主机在初始化服务和实例失败，报错cn个数不在0~10的范围
发生版本
【GaussDB(DWS)】【6.5.1.3】
问题描述
添加主机在初始化服务和实例失败，报错cn个数不在0~10的范围：
问题分析
LLD中所有新扩容节点cn设置均为1导致cn数超过10。
解决方案
1、将LLD中新扩容节点的cn的数修改为0；
2、删除添加失败的主机后重新添加主机。
3.1.4 添加主机在初始化服务和实例失败,postinstall日志报lost connection
发生版本
【GaussDB(DWS)】【C80SPC808】
问题描述
添加主机在初始化服务和实例失败,postinstall日志报lost connection
问题分析
报错节点omm用户下通过ssh 主机名的方式连接新节点，需要输入yes才能连接。
解决方案
对新节点进行以下操作：
1、将新节点上的/home/omm/.ssh/known_hosts清空进行
2、在报错节点重新以omm用户通过ssh 主机名的方式连接新节点，提示输入yes的时候输入yes
3、退出session，在执行节点再次以omm用户通过ssh 主机名的方式连接新节点，确认可以免密登录
4、修复所有新节点后重新执行添加主机操作。
3.1.5 添加主机在初始化服务和实例失败，postinstall.log日志报Failed to rebuild instance [6033]
发生版本
【GaussDB(DWS)】【6.5.1.8】
问题描述
添加主机在初始化服务和实例失败，. postinstall.log日志报Failed to rebuild instance [6033]
排查gs_ctl日志有报错got WAL data offset 00000628, expected 00000630。
排查新老节点gs_ctl版本不一致
问题分析
此问题是由于上次打补丁时没有按照方案执行替换MPPDB软件包步骤，导致分发到新节点的软件与老节点版本不一致。
解决方案
根据升级指导书完成oms包的替换步骤，删除新扩容的节点重试。
3.1.6 添加主机在初始化服务和实例失败，报错[GAUSS-52631] : Invalid value for GUC parameter comm_max_datanode: 512
发生版本
【GaussDB(DWS)】【8.0.0.1】
问题描述
扩容初始化实例和服务报错：
[GAUSS-52631] : Invalid value for GUC parameter comm_max_datanode: 512.
HINT: Increase the value of comm_max_datanode by executing "source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile; gs_guc set -Z datanode -I all -N all -c 'comm_max_datanode=1024'; gs_guc set -Z coordinator -I all -N all -c 'comm_max_datanode=1024'" and then, restart the database.
2020-08-28 20:58:43 ERROR (nodeExtend:[mpp-postinstall.sh:1001]) dilatation failed, the dilatation result is 1.
2020-08-28 20:58:43 ERROR (main:[mpp-postinstall.sh:1397]) Extend node failed , restore configXML.
2020-08-28 20:58:43 INFO (restoreOrRemoveConfigXml:[mpp-postinstall.sh:1036]) local host :mpp-dat41 is compare_host: mpp-dat41.
问题分析
comm_max_datanode的值512小于扩容后实际的dn数目。
解决方案
按如下命令调整cn和dn的comm_max_datanode值，然后重新执行添加主机：
gs_guc reload -Z coordinator -Z datanode -N all -I all -c "comm_max_datanode=1024"。
3.1.7 添加主机在初始化服务和实例失败，报错不能修改default_transaction_read_only
发生版本
【GaussDB(DWS)】【C80SPC300】
问题描述
扩容新节点导入元数据阶段报错：
“defalt_transaction_read_only” can not be changed now
问题分析
使用如下命令手动导出对应sql文件，确认文件中包含设置default_transaction_read_only为off的语句
gs_dumpall -U omm -W Bigdata123@ -p 25330 -s --dump-wrm --include-templatedb --file='schema_datanode.sql' -g
手动alter role属性报同样的错误
查看pg_db_role_setting结果如下：
解决方案
使用如下存储过程将pg_db_role_setting中的内容清空：
CREATE OR REPLACE FUNCTION public.pgxc_set_roles() RETURNS void
AS $$
DECLARE
rd record;
fetch_dn text;
SQL_STR TEXT;
BEGIN
fetch_dn := 'SELECT node_name FROM pg_catalog.pgxc_node WHERE node_type=''D'' or node_type=''C'' order by node_name';
FOR rd IN EXECUTE(fetch_dn) LOOP
sql_str := 'EXECUTE DIRECT ON (' || rd.node_name || ') ''delete from pg_db_role_setting ''';
EXECUTE IMMEDIATE sql_str;
RAISE INFO 'cancel query with node_name = %', rd.node_name;
END LOOP;
END; $$
LANGUAGE 'plpgsql';
3.1.8 添加主机在初始化服务和实例失败，扩容节点gs_local日志报role 16664 does not exist
发生版本
【GaussDB(DWS)】【C80SPC808】
问题描述
添加主机在初始化服务和实例失败，看扩容节点的gs_local日志报错：
role 16664 does not exist
HINT: please use "pgxc_wlm_rebuild_user_respool" to rebuild info
问题分析
扩容添加节点阶段，新dn实例以restore mode启动同步元数据，CREATE USER时没有刷新user hash，ALTER TABLE OWNER TO会从user hash中搜索该用户，user hash中没有该用户信息而发生报错：Error: role 16664 does not exist。
解决方案
升级到C80SPC810版本/6.5.1.8版本/8.0版本之后再进行扩容。
3.1.9 添加主机时在初始化服务和实例失败，报错set os parameters failed
发生版本
【GaussDB(DWS)】【C80SPC300】
问题描述
添加主机时在初始化服务和实例失败，报错
ERROR (main :[elk-postinstall.sh:1099]) set os parameters failed (sysctl：cannot stat /proc/sys/kernel/kstack_depth_to_print:NO such file or directory)
问题分析
/etc/sysctl.conf配置文件中有kstack_depth_to_print参数，但是os中缺少此参数依赖的文件/proc/sys/kernel/kstack_depth_to_print。
解决方案
注释掉/etc/sysctl.conf的kstack_depth_to_print，sysctl -p规避。
3.1.10 添加主机成功后页面出现37014 Gaussdb进程锁文件已经存在的告警
发生版本
【GaussDB(DWS)】【6.5.1】
问题描述
添加主机成功后页面出现37014 gaussdb进程锁文件已经存在的告警
问题分析
cma的启停线程在start_datanode_check逻辑，判断进程不存在之后，会检查是否有gs_ctl在运行，如果有gs_ctl运行，会sleep(2)用来让gs_ctl build在执行的时候，有足够的时间创建gs_build.pid文件。这样会造成一个问题，2s前检测到dn进程不存在。进入进程不存在的判断逻辑，DN START，但是此时有概率dn在进行build，这个时候，会sleep(2)，2s之后dn进程成功启动，cma再次拉起。
解决方案
按如下步骤可消除告警：
1、先根据告警信息找到上报告警的dn对应的目录
2、把目录下的postmaster.pid文件移到其他地方
3、然后在kill出问题的dn对应的进程
3.1.11 添加主机在初始化服务和实例失败，还原元数据报错缺少format option
发生版本
【GaussDB(DWS)】【C80SPC300】
问题描述
导入元数据阶段报错error：dn_7029_7030:Need format option for the foreign table：
问题分析
重试并取出对应的sql文件，检查确认此外表确实缺少format option相关内容：
解决方案
导出此外表定义，然后将此外表从库内删除。
3.1.12 添加主机在初始化服务和实例失败，还原元数据报错option foldername存在非法字符
发生版本
【GaussDB(DWS)】【C80SPC300】
问题描述
还原元数据阶段报错：error：dn_7029_7030:There is an illegal character ' ' in the option foldername
问题分析
重试并获取对应sql文件，确认外表定义foldername中多了一个空格
解决方案
导出此外表定义，然后将此外表从库内删除。
3.1.13 添加主机部分实例成功，IPV6模块被禁用
发生版本
【GaussDB(DWS)】【C80SPC305】
问题描述
扩容时候初始化服务和实例部分失败
问题分析
排查postinstall.log发现ipv6报错
局点此前由于安全加固禁用了IPV6模块
解决方案
1、 在modprobe.conf.local文件下，注销ipv6跟net-pf-10两行
2、 启动ipv6服务
3.2 数据重分布
3.2.1 数据重分布报错Failed to check used space of the database users. Used space percentage cannot exceed 80%
发生版本
【GaussDB(DWS)】【8.0.0.1】
问题描述
数据重分布报错Failed to check used space of the database users. Used space percentage cannot exceed 80%. Detail: The space usage of user [t46xxxxxxxx] is 85.23
问题分析
租户配置了roltabspace限制且当前使用量已超限，导致扩容报错。
解决方案
1、 统计pg_roles系统表中有配置用户表空间限制的用户并备份一份以便后面还原；
select rolname,roltabspace from pg_roles where roltabspace is not null;
2、 逐个将配置的用户表空间全部设置为null
udpate pg_roles set roltabspace=null where rolname=角色名 and roltabspace=原始表空间值;
3、 继续进行扩容重分布
4、 根据备份的信息还原用户表空间配置
3.2.2 数据重分布报错invalid page header
发生版本
【GaussDB(DWS)】【C80SPC300】
问题描述
ztfx.tb_sub_kw_stat重分布失败 error： dn_6583_6584：dn_6673_6674: invalid page header in block 0 of relation base/16403/2498165
问题分析
分别连接对应dn主备，确认主上此relation数据有问题，备上数据正常
select * from pg_partition where relfilenode=2498165;为一个分区
invalid page header in block表示从磁盘读取数据文件时，发现磁盘中存储的数据文件中某个block的page header发生了错误。
有两种可能：
1. 一般是磁盘发生了存在磁盘坏块，导致数据文件受损。
2. 另一种可能是开启了disk cache导致在服务器发生掉电等crash时，导致部分disk cache中的数据丢失。
解决方案
与客户确认，此分区数据可删除，alter table ** drop partition ***；解决
如果此分区数据不可删除，则需要对此dn进行全量build重建。
3.2.3 数据重分布报错pmk在个别dn上不存在
发生版本
【GaussDB(DWS)】【C80SPC300】
问题描述
数据重分布过程中报错：
pmk.pmk_meta_data
pmk.pmk_snapshot_datanode_stat
pmk.pmk_configuration
pmk.pmk_snapshot_coordinator_stat
pmk.pmk_snapshot重分布失败，报dn schema pmk不存在
问题分析
Pmk schema在个别dn上不存在，导致数据重分布报错。
解决方案
将pmk schema drop掉，重新调起重分布。
DROP SCHEMA IF EXISTS pmk cascade；
pmk schema会在下次调用性能统计脚本时自动重建出来，无需手动重建。
3.2.4 数据重分布重入时delete pgxc_redistb操作耗时长，3小时以上无法完成
发生版本
【GaussDB(DWS)】【C80SPC600】
问题描述
将重分布进程杀掉重入，长时间不能进入表重分布阶段，后台查看第一个cn上PG_STAT_ACTIVITY视图，发现是在执行如下语句：
delete from pgxc_redistb where(nspname, relname) not in ( select n.nspname, c.relname from pg_class c,pg_namespace n where c.relnamespace = n.nspname);
问题分析
重分布重入时需要先将pgxc_redistb中已完成重分布的表记录剔除掉，此剔除语句执行慢。
解决方案
1、首先停止重分布进程；
2、查看当前事务，cancel掉redis进程调起的语句
select pg_cancel_backend(pid) from pg_stat_activity where application_name = 'gs_redis' and query like 'DELETE FROM pgxc_redistb%';
3、修复表字段，在每个数据库下执行语句：
set enable_cluster_resize = on;
alter table pgxc_redistb alter column relname set not null;
alter table pgxc_redistb alter column nspname set not null;
4、重新调起重分布命令。
3.2.5 数据重分布报错cstore_buffers maybe too small
发生版本
【GaussDB(DWS)】【8.0.0.2】
问题描述
数据重分布失败，排查gs_redis日志cstore_buffers maybe too small:
问题分析
执行show cstore_buffers，确认大小为256M，过小。
解决方案
结合节点总内存大小，修改cstore_buffers为1G，然后重启集群，重新执行数据重分布。
3.2.6 数据重分布报错string is longer than 8
发生版本
【GaussDB(DWS)】【6.5.1.1】
问题描述
添加完节点，在数据重分布时候发生报错string is longer than 8:
问题分析
重分布工具只能识别8位node id，当前node id已经增长到9位，导致重分布工具无法识别node id，从而不能进程重分布。
解决方案
分别连接集群中每个cn，查询如下sql确认是否还有oid未超过8位的cn：
select max(oid) from pg_class;
select max(oid) from pgxc_node;
如果存在cn上oid未超过8位，则可按如下方式修改脚本规避并在重分布完成后尽快升级到新版本：
vi /opt/huawei/Bigdata/mppdb/wisequery/script/impl/expand/OLAP/ExpandImplOLAP.py
2099 self.redisNode = coorInst[-1]--修改cn编号为oid未超过8位的cn编号，并注释后续四行
2100 #if len(coorInst) > 1:
2101 # for cnInst in coorInst[1:]:
2102 # if int(cnInst.instanceId) < int(self.redisNode.instanceId):
2103 # self.redisNode = cnInst
3.2.7 终止数据重分布重新运行业务，应用程序连接数据库报错negative bitmapset member not allowed等错误
发生版本
【GaussDB(DWS)】【8.0.0.1】
问题描述
重分布完成一部分表之后终止数据重分布，重新启动跑批任务，出现如下几种报错现象：
1、 应用程序连接数据库报错negative bitmapset member not allowed；
2、 Cn频繁core重启，堆栈如下：
3、 Cn日志中有ERROR：invalid coordinator number: -1, NumCoords: 0报错。
问题分析
重分布完成一部分表之后终止数据重分布，此时集群还处于重分布Y模式下，如果使用JDBC作为客户端连接，且JDBC的URL带schema信息时，数据库中建立连接时没有初始化CN，DN handles信息导致上述三种报错。
解决方案
实际业务中很难彻底保证无跟表相关的ddl、跟表关联的对象的ddl、函数返回值带表类型的ddl等操作，所以建议使用方案一，最好不要使用方案二。
方案一：
1、停止重分布进程；
1)omm用户登录第一个cn节点；
2)找到gs_redis进程并将其kill -9 杀掉
ps -ef |grep gs_redis|grep -v grep找到重分布进程pid
kill -9 pid 杀掉重分布进程
ps -ef |grep gs_redis|grep -v grep确认进程已被kill掉
3)连接第一个cn，将数据重分布活跃语句全部终止掉
SELECT pg_terminate_backend(pid);
2、修改业务，JDBC的URL中去掉schema，把后面用户表都显式带上schema；
3、运行业务；
4、停止业务，重新调起重分布。
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
gs_expand -t redistribute --fast-redis --parallel-jobs=12 --redis-mode=read-only
方案二：
1、停止重分布进程；
1)omm用户登录第一个cn节点；
2)找到gs_redis进程并将其kill -9 杀掉
ps -ef |grep gs_redis|grep -v grep找到重分布进程pid
kill -9 pid 杀掉重分布进程
ps -ef |grep gs_redis|grep -v grep确认进程已被kill掉
3)连接第一个cn，将数据重分布活跃语句全部终止掉
SELECT pg_terminate_backend(pid);
2、修改所有cn上老nodegroup的in_redistribution=n；并kill cn进程
alter table pgxc_group set in_redistribution='n' where group_name=old_group;
kill cn进程
ps -ef |grep coordinator|grep -v grep|awk -F ' ' '{print $2}'|xargs kill -9
3、运行业务，需要保证业务中无跟表相关的ddl，跟表关联的对象的ddl，函数返回值带表类型的ddl等操作，否则会造成新老节点元数据不一致；
4、停止业务，修改所有cn上老nodegroup的redistribute=y；并kill cn进程
alter table pgxc_group set in_redistribution='y' where group_name=old_group;
kill cn进程
ps -ef |grep coordinator|grep -v grep|awk -F ' ' '{print $2}'|xargs kill -9
5、重新调起重分布。
source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
gs_expand -t redistribute --fast-redis --parallel-jobs=12 --redis-mode=read-only
3.2.8 数据重分布时查询redis_progress结果的剩余表个数33张和pgxc_redistb剩余11张表，剩余表统计不准
发生版本
【GaussDB(DWS)】【6.5.1.1】
问题描述
数据重分布时查询redis_progress结果的剩余表个数33张和pgxc_redistb剩余11张表，剩余表统计不准。
问题分析
扩容过程中，手动处理过表，也删除过表，所以导致redis_progress和pgxc_redistb中统计结果不准。
解决方案
分别连接每个database执行如下sql，可统计每个库中剩余未重分布的表个数：
select * from pgxc_class where pgroup='group_version1';
3.2.9 数据重分布过程中新增的节点报某些表不存在，重分布任务中断
发生版本
【GaussDB(DWS)】【C80SPC307】
问题描述
数据重分布过程中新增的节点报某些表不存在，重分布任务中断，报错如下：
问题分析
在旧节点上可以查到该表，在新扩容节点查不到该表，发现该表是创建在sys下，sys是系统schema，默认不dump里面的表，导致新节点在重分布过程中报无该表的错误，通过排查发现业务侧共有30张创建在sys schema下的表。
解决方案
一、先将剩余的表继续重分布，将sys下的30张表跳过：
1、以omm用户登录postgres数据库，设置append_mode = off
alter table pgxc_redistb set (append_mode = off);
2、执行update
将需要跳过的表，进行update，执行：
update pgxc_redistb set redis_order = 0 where relname in ('sys_log','xx','xx') and nspname = 'sys' and redistributed = 'n';
3、恢复表为只读模式
alter table pgxc_redistb set (append_mode = read_only);
4、确认是否生效
select redis_order from pgxc_redistb where relname in ('sys_log','xx','xx') and nspname = 'sys';
查看结果是否为0
5、重新调起重分布任务脚本
二、其他表重分布完成后，处理sys下的30张表
1、以omm用户执行导出命令(单表导出，30张表导出30个文件)：
gs_dump -p 25308 dbname -f /home/omm/bkp.sql -s -t tablename
2、修改导出文件里的search_path为新的schema
3、以omm用户执行导入命令（单表导入，导入30次）：
gsql -d dbname -p 25308 -f bkp.sql
4、连接szga_edw库，导数：
insert into newschema.tablename from sys.tablename
5、drop掉sys下的30张表
登录cn，-m维护模式下 set xc_maintenance_mode = on； 然后再drop if exists 表名
6、处理后再重新调起重分布脚本，将重分布完成。
3.2.10 数据重分布报错Could not begin transaction on Datanodes
发生版本
【GaussDB(DWS)】【C80SPC310】
问题描述
数据重分布报错Could not begin transaction on Datanodes
问题分析
排查cn日志，报错dn_6029有发生重启
排查dn_6029日志和磁盘使用率，是由于磁盘使用率本身处于高位（92%），然后并发执行大表重分布将磁盘写满
解决方案
将重分布并发从12降低到6然后重新调起重分布。
3.2.11 gs_redis日志显示重分布已完成但集群状态还是 normal yes yes
发生版本
【GaussDB(DWS)】【6.5.1.1】
问题描述
gs_redis日志显示重分布已完成，进程也已退出，但集群状态还是 normal yes yes，查看gs_expand日志，有如下报错：
can not drop group_version1,because other objects depend on it
再继续查看cn日志，有详细打印出报错的依赖对象是3张存在元数据不一致的表。
问题分析
元数据不一致表残留在老的nodegroup中，导致重分布完drop老的nodegroup时报有对象依赖，不能drop。
可通过1.4.2查询有哪些表未重分布步骤查看哪些对象在老集群nodegroup中。
解决方案
让业务侧清理残留元数据不一致的表然后重新调重分布命令。
3.2.12 DWS数据重分布慢系统盘IO高
发生版本
【GaussDB(DWS)】【6.5.0】
问题描述
DWS数据重分布慢，系统盘IO高，数据盘IO很低：
问题分析
unlink的系统调用底层会调用audit，将系统盘io占满，成为瓶颈，导致重分布业务backend线程阻塞。
解决方案
以root用户关闭各节点系统审计功能：
service auditd stop
检查确认系统审计功能已关闭：
service auditd status
3.2.13 后台数据重分布已完成但FIM界面状态还是待重分布
发生版本
【GaussDB(DWS)】【6.5.1.1】
问题描述
后台查看进度重分布已完成，但是FIM界面状态还是待重分布：
问题分析
重分布进度未正常同步到FIM界面。
解决方案
将业务中使用JDBC客户端连接时，去掉URL中的schema信息，在程序中表前增加schema信息。按如下步骤手动刷新FIM界面重分布状态：
1、使用omm用户，在主oms节点登录OMS数据库：gsql -p 20015 -U omm -W ChangeMe@123456
2、执行sql：
select * from MPP_LOGIC_CLUSTER_REDISTRIBUTION_TASK;
查询对应的TASKID；
3、更新如下sql的TASKID字段后，执行该sql：
update MPP_LOGIC_CLUSTER_REDISTRIBUTION_TASK set TASKSTATE=2,TASKPROGRESS=100, LEFTTBLCOUNT=0, LEFTDATACAPACITY=0, LEFTTIME=0,LEFTTIMEUNIT=0 where TASKID='98d38afd-0a8d-4435-b44b-c7bdd8a96860'
TASKID按实际查询出来的id替换，其它字段值与上面命令保持一致
4、刷新FIM界面，确认重分布状态刷新为已重分布。
- 点赞
- 收藏
- 关注作者
评论（0）