GBase8a运维案例分析 – 老紫竹的家

GBase8a运维案例分析：建表时报no space left on device

GBase 8a使用操作系统的文件系统，以目录和文件的形式组织数据。如果操作系统空间满，或者没有写入权限，会报 no space left on device. 但本文记录了排查过程，最终是用户未停服务，直接mv走数据库所有文件造成的。重启服务后，恢复。

极少见的场景，排查的结果，GBase 8a宕机，是被操作系统kill掉了，而kill的原因是访问了不可用的内存，但又不是segment_fault, 而是内存坏了。

GBase 8a当出现主副本不一致时，会记录event,信息里ObjectName包含了库和表的名字，比如db1.Table1这样。本文介绍一个建库故障，导致只有一个字符串的情况。

linux的防火墙对ipv6的配置里，如果将icmp包全部drop掉，将导致无法访问ipv6网络，本文介绍一例该原因导致的同步一直报错的现场运维案例。

GBase 8a从V8.6Build43开始支持ipv6,但早期都是直接安装时就是ipv6。本周1，在上东移动某2个项目中，配合应用厂商，成功的将数据库切换到ipv6，系统运行一切正常。

GBase 8a运维案例，GBase 8a 数据库某些操作时，节点服务内部会临时创建连接，操作完成后关闭，如果在某个阶段时操作系统没有可用的本地端口，将会造成连接失败，涉及的表也将无法确保状态正确，于是设置了event标记。

某项目共20个节点的GBase 8a 9.5.3版本集群，发生2台服务器硬件故障，其中1台纯数据数据节点，另一台是管理gcware+调度coordinator+数据计算服务gnode的复合节点，本文记录整个操作过程。

GBase 8a集群上线项目扩容操作，最终用户出于安全考虑，都会做安全加固，结果就是一些命令表面看着很正常，可是一旦远程运行，或者多几次用户su切换，就会出问题。

某客户反馈，扩容操作重分布已经快1个月了，发现每天就完成十几个表，按照这个速度，需要半年以上。经过排查，发现客户是在云环境，部分计算节点之间，出现严重的网络问题，上行和下行速度都极差(500K-2MB),正常的至少150MB。

客户现场一般都做了安全加固，如果某些服务，有连接频率限制，可能会导致性能问题。本文介绍的一个案例是客户的sftp服务加载，导致的加载性能慢的情况。