本文档旨在帮助用户快速定位南大通用GBase 8c数据库在进行扩缩容操作时出现的性能卡顿问题。文章详细阐述了扩容和缩容的原理及各个阶段，并提供了在不同阶段遇到问题时的日志查看方法。通过分析gha_ctl的输出和相关日志文件，用户可以准确判断问题所在。文中列举了两个具体的定位案例，分别针对SSH互信失败和gs_redis工具执行失败的情况，并给出了相应的解决方法，帮助用户高效解决实际操作中的困难。

✨ **扩缩容流程解析：** 扩容过程包含add_primary、prepare、execute、add_standby、clean_data五个阶段，而缩容则包括prepare、execute、drop_group、clean_data四个阶段。用户可以通过`gha_ctl get expand history -l $dcslist`命令查看当前所处阶段，以便针对性地进行问题排查。

🔍 **日志分析定位：** 在扩容/缩容的add_primary、add_standby、prepare阶段，应检查gha_server上的`/var/log/messages`和`/tmp/gha_ctl/gha_ctl.log`日志，以及目标DN节点上的`gbase/om`日志目录中的`gs_expansion`相关日志。若在execute阶段卡顿，则需重点关注`gs_redis`工具的日志，该日志位于CN的`bin/gs_redis`目录下，其中会详细记录数据重分布失败的原因。

🔑 **SSH互信是关键：** 定位案例一揭示了SSH配置不当是导致扩容失败的常见原因。当出现“Failed to verify SSH trust”的错误时，意味着执行节点与目标节点之间的SSH免密登录未配置成功，需要检查并配置好所有相关节点的SSH互信。

💡 **gs_redis执行失败排查：** 定位案例二展示了`gs_redis`工具执行失败可能源于数据不一致。当日志显示“relation ... does not exist”时，需要登录到相关DN节点，检查数据库中是否存在目标表或数据，并根据情况进行重新创建或导入，以确保数据完整性。

🛠️ **问题解决思路：** 针对不同的失败阶段和错误信息，应采取相应的解决策略。例如，对于参数配置问题，直接修改参数即可；对于SSH互信问题，则需要配置SSH免密登录；而对于数据重分布失败，则需要检查并修复目标节点上的数据问题，以保证扩缩容操作的顺利进行。

扩缩容过程性能卡顿如何快速定位？从原理上分析，南大通用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。

1.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。

1.3 解决方法

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

execute阶段失败的话，一般报错消息会显示”gs_redis failed on ...”，此时需要查看gs_redis工具的日志。gs_redis日志在某个CN的bin/gs_redis目录下。

gs_redis日志日志详细记录了失败的原因，然后可在cn的pg_log目录下查看失败原因。

1.4 定位案例

定位案例1

现象如下所示：

[gbase@gbase-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@gbase-82 script]$ {"ret":-1，"msg":"Init fail"}

定位步骤：

首先执行命令，查看一下是在哪个步骤失败：

./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":"2024-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文件。

2024-12-29 10:28:04 gbasedb.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_2024-12-29_10:28:02_796027/clusterconfig.xml -h 100.0.0.84 --from-gha --inst-name dn4_1 --group-name dn42024-12-29 10:28:08 command_util.py execute 249 DEBUG 345309 cmd:ssh -E /dev/null -p 22 gbase@100.0.0.84 "source ~/.bashrc;gs_expansion -U gbase -G gbase -X /tmp/gs_gha_2024-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: Failed to verify SSH trust on these nodes:gbase-82， gbase-83， gbase-84， 100.0.0.82， 100.0.0.83， 100.0.0.84 by individual user.2024-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_2024-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 gbase@100.0.0.84 "source ~/.bashrc;gs_expansion -U gbase -G gbase -X /tmp/gs_gha_2024-12-29_10:28:02_796027/clusterconfig.xml -h 100.0.0.84 --from-gha --inst-name dn4_1 --group-name dn4"]， msg[[GBASE-51100] : Failed to verify SSH trust on these nodes:gbase-82， gbase-83， gbase-84， 100.0.0.82， 100.0.0.83， 100.0.0.84 by individual user.]2024-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

现象：

[gbase@gbase-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@gbase-82 script]$ {"ret":-1，"msg":"gs_redis on cn1 failed"}

定位步骤：

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

tid[392445]: INFO: redistributing database "gbase"tid[392445]: INFO: lock schema gbase.publicINFO: please do not close this session until you are done adding the new nodeCONTEXT: referenced column: pgxc_lock_for_transfertid[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 existDETAIL: query was: ALTER TABLE public.spatial_ref_sys SET (append_mode=on，rel_cn_oid =17324)

我们登陆到dn4上看检查gbase数据库，确实没有public.spatial。重新创建或导入即可。