<div dir="ltr"><div>Hi David,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 20, 2021 at 6:23 AM David Cunningham <<a href="mailto:dcunningham@voisonics.com">dcunningham@voisonics.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>I've a few questions about conflict resolution in a net-split scenario:</div><div><br></div><div>1. What are the default values for cluster.server-quorum-type and cluster.server-quorum-ratio? (at the moment "gluster volume info gvol0" does not report either)<br></div><div><br></div></div></blockquote><div><font face="arial, sans-serif">$gluster volume get gvol0 <span style="color:rgb(0,0,0)">cluster.server-quorum-type</span></font></div><div><font face="arial, sans-serif"><span style="color:rgb(0,0,0)">$gluster volume get all </span><span style="color:rgb(0,0,0)">cluster.server-quorum-ratio</span></font></div><div><span style="color:rgb(0,0,0);font-family:monospace"><br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>2. If there are 3 mirrored nodes and cluster.server-quorum-ratio is 50, and node1 and node2 are net-split from node3, then am I right in thinking that the volume on node3 will automatically shut down and prevent access thus preventing a conflict?</div><div><br></div></div></blockquote><div>Yes, the glusterd on node 3 will kill the brick processes on that node.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>3. If there are 2 mirrored nodes and a net-split happens and cluster.server-quorum-ratio is 50 then:</div><div>a) If existing file A is changed on node1 and node2 then the file will enter net-split state, right?</div></div></blockquote><div><br></div><div>Yes, for 2 node setups, you must set the ratio to 51% to avoid this. I'm assuming that the 'changing' that you refer to is happening via fuse mounts on each of these nodes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>b) If existing file B is changed on node1 but not node2 then will the file enter a net-split state?</div></div></blockquote><div>No. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>c) If new file C is written on node1 but not node2 then will the file enter a net-split state?<br></div><div><br></div></div></blockquote><div>No. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>4. Is the outcome of conflict resolution at a file level the same whether node3 is a full replica or just an arbiter?<br></div><div><br></div></div></blockquote><div>server quorum feature is not related to replication. It really is a glusterd thing and doesn't really help prevent split-brains, because split-brains are caused by failed I/Os from clients and the clients can be mounted even outside the storage pool. What you need to ensure is that cluster.quorum-type (which is 'client' quorum) is set to auto for replica 3 and arbiter. It already is by default. See <a href="https://docs.gluster.org/en/latest/Administrator-Guide/arbiter-volumes-and-quorum/#split-brains-in-replica-volumes">https://docs.gluster.org/en/latest/Administrator-Guide/arbiter-volumes-and-quorum/#split-brains-in-replica-volumes</a> for more info. </div><div><br></div><div>-Ravi </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Thank you very much for any advice,<br></div><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>David Cunningham, Voisonics Limited<br><a href="http://voisonics.com/" target="_blank">http://voisonics.com/</a><br>USA: +1 213 221 1092<br>New Zealand: +64 (0)28 2558 3782</div></div></div></div></div></div></div></div></div></div></div></div>
________<br>
<br>
<br>
<br>
Community Meeting Calendar:<br>
<br>
Schedule -<br>
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br>
Bridge: <a href="https://meet.google.com/cpu-eiue-hvk" rel="noreferrer" target="_blank">https://meet.google.com/cpu-eiue-hvk</a><br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div></div>