Я пытаюсь прикрепить кирпич с другого сервера к локальному серверу разработки gluster. Поэтому я сделал дд из моментального снимка на производстве и дд на томе lvm при разработке. Затем я удалил папку .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
Есть ли способ восстановить этот кирпич на новом сервере? Спасибо за любую помощь по этому поводу.
Вы можете проверить, есть ли 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
Если какой-либо из них показывает идентификатор тома, вы можете удалить его с помощью setfattr команда, которую вы использовали ранее.