Hi all,<br><br>We've been using gluster 3.2.X without much issue and we were trying next version (3.3) compiled from sources on a ubuntu 12.04 server:<br><br>glusterfs 3.3.0 built on Jun 7 2012 11:19:51<br>Repository revision: git://<a href="http://git.gluster.com/glusterfs.git">git.gluster.com/glusterfs.git</a><br>
Copyright (c) 2006-2011 Gluster Inc. <<a href="http://www.gluster.com">http://www.gluster.com</a>><br>GlusterFS comes with ABSOLUTELY NO WARRANTY.<br>You may redistribute copies of GlusterFS under the terms of the GNU General Public License.<br>
<br>We're using a replicated distributed architecture with 8 nodes in a 2-replica configuration.<br><br>On the client side we're using gluster native libraries to mount the gluster volume and recently we found an issue with 1 file <br>
<br>[2012-06-25 14:58:22.161036] W [afr-self-heal-data.c:831:afr_lookup_select_read_child_by_txn_type] 0-cloud-replicate-2:$FILE: Possible split-brain<br>[2012-06-25 14:58:22.161098] W [afr-common.c:1226:afr_detect_self_heal_by_lookup_status] 0-cloud-replicate-2: split brain detected during lookup of $FILE<br>
[2012-06-25 14:58:22.161881] E [afr-self-heal-common.c:2156:afr_self_heal_completion_cbk] 0-cloud-replicate-2: background data gfid self-heal failed on $FILE<br><br>I located the 2 bricks (servers) were the file was located, and the file was ok in both nodes as expected. I tried to delete both the file and the hard link in one node, perform a self-healing on the client, and the file was recreated in the missing node but the file was not yet accessible from the client.<br>
<br>I made the same procedure on the other node (delete file and hard link) and launch self-healing and the file is not yet accessible.<br><br>Is there any guide or procedure to handle split brains on 3.3?<br><br>Thanks in advance,<br>
Samuel.<br>