shrinking volume

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

 



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



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux