☰

在新服务器上恢复砖块失败 -

tag-icon • tag-icon filesystems glusterfs
在新服务器上恢复砖块失败 -

我正在尝试将另一台服务器上的砖块连接到本地 gluster 开发服务器。因此，我从生产服务器上的快照执行了 dd，并在开发服务器上的 lvm 卷上执行了 dd。然后，我删除了根目录上的 .glusterfs 文件夹。

不幸的是，尽管有信息表明新砖已经是卷的一部分，但形成新砖仍失败了。（gluster 怎么知道的？！）

然后我发布了以下内容：

sudo setfattr -x trusted.gfid /bricks/staging/brick1/
sudo setfattr -x trusted.glusterfs.volume-id /bricks/staging/brick1/
sudo /etc/init.d/glusterfs-server restart

神奇的是，gluster 似乎仍然知道这个砖块来自另一台服务器因为它知道在开发服务器上明显不同的对等 gluster 节点：

sudo gluster volume create staging node1:/bricks/staging/brick1

错误消息：

volume create: staging: failed: Staging failed on gs3. Error: Host node1 is not in 'Peer in Cluster' state

Staging failed on gs2. Error: Host node1 is not in 'Peer in Cluster' state

有没有办法在新服务器上恢复该块？感谢您对此提供的任何帮助。

答案1

您可以检查trusted.glusterfs.volume-id扩展属性是否已设置为 中的任何目录/bricks/staging/brick1/。Gluster 会使用此属性来查看砖块是否不是其他卷的一部分（或放置在其他砖块内）。

$ sudo getfattr -e hex -n rusted.glusterfs.volume-id /bricks/staging/brick1
$ sudo getfattr -e hex -n rusted.glusterfs.volume-id /bricks/staging
$ sudo getfattr -e hex -n rusted.glusterfs.volume-id /bricks

如果其中任何一个显示了volume-id，您可以使用setfattr之前使用的命令将其删除。

相关内容