[Gluster-users] 'replace-brick' - why we plan to deprecate
hans at shapeways.com
Tue Apr 9 12:31:28 UTC 2013
Amar Tumballi wrote on Thu Oct 11 18:35:32 UTC 2012 :
> When we initially came up with specs of 'glusterd', we needed an
> option to replace a dead brick, and few people even requested for
> having an option to migrate the data from the brick, when we are
> replacing it.
Do you specifically mean a 'dead' brick ? Or does your proposal hold for
a live brick too ?
(And doesn't a dead brick prevent one from reading data from it ?)
> The result of this is 'gluster volume replace-brick' CLI, and in the
> releases till 3.3.0 this was the only way to 'migrate' data off a
> removed brick properly.
> Now, with 3.3.0+ (ie, in upstream too), we have another *better*
> approach (technically), which is achieved by below methods:
> 2) (Distributed-)Replicate Volume:
> #gluster volume replace-brick <VOL> brick1 brick2 start 
> #gluster volume replace-brick <VOL> brick1 brick2 commit force
> (self-heal daemon takes care of syncing data from one brick to another)
For a dead brick this is OK. For a live brick this would break
redundancy during the long syncing time which is unacceptable.
What is the live brick replace-brick 3.3.1 status and roadmap ?
Hans Lambermont | Senior Architect
(t) +31407370104 (w) www.shapeways.com
More information about the Gluster-users