问题记录
- 官网上。。。
维护总结
原地址:https://blog.csdn.net/daydayup_gzm/article/details/52748859
某个GlusterFS节点的操作系统Down,需要重装系统和GlusterFS的场景。。
操作步骤:
- 别启动GlusterFS服务
重新安装GlusterFS后,设置好对应的Brick目录和挂载完对应的存储,暂时别启动GlusterFS服务。 - 获取该节点UUID信息
通过观察集群的其他节点保存的节点UUID信息,得到损坏节点的UUID信息。
ls命令查看一个完好节点的“/var/lib/glusterd/peers”目录,可以看到该集群其他节点所有的UUID,如图1所示。
逐个观察各完好节点的本身UUID信息(cat /var/lib/glusterd/glusterd.info),如图2所示。
结合两个结果进行排除,就可以损坏节点的原UUID信息。
- 在损坏节点配置原UUID信息
在/var/lib/glusterd/目录下,新建glusterd.info,按图2的格式,将原UUID和operating-version信息写入该文件。 - 重启GlusterFS服务
- 在该节点执行“gluster peer probe gf6”命令探测完好节点。
- 在该节点执行“gluster peer status”命令观察存储池的状态,如图3所示。
在第(5)步命令中那个完好的节点(gf6),也执行“gluster peer status”命令观察存储池的状态,如图4所示。
可以看到损坏的节点(gf2)在存储池节点的状态为“Peer Rejected (Connected)”。
- 重启损坏节点(gf2)的GlusterFS服务
在两个节点分别观察存储池节点的状态,应该可以发现损坏的节点,已经正常连接到存储池中。
- 触发该节点进行数据同步
在客户端的挂载点使用ls命令遍历集群目录,该节点就启动文件自愈功能,从老的备份节点将数据同步过来。
注意:当数据较大时,整个同步过程较为耗时。
- 测试损坏节点是否可写文件
在客户端的挂载目录,新建多个文件,观察新建的文件能否写在该节点上。
测试如下:通过touch命令,新建数个文件。
在原来损坏的节点的brcik目录下观察能否写入文件
命令:
mkdir ...bricks... ls /var/lib/glusterd/peers ll /var/lib/glusterd/peers cat /var/lib/glusterd/glusterd.info vi /var/lib/glusterd/glusterd.info gluster peer probe gfs1 gluster peer status ls ....挂载客户端 touch ...