gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Amar Tumballi
Subject: [Gluster-devel] 'replace-brick' - why we plan to deprecate
Date: Fri, 12 Oct 2012 00:05:32 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

Hi All,

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.

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:
========

1) Distribute volume:

earlier:

#gluster volume replace-brick <VOL> brick1 brick2 start [1]

alternative/now:

#gluster volume add-brick <VOL> brick2
#gluster volume remove-brick <VOL> brick1 start
(above does rebalance which is intelligent now to understand that all data in brick1 should get moved to brick2)

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)

3) (Distributed-)Stripe Volume:

earlier:

#gluster volume replace-brick <VOL> brick1 brick2 start [1]
(this would have caused brick2 to consume much more space than brick1 as it would have filled up the holes with 0s)

now:

if one needs data migration:

# gluster volume add-brick <VOL> brickN ... brickN+M (M == number of stripe)
# gluster volume remove-brick <VOL> brick1 ... brickM start (all bricks of the stripe subvol which has the brick to be removed). [1]

but as we recommend stripe volume for 'only' scratch data, I personally recommend using below volume instead, if stripe is absolutely necessary:

4) (Distributed-)Stripe-Replicate Volume:

earlier:

I never tried (the volume type is new), but the semantic is generally same:

#gluster volume replace-brick <VOL> brick1 brick2 start [1]


now:

# gluster volume replace-brick <VOL> brick1 brick2 commit force
(self-heal daemon heals the data)


================

Let me know if anyone has objections with discarding replace-brick data migration.

Regards,
Amar

[1] - (checking status and doing a 'commit' after 'start' is part of both replace-brick and remove-brick CLI to finish the task completely, with data migration).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]