[Gluster-users] Issues removing then adding a brick to a replica volume (Gluster 3.7.6)

[Krutika Dhananjay]

----- Original Message -----

> From: "Lindsay Mathieson" <lindsay.mathieson at gmail.com>
> To: "Krutika Dhananjay" <kdhananj at redhat.com>
> Cc: "gluster-users" <gluster-users at gluster.org>
> Sent: Monday, January 18, 2016 7:38:44 PM
> Subject: Re: [Gluster-users] Issues removing then adding a brick to a replica
> volume (Gluster 3.7.6)

> On 18/01/2016 10:24 PM, Krutika Dhananjay wrote:

> > Heal _is_ necessary when you add a brick that changes the replica count
> > from
> > n to (n+1). Now the new brick that is also part of the existing replica set
> > is lagging with respect to the existing bricks
> 
> > and needs to be brought in sync with these. All files and directories in
> > vna
> > and/or vnb will be healed to vng in your case.
> 

> Yes I realise that :)

> I was under the impression that heal info lists the files that are the src of
> the heal, e.g all the files on vna & vnb.

> vng which is blank would only be receiving files.

> > Yes, there is a bug report for this @
> > https://bugzilla.redhat.com/show_bug.cgi?id=1112158 .
> 
> > The workaround, like you yourself figured, is to run the command on the
> > node
> > with the highest uuid.
> 
> > Steps:
> 
> > 1) Collect output of `cat /var/lib/glusterd/glusterd.info | grep UUID` from
> > each of the nodes, perhaps into a file named 'uuid.txt'.
> 
> > 2) cat uuid.txt | sort
> 
> > 3) Pick the last gfid.
> 
> > 4) find out which of the glusterd.info files has the same uuid as this
> > selected uuid.
> 
> > 5) Run 'heal info full' on that same node.
> 

> Will do.

> And I still have the problem with the files becoming unreadable when adding a
> brick.
What do you mean by files becoming unreadable? Could you throw some light on this? Do you have the client logs? 

-Krutika 

> Thanks,

> --
> Lindsay Mathieson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160119/19284ffc/attachment.html>