<div dir="ltr">Once the volume is created as an Arbiter volume can it at a later time be changed to a replica 3 with all bricks containing data?</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><span><font color="#888888"><span style="color:rgb(0,0,0)"><b><i>David Gossage</i></b></span><font><i><span style="color:rgb(51,51,51)"><b><br>

</b></span></i></font></font></span><div><span><font color="#888888"><font><i><span style="color:rgb(51,51,51)"></span></i><font size="1"><b style="color:rgb(153,0,0)">Carousel Checks Inc.<span style="color:rgb(204,204,204)"> | System Administrator</span></b></font></font><font style="color:rgb(153,153,153)"><font size="1"><br>



</font></font><font><font size="1"><span style="color:rgb(51,51,51)"><b style="color:rgb(153,153,153)">Office</b><span style="color:rgb(153,153,153)"> <a value="+17086132426">708.613.2284<font color="#888888"><font size="1"><br></font></font></a></span></span></font></font></font></span></div></div></div></div>
<br><div class="gmail_quote">On Tue, Sep 8, 2015 at 8:46 PM, Ravishankar N <span dir="ltr">&lt;<a href="mailto:ravishankar@redhat.com" target="_blank">ravishankar@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <small>Sending out this mail for awareness/ feedback.<br>
-----------------------------------------------------------------------------<br>
      <b>What:</b><b><br>
      </b>Since glusterfs-3.7,  AFR supports creation of arbiter
      volumes. These are a special type of replica 3 gluster volume
      where the 3rd brick  is (always) configured as an arbiter
      node.What this means is that the 3rd brick will store only the
      file name and metadata (including gluster xattrs), but does not
      contain any data. Arbiter volumes prevent split-brains and
      consumes lesser space than a normal replica 3 volume and provides
      better consistency and availability than a replica 2 volume.<br>
      <br>
      <b>How:</b><b><br>
      </b>You can create an arbiter volume with the following command:<br>
      <i><br>
        gluster volume create &lt;VOLNAME&gt; replica 3 arbiter 1
        host1:brick1 host2:brick2 host3:brick3</i><br>
      <br>
      Note that the syntax is similar to creating a normal replica 3
      volume with the exception of the <i>arbiter 1</i> keyword. As
      seen in the command above, the only permissible values for the
      replica count and arbiter count are 3 and 1 respectively. Also,
      the 3rd brick is always chosen as the arbiter brick and it is
      currently not configurable to have any other brick as the arbiter.<br>
      <br>
      <b>Client/ Mount behaviour:</b><b><br>
      </b>By default, client quorum (cluster.quorum-type) is set to auto
      for a replica 3 volume (including arbiter volumes) when it is
      created; i.e. at least 2 bricks need to be up to satisfy quorum
      and to allow writes. This setting is not to be changed for arbiter
      volumes also. Additionally, the arbiter volume has some additional
      checks to prevent files from ending up in split-brain:<br>
      <br>
          * Clients take full file locks when writing to a file as
      opposed to range locks in a normal replica 3 volume.<br>
      <br>
          * If 2 bricks are up and if one of them is the arbiter (i.e.
      the 3rd brick) and it blames the other up brick, then all FOPS
      will fail with ENOTCONN (Transport endpoint is not connected). If
      the arbiter doesn&#39;t blame the other brick, FOPS will be allowed to
      proceed. &#39;Blaming&#39; here is w.r.t the values of AFR changelog
      extended attributes.<br>
      <br>
          * If 2 bricks are up and the arbiter is down, then FOPS will
      be allowed.<br>
      <br>
          * In all cases, if there is only one source before the FOP is
      initiated and if the FOP fails on that source, the application
      will receive ENOTCONN.<br>
      <br>
      Note: It is possible to see if a replica 3 volume has arbiter
      configuration from the mount point. If<i>
        $mount_point/.meta/graphs/active/$V0-replicate-0/options/arbiter-count</i>
      exists and its value is 1, then it is an arbiter volume. Also the
      client volume graph will have arbiter-count as a xlator option for
      AFR translators.<br>
      <br>
      <b>Self-heal daemon behaviour:</b><br>
      <br>
      Since the arbiter brick does not store any data for the files, it
      cannot be used as a source for data self-heal. For example if
      there are 2 source bricks B2 and B3 (B3 being arbiter brick) and
      B2 is down, then data-self-heal will not happen from B3 to sink
      brick B1, and will be pending until B2 comes up and heal can
      happen from it. Note that metadata and entry self-heals can still
      happen from B3 if it is one of the sources. <br>
    </small><br>
    <small>-----------------------------------------------------------------------------<br>
      <br>
      Please provide feedback if you have tried it out.<br>
      <b>If you ever encounter a split-brain while using the arbiter
        volume, it is a BUG - do report!</b><br>
      We have had users asking for a way to convert existing replica 2
      volumes to arbiter volumes- this is definitely in our to-do list,
      in addition to some performance optimizations.<br>
      <br>
      Thanks,<br>
      Ravi<br>
    </small>
  </div>

<br>_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-users</a><br></blockquote></div><br></div>