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

[Hans Lambermont]

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 ?


regards,
   Hans Lambermont
-- 
Hans Lambermont | Senior Architect
(t) +31407370104 (w) www.shapeways.com