<div dir="ltr">Hi Dave,<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 26, 2018 at 4:45 PM, Dave Sherohman <span dir="ltr"><<a href="mailto:dave@sherohman.org" target="_blank">dave@sherohman.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've configured 6 bricks as distributed-replicated with replica 2,<br>
expecting that all active bricks would be usable so long as a quorum of<br>
at least 4 live bricks is maintained.<br></blockquote><div>The client quorum is configured per replica sub volume and not for the entire volume.<br></div><div>Since you have a distributed-replicated volume with replica 2, the data will have 2 copies,<br></div><div>and considering your scenario of quorum to be taken on the total number of bricks will lead to split-brains.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
However, I have just found<br>
<br>
<a href="http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/" rel="noreferrer" target="_blank">http://docs.gluster.org/en/<wbr>latest/Administrator%20Guide/<wbr>Split%20brain%20and%20ways%<wbr>20to%20deal%20with%20it/</a><br>
<br>
Which states that "In a replica 2 volume... If we set the client-quorum<br>
option to auto, then the first brick must always be up, irrespective of<br>
the status of the second brick. If only the second brick is up, the<br>
subvolume becomes read-only."<br></blockquote><div>By default client-quorum is "none" in replica 2 volume. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Does this apply only to a two-brick replica 2 volume or does it apply to<br>
all replica 2 volumes, even if they have, say, 6 bricks total?<br></blockquote><div>It applies to all the replica 2 volumes even if it has just 2 brick or more.<br></div><div>Total brick count in the volume doesn't matter for the quorum, what matters<br>is the number of bricks which are up in the particular replica subvol.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If it does apply to distributed-replicated volumes with >2 bricks,<br>
what's the reasoning for it? I would expect that, if the cluster splits<br>
into brick 1 by itself and bricks 2-3-4-5-6 still together, then brick 1<br>
will recognize that it doesn't have volume-wide quorum and reject<br>
writes, thus allowing brick 2 to remain authoritative and able to accept<br>
writes.<br></blockquote><div>If I understood your configuration correctly it should look something like this:<br>(Please correct me if I am wrong)<br></div><div>replica-1: bricks 1 & 2<br></div><div>replica-2: bricks 3 & 4<br></div><div>replica-3: bricks 5 & 6<br></div><div>Since quorum is per replica, if it is set to auto then it needs the first brick of the particular replica subvol to be up to perform the fop.<br><br></div><div>In replica 2 volumes you can end up in split-brains. It would be great if you can consider configuring an arbiter or replica 3 volume.<br></div><div>You can find more details about their advantages over replica 2 volume in the same document.<br><br></div><div>Regards,<br></div><div>Karthik<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
Dave Sherohman<br>
______________________________<wbr>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-users</a><br>
</font></span></blockquote></div><br></div></div>