[Gluster-users] shrinking volume

[Brian Cipriano]

Ah, great! Thanks Harry!

Time to upgrade to 3.3 :)

- brian

On 6/21/12 12:43 PM, harry mangalam wrote:
> In 3.3, this is exactly what 'remove-brick' does.  It migrates the data
> off an active volume, and when it's done, allows the removed brick to be
> upgraded, shut down, killed off etc.
>
> gluster volume  remove-brick<vol>  server:/brick  start
>
> (takes a while to start up, but then goes fairly rapidly.)
>
> following is the result of a recent remove-brick I did with 3.3
>
> % gluster volume  remove-brick gl bs1:/raid1  status
>       Node Rebalanced-files          size       scanned      failures
> status
> ---------      -----------   -----------   -----------   -----------
> ------------
> localhost                2  10488397779           12            0    in
> progress
>        bs2                0            0            0            0    not
> started
>        bs3                0            0            0            0    not
> started
>        bs4                0            0            0            0    not
> started
>
> (time passes )
>
> $ gluster volume  remove-brick gl bs1:/raid2  status
>                                      Node Rebalanced-files          size
> scanned      failures         status
>                                 ---------      -----------   -----------
> -----------   -----------   ------------
>                                 localhost              952  26889337908
> 8306            0      completed
>
>
>
> Note that once the 'status' says completed, you need to issue the
> remove-brick command again to actually finalize the operation.
>
> And that 'remove-brick' command will not clear the dir structure on the
> removed brick.
>
>
> On Thu, 2012-06-21 at 12:29 -0400, Brian Cipriano wrote:
>> Hi all - is there a safe way to shrink an active gluster volume without
>> losing files?
>>
>> I've used remove-brick before, but this causes the files on that brick
>> to be removed from the volume. Which is fine for some situations.
>>
>> But I'm trying to remove a brick without losing files. This is because
>> our file usage can grow dramatically over short periods. During those
>> times we add a lot of buffer to our gluster volume, to keep it at about
>> 50% usage. After things settle down and file usage isn't changing as
>> much, we'd like to remove some bricks in order to keep usage at about
>> 80%. (These bricks are AWS EBS volumes - we want to remove the bricks to
>> save a little $ when things are slow.)
>>
>> So what I'd like to do is the following. This is a simple distributed
>> volume, no replication.
>>
>> * Let gluster know I want to remove a brick
>> * No new files will go to that brick
>> * Gluster starts copying files from that brick to other bricks,
>> essentially rebalancing the data
>> * Once all files have been duplicated onto other bricks, the brick is
>> marked as "removed" and I can do a normal remove-brick
>> * Over the course of this procedure the files are always available
>> because there's always at least one active copy of every file
>>
>> This procedure seems very similar to replace-brick, except the goal
>> would be to evenly distribute to all other active bricks (without
>> interfering with pre-exiting files), not one new brick.
>>
>> Is there any way to do this?
>>
>> I *could* just do my remove-brick, then manually distribute the files
>> from that old brick back onto the volume, but that would cause those
>> files to become unavailable for some amount of time.
>>
>> Many thanks for all your help,
>>
>> - brian
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users