Dear list,
I seem to have gotten into a tricky situation. Today I brought up a shiny new server with new disk arrays and attempted to replace one brick of a replica 2 distribute/replicate volume on an older server using the `replace-brick` command:
# gluster volume replace-brick homes wingu0:/mnt/gluster/homes wingu06:/data/glusterfs/sdb/homes commit force
The command was successful and I see the new brick in the output of `gluster volume info`. The problem is that Gluster doesn't seem to be migrating the data, and now the original brick that I replaced is no longer part of the volume (and a few terabytes of data are just sitting on the old brick):
# gluster volume info homes | grep -E "Brick[0-9]:"
Brick1: wingu4:/mnt/gluster/homes
Brick2: wingu3:/mnt/gluster/homes
Brick3: wingu06:/data/glusterfs/sdb/homes
Brick4: wingu05:/data/glusterfs/sdb/homes
Brick5: wingu05:/data/glusterfs/sdc/homes
Brick6: wingu06:/data/glusterfs/sdc/homes
Brick1: wingu4:/mnt/gluster/homes
Brick2: wingu3:/mnt/gluster/homes
Brick3: wingu06:/data/glusterfs/sdb/homes
Brick4: wingu05:/data/glusterfs/sdb/homes
Brick5: wingu05:/data/glusterfs/sdc/homes
Brick6: wingu06:/data/glusterfs/sdc/homes
I see the Gluster docs have a more complicated procedure for replacing bricks that involves getfattr/setfattr¹. How can I tell Gluster about the old brick? I see that I have a backup of the old volfile thanks to yum's rpmsave function if that helps.
We are using Gluster 5.6 on CentOS 7. Thank you for any advice you can give.
--
Alan Orth
alan.orth@xxxxxxxxx
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch
"In heaven all the interesting people are missing." ―Friedrich Nietzsche
alan.orth@xxxxxxxxx
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch
"In heaven all the interesting people are missing." ―Friedrich Nietzsche
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-users