GlusterFS使用记录

问题记录

1. 官网上。。。

维护总结

原地址：https://blog.csdn.net/daydayup_gzm/article/details/52748859

某个GlusterFS节点的操作系统Down，需要重装系统和GlusterFS的场景。。

操作步骤：

1. 别启动GlusterFS服务
   重新安装GlusterFS后，设置好对应的Brick目录和挂载完对应的存储，暂时别启动GlusterFS服务。
2. 获取该节点UUID信息
   通过观察集群的其他节点保存的节点UUID信息，得到损坏节点的UUID信息。
   ls命令查看一个完好节点的“/var/lib/glusterd/peers”目录，可以看到该集群其他节点所有的UUID，如图1所示。
   
   

   逐个观察各完好节点的本身UUID信息（cat /var/lib/glusterd/glusterd.info），如图2所示。

   
   
   

   结合两个结果进行排除，就可以损坏节点的原UUID信息。

3. 在损坏节点配置原UUID信息
   在/var/lib/glusterd/目录下，新建glusterd.info，按图2的格式，将原UUID和operating-version信息写入该文件。
4. 重启GlusterFS服务
5. 在该节点执行“gluster peer probe gf6”命令探测完好节点。
6. 在该节点执行“gluster peer status”命令观察存储池的状态，如图3所示。
   
   

   在第（5）步命令中那个完好的节点（gf6），也执行“gluster peer status”命令观察存储池的状态，如图4所示。

   

   可以看到损坏的节点（gf2）在存储池节点的状态为“Peer Rejected (Connected)”。

7. 重启损坏节点（gf2）的GlusterFS服务
   

   在两个节点分别观察存储池节点的状态，应该可以发现损坏的节点，已经正常连接到存储池中。

8. 触发该节点进行数据同步
   

   在客户端的挂载点使用ls命令遍历集群目录，该节点就启动文件自愈功能，从老的备份节点将数据同步过来。

   注意：当数据较大时，整个同步过程较为耗时。

9. 测试损坏节点是否可写文件
   

   在客户端的挂载目录，新建多个文件，观察新建的文件能否写在该节点上。

   测试如下：通过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 ...