2017-05-01 20:55 GMT+02:00 Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx>: > Replace-brick as a command is implemented with the goal of replacing a disk > that went bad. So the availability was already less. In 2013-2014 I proposed > that we do it by adding brick to just the replica set and increase its > replica-count just for that set once heal is complete we could remove this > brick. But at the point I didn't see any benefit to that approach, because > availability was already down by 1. But with all of this discussion it seems > like a good time to revive this idea. I saw that Shyam suggested the same in > the PR he mentioned before. Why availability is already less? replace-brick is usefull for adding a new disks (as we are discussing here) or if you have to preventive replace/dismiss a disk. If you have disks that are getting older and older, you can safely replace them one by one with replace-disks. Doing this way will keep you at desidered redundancy for the whole phase. If you just remove the older disk and let gluster to heal, you loose one replica. During the heal process another disk could fail and so on..... The same like with any RAID. If possible, adding the new disks and the remove the older one is better than brutally replace disks. "mdadm", with replace disks (and I think also ZFS) will add the new disks keeping full redundancy and after replacement is done, the older disk is decommissioned. I don't see any drawback in doing this even with gluster, only advantages. _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
