Restaurando o tijolo em novas falhas do servidor -

Question

Estou tentando anexar um bloco de outro servidor a um servidor de desenvolvimento gluster local. Portanto, fiz um dd a partir de um instantâneo em produção e um dd no volume lvm em desenvolvimento. Então eu deletei a pasta .glusterfs na raiz.

Infelizmente, formar um novo tijolo falhou com a informação de que este tijolo já faz parte de um volume. (como o gluster sabe disso?!)

Em seguida, emiti o seguinte:

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

Magly gluster ainda parece saber que esse bloco é de outro servidor porque ele conhece os nós gluster pareados que são aparentemente diferentes no servidor dev:

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

Mensagem de erro:

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

Existe uma maneira de obter uma restauração desse bloco em um novo servidor? Obrigado por qualquer ajuda sobre isso.

    

Answer 1

Você pode verificar se o atributo trusted.glusterfs.volume-id extended está definido para qualquer um dos diretórios em /bricks/staging/brick1/ . Isso é o que o Gluster usa para ver se o tijolo não faz parte de outro volume (ou colocado dentro de outro tijolo).

$ 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

Se algum deles mostrar um id de volume, você poderá removê-lo com o comando setfattr usado anteriormente.