“G”术时刻:南大通用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。

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

现象如下所示:

perl 复制代码
[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"
}

定位步骤:

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

bash 复制代码
./gha_ctl get expand history -l http://100.0.0.82:2379,http://100.0.0.83:2379,http://100.0.0.84:2379

例如返回:

css 复制代码
{
"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文件。

vbnet 复制代码
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 dn4
2024-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

现象:

perl 复制代码
[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日志。

vbnet 复制代码
tid[392445]: INFO: redistributing database "gbase"
tid[392445]: INFO: lock schema gbase.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上看检查gbase数据库,确实没有public.spatial。重新创建或导入即可。

相关推荐
葵野寺1 小时前
【MySQL】MySQL索引—B树/B+树
数据库·b树·mysql·b+树
隔壁老登1 小时前
解决dbeaver连接不上oceanbase数据库的问题
数据库·oceanbase
····懂···2 小时前
抢占先机,PostgreSQL 中级专家认证的职业跃迁
数据库·postgresql
Elastic 中国社区官方博客3 小时前
用于 UBI 的 Elasticsearch 插件:从搜索查询中分析用户行为
大数据·数据库·elasticsearch·搜索引擎·全文检索
小白不想白a3 小时前
【MySQL安全】什么是SQL注入,怎么避免这种攻击:前端防护、后端orm框架、数据库白名单
数据库·sql·mysql·安全
大路谈数字化3 小时前
Oracle 19C 在centos中安装操作步骤和说明
数据库·oracle
张彦峰ZYF3 小时前
联合索引全解析:一棵树,撑起查询的半边天
数据库·mysql
熏鱼的小迷弟Liu3 小时前
【MySQL】MySQL中锁有哪些?
数据库·mysql
我不是星海3 小时前
MySQL深度理解-MySQL锁机制
数据库·mysql