[Gluster-users] how to detach the peer off line, which carries data

[Alan Millar]

> 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.

- Alan