Re: Proper procedure to reduce an active volume

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

 



Il 03/02/21 18:15, Strahil Nikolov ha scritto:

Tks for the fast answer.

> Replica volumes do not require the 'start + commit' - it's needed only
> for distributed replicated volumes and other types of volumes.
> Yet, I'm not sure if removing a data brick (and keeping the arbiter)
> makes any sense. Usually, I just remove 1 data copy + the arbiter to 
> reshape the volume.
Well, actually I need to remove both data bricks and the arbiters w/o
losing the data. Probably that wasn't clear, sorry.

The current pods have 28x10TB disks and all the arbiters are on a VM.
The new pod does have only 26 disks.
What I want to do is remove one disk from each of the current pods, move
one of the freed disks to the new pod (this way each pod will have 27
disks and I'll have a cold spare to quickly replace a failed disk) and
distribute the arbiters between the three pods to dismiss the VM.
If possible, I'd prefer to keep redundancy (hence not going to replica 1
in an intermediate step).

> Keep in mind that as you remove a brick you need to specify the new
> replica count.
> For example you have 'replica 3 arbiter 1' and you want to remove the
> second copy and the arbiter:
> gluster volume remove-brick <VOLUME> replica 1 server2:/path/to/brick
> arbiter:/path/to/brick force
That's what I want to avoid :)
I need to migrate data out of s1:/bricks/27, s2:/bricks/27 and
s3:/arbiters/27 redistributing it to the remaining bricks.
BTW, isn't replica count an attribute of the whole volume?

> If you wish to reuse block devices, don't forget to rebuild the FS (as
> it's fastest way to cleanup)!
Yup. Already been bitten by eas :)

> When you increase the count (add second data brick and maybe arbiter),
> you should run:
> gluster volume add-brick <VOLUME> replica 3 arbiter 1
> server4:/path/to/brick arbiter2:/path/to/brick
> gluster volume heal <VOLUME> full
That will be useful when more disks will be added.
After removing the last bricks (isn't there a term for "all the
components of a replica set"? slice?) I thought I could move the
remaining bricks with replace-brick and keep a "rotating" distribution:
slice | s1  | s2  | s3
 00   | b00 | b00 | a00 (vm.a00 -> s2.a00)
 01   | a00 | b01 | b00 (s1.b01 -> s3.b00, vm.a01 -> s1.a00)
 02   | b01 | a00 | b01 (s1.b02 -> s1.b01, s2.b02 -> s3.b01, vm.a02 ->
s2.a00)
[and so on]
That will take quite a long time (IIUC I cannot move to a brick being
moved to another... or at least it doesn't seem wise :) ).
It's probably faster to first move arbiters and then the data.

-- 
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786
________



Community Meeting Calendar:

Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/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