南大通用GBase 8c扩缩容失败故障定位方法

南大通用GBase 8c是一款多模多态分布式数据库，可进行横向水平的扩张和缩减，即支持扩容和缩容操作。本文介绍当扩缩容故障时如何进行问题定位。

正常来讲，使用自带的gha_ctl工具进行扩缩容正常会分输出两个success。第一个success是检查输入参数是否正确，数据目录是否非空。在这一步失败的话，可以修改参数，再次尝试。第二个success表示启动子进程，执行扩容/缩容，这一步是比较花时间的。

1、原理介绍

（1）扩容

执行扩容是分下面几个阶段，通过gha_ctl get expand history -l $dcslist 命令的输出结果中phase可以知道是在那个阶段失败。

add_primary > prepare > execute > add_standby > clean_data

• add_primary阶段是dn节点的初始化，添加dn主机。
• prepare阶段是检查需要扩容的node group， 创建目标node group，设置扩容的源node group和目标node group。
• execute阶段是执行gs_redis工具进行数据重分布。
• add_standy阶段添加dn备机的过程。
• clean_data阶段是更改扩容状态到end。

（2）缩容

缩容在第二步骤也分几个阶段， 通过gha_ctl get expand history -l $dcslist 命令的输出结果中phase可以知道是在那个阶段失败。缩容是不需要添加节点的，只会删除节点。

prepare > execute > drop_group > clean_data

• prepare阶段是检查需要缩容的node group， 创建目标node group，设置缩容的源node group和目标node group。
• execute阶段是执行gs_redis工具进行数据重分布。
• drop_group阶段是擅长缩容的datanode组。
• clean_data阶段是更改扩容状态到end。

2、故障概述及案例

在add_primary/add_standy/prepare阶段失败时，在gha_server(多个gha_server时，在主gha_server上)上查看/var/log/messages和/tmp/gha_ctl/gha_ctl.log，以及在添加的dn节点上的日志目录$GAUSSLOG/gbase/om中查看gs_expansion***的日志。

execute阶段失败的话，一般报错消息会显示”gs_redis failed on ...”，此时需要查看gs_redis工具的日志。

gs_redis日志在某个CN的$GAUSSLOG/bin/gs_redis目录下。gs_redis日志日志详细记录了失败的原因，然后可在cn的pg_log目录下查看失败原因。

（1）故障定位案例1

现象如下所示：

[gbase@gbase8c-82 script]$ ./gha_ctl expand datanode 'dn4 (dn4_1 100.0.0.84 30010 /home/gbase/data/dn4/dn4_1 8020)' -l http://100.0.0.82:2379，http://100.0.0.83:2379，http://100.0.0.84:2379 -u 40ac7d83-6be3-486c-83c4-8942a16d3590
{
"ret":0，
"msg":"Success"
}
[gbase@gbase8c-82 script]$ {
"ret":-1，
"msg":"Init fail"
}

定位步骤：

首先查看一下是在哪个步骤失败：

[gbase@gbase8c-82 script]$ ./gha_ctl get expand history -l http://100.0.0.82:2379，http://100.0.0.83:2379，http://100.0.0.84:2379
{
"state":"idle"，
"current":""，
"history":[
{
"time":"2022-12-29 10:27:59"，
"uuid":"40ac7d83-6be3-486c-83c4-8942a16d3590"，
"phase":"add_primary"，
"status":"failed"，
"info":{
"dn4":[
{
"name":"dn4_1"，
"host":"100.0.0.84"，
"port":"30010"，
"work_dir":"/home/gbase/data/dn4/dn4_1"，
"agent_port":"8020"，
"role":"primary"，
"agent_host":"100.0.0.84"
}
]
}
}
]
}

发现是在加节点时失败，检查一下84节点上的gs_expansion***日志，发现没有错误。

然后在gha_server上查看/tmp/gha_ctl/gha_ctl.log文件。

2022-12-29 10:28:04 gaussdb.py expansion 89 DEBUG 345309 Execute expansion command in [100.0.0.84]: source ~/.bashrc;gs_expansion -U gbase -G gbase -X /tmp/gs_gha_2022-12-29_10:28:02_796027/clusterconfig.xml -h 100.0.0.84 --from-gha --inst-name dn4_1 --group-name dn4
2022-12-29 10:28:08 command_util.py execute 249 DEBUG 345309 cmd:ssh -E /dev/null -p 22 [email protected] "source ~/.bashrc;gs_expansion -U gbase -G gbase -X /tmp/gs_gha_2022-12-29_10:28:02_796027/clusterconfig.xml -h 100.0.0.84 --from-gha --inst-name dn4_1 --group-name dn4"， status:1， output:[GAUSS-51100] : Failed to verify SSH trust on these nodes:
gbase8c-82， gbase8c-83， gbase8c-84， 100.0.0.82， 100.0.0.83， 100.0.0.84 by individual user.
2022-12-29 10:28:08 instance.py init 1614 INFO 345309 Node dn4_1 init error:Failed to execute the command: source ~/.bashrc;gs_expansion -U gbase -G gbase -X /tmp/gs_gha_2022-12-29_10:28:02_796027/clusterconfig.xml -h 100.0.0.84 --from-gha --inst-name dn4_1 --group-name dn4. Error:
Run cmd failed:cmd[ssh -E /dev/null -p 22 [email protected] "source ~/.bashrc;gs_expansion -U gbase -G gbase -X /tmp/gs_gha_2022-12-29_10:28:02_796027/clusterconfig.xml -h 100.0.0.84 --from-gha --inst-name dn4_1 --group-name dn4"]， msg[[GAUSS-51100] : Failed to verify SSH trust on these nodes:
gbase8c-82， gbase8c-83， gbase8c-84， 100.0.0.82， 100.0.0.83， 100.0.0.84 by individual user.]
2022-12-29 10:28:08 common.py add_one_node 190 ERROR 345309 init one node dn4_1 failed， code: -1， response: Init fail

我们看到是ssh没有配置互信，测试一下，发现84节点没有配置到其他节点的ssh互信。

解决方法：

配置互信后可以再次尝试扩容。

（2）故障定位案例2

现象：

[gbase@gbase8c-82 script]$ ./gha_ctl expand datanode 'dn4 (dn4_1 100.0.0.84 30010 /home/gbase/data/dn4/dn4_1 8020)' -l http://100.0.0.82:2379，http://100.0.0.83:2379，http://100.0.0.84:2379 -u 40ac7d83-6be3-486c-83c4-8942a16d3590
{
"ret":0，
"msg":"Success"
}
[gbase@gbase8c-82 script]$ {
"ret":-1，
"msg":"gs_redis on cn1 failed"
}

定位步骤：

从错误内容看，是执行gs_redis的时候失败了，然后我们去cn1的$GAUSSLOG/bin/gs_redis下查看gs_redis日志。

tid[392445]: INFO: redistributing database "postgres"
tid[392445]: INFO: lock schema postgres.public
INFO: please do not close this session until you are done adding the new node
CONTEXT: referenced column: pgxc_lock_for_transfer
tid[392445]: INFO: redistributing table "spatial_ref_sys"
tid[392445]: INFO: ---- 1. setup table spatial_ref_sys ----
tid[392445]: ERROR: query failed: ERROR: dn4: relation "public.spatial_ref_sys" does not exist
DETAIL: query was: ALTER TABLE public.spatial_ref_sys SET (append_mode=on，rel_cn_oid =17324)

我们登陆到dn4上看，postgres数据库，确实没有public.spat。