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
