GBase 8a服务gcluster和gnode状态CLOSE排查,gbase用户被重建导致目录属主不正确

今天遇到一个集群重启后,gcware正常,gcluster和gnode都显示CLOSE状态,经过排查,是因为集群依赖的操作系统用户gbase被意外重建了,导致安装目录的属主不正确,没有权限访问导致。

错误现象

gcware正常,gcluster和gnode都显示CLOSE状态

gcware正常,gcluster和gnode都显示CLOSE状态
gcware正常,gcluster和gnode都显示CLOSE状态

排查过程

重点是gnode服务是不依赖其它服务的,而gcluster依赖gcware。因为gcware部署在根目录下,而gcluster,gnode目录一般都是默认都是单独挂载一块大容量磁盘的,所有先怀疑是文件系统没有挂载,导致服务找不到可执行文件。

检查挂载情况

df -h检查,发现挂载正常,/opt/gbase存在。既然磁盘挂载正常,那检查一下服务的启动日志system.log看什么报错信息。

df -h检查发现挂载正常
df -h检查发现挂载正常

检查启动日志

查看gnode服务system.log日志,发现 No Space left on device和No such file or directory的报错信息,怀疑磁盘空间满了。结合前面的df -h容量没满,后续检查inode是否满了。

检查inode

df -i 发现inode没有满,但为啥会出现空间不足,以及文件不存在的报错呢? 日志里没有更多信息。后面尝试重启服务,再次查看报错日志是否有变动。

df -i 发现inode没有满
df -i 发现inode没有满

尝试重启服务

用户反馈日志无任何变动,并没有新的日志生成。后续单独启动服务进程,查看报错信息。

单独启动服务进程

却换到gbase用户(su – gbase),然后运行gbased进程,发现报错信息

can’t create test file,和 Can’t change dir to XXX (Errcode: 13)

查看操作系统报错码。errcode 13对应Permission denied, 拒绝访问,怀疑权限有问题。

报错信息can't create test file,和 Can't change dir to XXX (Errcode: 13)
报错信息can’t create test file,和 Can’t change dir to XXX (Errcode: 13)

查看文件权限

发现数据库安装目录的宿主丢失,变成了1034,而用户组还是gbase。

至此确诊,是权限问题导致。猜测是操作系统用户gbase被重建了,导致原来属于gbase的目录变成了uid(1034)。

数据库安装目录的宿主丢失,变成了1034,而用户组还是gbase。
数据库安装目录的宿主丢失,变成了1034,而用户组还是gbase。

解决方案

通过 chown -R gbase:gbase XXX 将数据库目录和文件修改成正确的属主。 重启服务后集群恢复正常。

总结

操作系统gbase用户是数据库的安装和运行用户,程序是以gbase用户启动和运行,而一旦操作系统用户gbase被重建,将导致属主变动,目录无法访问(写入),导致启动失败。

发表评论

您的电子邮箱地址不会被公开。