<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="group-replication-flow-control">
      </a>
      20.7.2 Flow Control
     </h3>
    </div>
   </div>
  </div>
  <div class="toc">
   <dl class="toc">
    <dt>
     <span class="section">
      <a href="group-replication-probes-and-statistics.html">
       20.7.2.1 Probes and Statistics
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="group-replication-throttling.html">
       20.7.2.2 Group Replication Throttling
      </a>
     </span>
    </dt>
   </dl>
  </div>
  <a class="indexterm" name="idm46045132221040">
  </a>
  <p>
   Group Replication ensures that a transaction only commits after a
      majority of the members in a group have received it and agreed on
      the relative order between all transactions that were sent
      concurrently. This approach works well if the total number of
      writes to the group does not exceed the write capacity of any
      member in the group. If it does and some of the members have less
      write throughput than others, particularly less than the writer
      members, those members can start lagging behind of the writers.
  </p>
  <p>
   Having some members lagging behind the group brings some
      problematic consequences, particularly, the reads on such members
      may externalize very old data. Depending on why the member is
      lagging behind, other members in the group may have to save more
      or less replication context to be able to fulfil potential data
      transfer requests from the slow member.
  </p>
  <p>
   There is however a mechanism in the replication protocol to avoid
      having too much distance, in terms of transactions applied,
      between fast and slow members. This is known as the flow control
      mechanism. It tries to address several goals:
  </p>
  <div class="orderedlist">
   <ol class="orderedlist" type="1">
    <li class="listitem">
     <p>
      to keep the members close enough to make buffering and
          de-synchronization between members a small problem;
     </p>
    </li>
    <li class="listitem">
     <p>
      to adapt quickly to changing conditions like different
          workloads or more writers in the group;
     </p>
    </li>
    <li class="listitem">
     <p>
      to give each member a fair share of the available write
          capacity;
     </p>
    </li>
    <li class="listitem">
     <p>
      to not reduce throughput more than strictly necessary to avoid
          wasting resources.
     </p>
    </li>
   </ol>
  </div>
  <p>
   Given the design of Group Replication, the decision whether to
      throttle or not may be decided taking into account two work
      queues:
   <span class="emphasis">
    <em>
     (i)
    </em>
   </span>
   the
   <span class="emphasis">
    <em>
     certification
    </em>
   </span>
   queue;
   <span class="emphasis">
    <em>
     (ii)
    </em>
   </span>
   and on the binary log
   <span class="emphasis">
    <em>
     applier
    </em>
   </span>
   queue. Whenever the size of one of
      these queues exceeds the user-defined threshold, the throttling
      mechanism is triggered. Only configure:
   <span class="emphasis">
    <em>
     (i)
    </em>
   </span>
   whether to do flow control at the certifier or at the applier
      level, or both; and
   <span class="emphasis">
    <em>
     (ii)
    </em>
   </span>
   what is the
      threshold for each queue.
  </p>
  <p>
   The flow control depends on two basic mechanisms:
  </p>
  <div class="orderedlist">
   <ol class="orderedlist" type="1">
    <li class="listitem">
     <p>
      the monitoring of members to collect some statistics on
          throughput and queue sizes of all group members to make
          educated guesses on what is the maximum write pressure each
          member should be subjected to;
     </p>
    </li>
    <li class="listitem">
     <p>
      the throttling of members that are trying to write beyond
          their fair-share of the available capacity at each moment in
          time.
     </p>
    </li>
   </ol>
  </div>
 </div>
 <br/>
</div>
