点击上方“IT那活儿”,关注后了解更多内容,不管IT什么活儿,干就完了!!!
环境描述
名称:操作系统
版本:Linux version:redhat 7.4
名称:Greenplum
版本:Database:greenplum4.3.30.4
问题描述
在生产环境中我们所维护的greenplum集群偶尔会遇到segments节点实例宕停的情况,导致实例宕停的因素比较多。
如:硬件上的磁盘故障导致io较高,内网的网络波动。sql语法的不规范导致资源消耗过大,大批量的调度语句集中在一个时间点导致集群压力太大。相关参数上的设置过小等等.....
这样的原因都会导致集群某一个或多个mirrror实例在固定的时间点宕机,以上的情况一般不会导致primary宕机,但是也不一定遇到primary也可以按照以下方法排查原因。
排查方法
1. 排查是否是硬件的问题,查看主机日志messages
路径:/var/log/messages
查看是否是降级导致的,磁盘降级的关键词根据主机厂商不同一般不一样。
如果是内存或者别的硬件导致的就执行以下命令(如果是硬件导致可能会有primary实例宕停)。
cat /var/log/messages | grep ker
具体的报错信息需根据经验判断。
gpstate -e
可以看到主机名后面的就是宕停实例的目录路径。
登录gp2切换到pg_log目录下:
可以看到按日期生成的.csv文件,这就是数据库日志。
但是有的文件后缀不是000000,是为什么?
数据库日志文件本身就是“gpdb-年-月-日_时间“,显示000000是因为在凌晨12点整生成的,而那些不是000000的则是因为该实例宕停不在记录日志信息只有把实例拉起时才会继续记录,而拉起宕停实例的时间就会自动生成一个对应的.csv文件。
查看相应的日志文件可以看到红色标记的哪一行有“WARING“关键词,而后面的信息就是当该实例宕停时所打印的信息。而报错信息的大概意思就是”在连接时收到了关闭信息并且成功了“,为什么会导致这样的情况?
根据网上得到的方案可以修改的参数有这两个:
这个参数简单的说就是在Master和Segment之间的探测超时时长。
导致的原因可能时那个时间点集群的压力过大,通信超时,可以将时间调高点。
这里引用greenplum6.0.1的解释:
3. sql语句的原因
这里就需要在master主机部署一个记录集群会话的脚本,将宕机时间点的sql反馈给应用让他们检查是否有问题,或者将宕机时间点的会话分散执行。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/129540.html
摘要:下安装配置文档一系统要求系统版本要求根据官方文档支持以下几种系统文件系统要求数据存储目录为文件系统二下安装服务器列表主节点数据节点数据节点主节点切换备用节点修改系统配置项关闭关闭防火墙修改内核配置参数并执行使之生 centos7.3下 greenplum-db 安装、配置文档 一.系统要求 1.系统版本要求:根据官方文档: greenplumd-b支持以下几种linux系统: ...
摘要:上有主节点和从节点两部分,两者主要的功能是生成查询计划并派发,以及协调并行计算,同时在上保存着,这个全局目录存着一组数据库系统本身所具有的元数据的系统表。 前言:近年来,互联网的快速发展积累了海量大数据,而在这些大数据的处理上,不同技术栈所具备的性能也有所不同,如何快速有效地处理这些庞大的数据仓,成为很多运营者为之苦恼的问题!随着Greenplum的异军突起,以往大数据仓库所面临的很多...
摘要:冒烟类型测试冒烟测试这个术语的定义一系列初步的测试来揭示一些简单的故障的严重性,以此来拒绝预期中软件的发布。冒烟测试最频繁的特点就是它运行的很快,通常是秒级的。 Satellite是硅谷初创公司Gravitational公司旗下一个用Go写的开源项目,可用来收集Kubernetes集群的健康信息,它既是一个library,也是一个应用。作为library,可以用做监控方案。在这篇文章里...
阅读 1346·2023-01-11 13:20
阅读 1684·2023-01-11 13:20
阅读 1132·2023-01-11 13:20
阅读 1858·2023-01-11 13:20
阅读 4100·2023-01-11 13:20
阅读 2704·2023-01-11 13:20
阅读 1385·2023-01-11 13:20
阅读 3597·2023-01-11 13:20