Bug 763684 (GLUSTER-1952) - Improvement for migrate functionality
Summary: Improvement for migrate functionality
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: GLUSTER-1952
Product: GlusterFS
Classification: Community
Component: distribute
Version: 3.2.1
Hardware: All
OS: All
low
low
Target Milestone: ---
Assignee: Amar Tumballi
QA Contact:
URL:
Whiteboard:
: GLUSTER-2457 765217 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-14 15:44 UTC by Jacob Shucart
Modified: 2015-12-01 16:45 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Jacob Shucart 2010-10-14 15:44:40 UTC
Looking at the documentation, right now it seems that you can only migrate data from a brick to another brick which is not currently being used.  Please add functionality where you can migrate data off of a brick and spread it across the other nodes in the cluster.  Having to have a new node for the data to go to may not always work.

Comment 1 Amar Tumballi 2011-04-25 09:33:48 UTC
Please update the status of this bug as its been more than 6months since its filed (bug id < 2000)

Please resolve it with proper resolution if its not valid anymore. If its still valid and not critical, move it to 'enhancement' severity.

Comment 2 Jacob Shucart 2011-05-23 15:25:42 UTC
This is becoming more important especially in Amazon where you will want to expand and shrink your Gluster environment to meet performance spikes.

Comment 3 Joe Julian 2011-07-05 15:56:04 UTC
This is still valid. There is no way to migrate data off of a dht subvolume that you might wish to remove.

Comment 4 Amar Tumballi 2011-07-06 09:21:32 UTC
*** Bug 2457 has been marked as a duplicate of this bug. ***

Comment 5 Jacob Shucart 2011-07-26 12:01:52 UTC
Again, this is an important feature necessary for maintenance in environments where people don't have extra servers laying around to use replace-brick.  Is it really going into 3.3.0?

Comment 6 Amar Tumballi 2011-09-09 11:32:19 UTC
patch submitted at http://review.gluster.com/118 hopefully should make it to release 3.3.0

Comment 7 Amar Tumballi 2011-09-09 11:33:12 UTC
*** Bug 3485 has been marked as a duplicate of this bug. ***

Comment 8 William L. Sebok 2011-09-09 12:11:27 UTC
Hopefully this feature will be robust against one of the bricks in a cluster/replicate group being down, either because of disk or computer failure. That is the main reason that I would try to remove a brick.  I would want to remove the whole cluster/replicate group with the idea that the data would be available from the other members of the group and then distributed to the the other servers.

Comment 9 Anand Avati 2011-09-13 06:10:14 UTC
CHANGE: http://review.gluster.com/118 (to achieve this, we now create volume-file with) merged in master by Vijay Bellur (vijay)

Comment 10 Amar Tumballi 2011-09-14 07:37:11 UTC
commit log:

----
    support for de-commissioning a node using 'remove-brick'
    
    to achieve this, we now create volume-file with
    'decommissioned-nodes' option in distribute volume, then just
    perform the rebalance set of operations (with 'force' flag set).
    
    now onwards, the 'remove-brick' (with 'start' option) operation tries
    to migrate data from removed bricks to existing bricks.
    
    'remove-brick' also supports similar options as of replace-brick.
    
    * (no options) -> works as 'force', will have the current behavior
             of remove-brick, ie., no data-migration, volume changes.
    
    * start  (starts remove-brick with data-migration/draining process,
              which takes care of migrating data and once complete, will
              commit the changes to volume file)
    * pause  (stop data migration, but keep the volume file intact with
              extra options whatever is set)
    * abort  (stop data-migration, and fall back to old configuration)
    * commit (if volume is stopped, commits the changes to volumefile)
    * force  (stops the data-migration and commits the changes to
              volume file)
    
    Change-Id: I3952bcfbe604a0952e68b6accace7014d5e401d3
    BUG: 1952
    Reviewed-on: http://review.gluster.com/118
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Vijay Bellur <vijay>

----

Will mark this resolved. Will open different bugs for specific issues/bugs within this feature.

Comment 11 Anand Avati 2011-10-11 07:37:54 UTC
CHANGE: http://review.gluster.com/551 (currently if 'remove-brick <BRICKS> start' is given, after all) merged in master by Vijay Bellur (vijay)


Note You need to log in before you can comment on or make changes to this bug.