[Gluster-users] how to detach the peer off line, which carries data
grunthos503 at yahoo.com
Mon May 2 18:12:11 UTC 2016
> From: ?? <yzlyourself at gmail.com>
> I have 3 peers. eg. P1, P2 and P3, and each of them has 2 bricks,
> e.g. P1 have 2 bricks, b1 and b2.
> P2 has 2 bricks, b3 and b4.
> P3 has 2 bricks, b5 and b6.
> Based that above, I create a volume (afr volume) like this:
> b1 and b3 make up a replicate subvolume rep-sub1
> b4 and b5 make up a replicate subvolume rep-sub2
> b2 and b6 make up a replicate sub volume rep-sub3
> And rep-sub1,2,3 make up a distribute volume, AND start the volume.
> now, p1 has a crash or it just disconnected. I want to detach P1 and the
> volume has started absolutely can?t be stop or deleted.
> if there is a method to detach P1 in the scenes above.
Yes. The way to do this is to fix the bricks first, and then you can detach the problem machine.
If P1 is down, then bricks b1 and b2 are down. That means half of rep-sub1 is missing, and half of rep-sub3 is missing.
First you need to fix rep-sub1 and rep-sub3 by creating replacement bricks.
You need a new machine to replace P1. Let's call it P4, with bricks b7 and b8. Do a replace-brick to replace b1 with b7, and b2 with b8.
gluster vol replace-brick VOLUME_NAME P1:b1 P4:b7 commit force
gluster vol replace-brick VOLUME_NAME P1:b2 P4:b8 commit force
gluster vol heal VOLUME_NAME full
After you do that, then P1 is no longer needed, and you should be able to remove it.
Definitely DO NOT edit the code to remove important safety-checks!
Think of it this way: The most important thing here is your DATA, not your machines. You don't want to leave your replicated bricks unprotected, so the FIRST thing to do is get them protected by replicating to new bricks. Removing the machine that is down is the last thing to do, not the first.
More information about the Gluster-users