<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-throttling">
      </a>
      20.7.2.2 Group Replication Throttling
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045132194528">
  </a>
  <p>
   Based on the metrics gathered across all servers in the group, a
        throttling mechanism kicks in and decides whether to limit the
        rate a member is able to execute/commit new transactions.
  </p>
  <p>
   Therefore, metrics acquired from all members are the basis for
        calculating the capacity of each member: if a member has a large
        queue (for certification or the applier thread), then the
        capacity to execute new transactions should be close to ones
        certified or applied in the last period.
  </p>
  <p>
   The lowest capacity of all the members in the group determines
        the real capacity of the group, while the number of local
        transactions determines how many members are writing to it, and,
        consequently, how many members should that available capacity be
        shared with.
  </p>
  <p>
   This means that every member has an established write quota
        based on the available capacity, in other words a number of
        transactions it can safely issue for the next period. The
        writer-quota is enforced by the throttling mechanism if the
        queue size of the certifier or the binary log applier exceeds a
        user-defined threshold.
  </p>
  <p>
   The quota is reduced by the number of transactions that were
        delayed in the last period, and then also further reduced by 10%
        to allow the queue that triggered the problem to reduce its
        size. In order to avoid large jumps in throughput once the queue
        size goes beyond the threshold, the throughput is only allowed
        to grow by the same 10% per period after that.
  </p>
  <p>
   The current throttling mechanism does not penalize transactions
        below quota, but delays finishing those transactions that exceed
        it until the end of the monitoring period. As a consequence, if
        the quota is very small for the write requests issued some
        transactions may have latencies close to the monitoring period.
  </p>
 </div>
 <br/>
</div>
