[Gluster-users] 'replace-brick' - why we plan to deprecate

Hans Lambermont 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:
> earlier:
> #gluster volume replace-brick <VOL> brick1 brick2 start [1]
> now:
> #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
Hans Lambermont | Senior Architect
(t) +31407370104 (w) www.shapeways.com

More information about the Gluster-users mailing list