<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="group-replication-distributed-recovery">
      </a>
      20.5.4 Distributed Recovery
     </h3>
    </div>
   </div>
  </div>
  <div class="toc">
   <dl class="toc">
    <dt>
     <span class="section">
      <a href="group-replication-distributed-recovery-connections.html">
       20.5.4.1 Connections for Distributed Recovery
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="group-replication-cloning.html">
       20.5.4.2 Cloning for Distributed Recovery
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="group-replication-tuning-recovery.html">
       20.5.4.3 Configuring Distributed Recovery
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="group-replication-distributed-recovery-fault.html">
       20.5.4.4 Fault Tolerance for Distributed Recovery
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="group-replication-view-changes.html">
       20.5.4.5 How Distributed Recovery Works
      </a>
     </span>
    </dt>
   </dl>
  </div>
  <a class="indexterm" name="idm46045133180272">
  </a>
  <p>
   Whenever a member joins or rejoins a replication group, it must
      catch up with the transactions that were applied by the group
      members before it joined, or while it was away. This process is
      called distributed recovery.
  </p>
  <p>
   The joining member begins by checking the relay log for its
   <code class="literal">
    group_replication_applier
   </code>
   channel for any
      transactions that it already received from the group but did not
      yet apply. If the joining member was in the group previously, it
      might find unapplied transactions from before it left, in which
      case it applies these as a first step. A member that is new to the
      group does not have anything to apply.
  </p>
  <p>
   After this, the joining member connects to an online existing
      member to carry out state transfer. The joining member transfers
      all the transactions that took place in the group before it joined
      or while it was away, which are provided by the existing member
      (called the
   <span class="emphasis">
    <em>
     donor
    </em>
   </span>
   ). Next, the joining member
      applies the transactions that took place in the group while this
      state transfer was in progress. When this process is complete, the
      joining member has caught up with the remaining servers in the
      group, and it begins to participate normally in the group.
  </p>
  <p>
   Group Replication uses a combination of these methods for state
      transfer during distributed recovery:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      A remote cloning operation using the clone plugin's
            function. To enable this method of state transfer, you must
            install the clone plugin on the group members and the
            joining member. Group Replication automatically configures
            the required clone plugin settings and manages the remote
            cloning operation.
     </p>
    </li>
    <li class="listitem">
     <p>
      Replicating from a donor's binary log and applying the
            transactions on the joining member. This method uses a
            standard asynchronous replication channel named
      <code class="literal">
       group_replication_recovery
      </code>
      that is
            established between the donor and the joining member.
     </p>
    </li>
   </ul>
  </div>
  <p>
  </p>
  <p>
   Group Replication automatically selects the best combination of
      these methods for state transfer after you issue
   <a class="link" href="start-group-replication.html" title="15.4.3.1 START GROUP_REPLICATION Statement">
    <code class="literal">
     START GROUP_REPLICATION
    </code>
   </a>
   on the
      joining member. To do this, Group Replication checks which
      existing members are suitable as donors, how many transactions the
      joining member needs from a donor, and whether any required
      transactions are no longer present in the binary log files on any
      group member. If the transaction gap between the joining member
      and a suitable donor is large, or if some required transactions
      are not in any donor's binary log files, Group Replication begins
      distributed recovery with a remote cloning operation. If there is
      not a large transaction gap, or if the clone plugin is not
      installed, Group Replication proceeds directly to state transfer
      from a donor's binary log.
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      During a remote cloning operation, the existing data on the
          joining member is removed, and replaced with a copy of the
          donor's data. When the remote cloning operation is complete
          and the joining member has restarted, state transfer from a
          donor's binary log is carried out to get the transactions that
          the group applied while the remote cloning operation was in
          progress.
     </p>
    </li>
    <li class="listitem">
     <p>
      During state transfer from a donor's binary log, the joining
          member replicates and applies the required transactions from
          the donor's binary log, applying the transactions as they are
          received, up to the point where the binary log records that
          the joining member joined the group (a view change event).
          While this is in progress, the joining member buffers the new
          transactions that the group applies. When state transfer from
          the binary log is complete, the joining member applies the
          buffered transactions.
     </p>
    </li>
   </ul>
  </div>
  <p>
   When the joining member is up to date with all the group's
      transactions, it is declared online and can participate in the
      group as a normal member, and distributed recovery is complete.
  </p>
  <div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Tip
   </div>
   <p>
    State transfer from the binary log is Group Replication's base
        mechanism for distributed recovery, and if the donors and
        joining members in your replication group are not set up to
        support cloning, this is the only available option. As state
        transfer from the binary log is based on classic asynchronous
        replication, it might take a very long time if the server
        joining the group does not have the group's data at all, or has
        data taken from a very old backup image. In this situation, it
        is therefore recommended that before adding a server to the
        group, you should set it up with the group's data by
        transferring a fairly recent snapshot of a server already in the
        group. This minimizes the time taken for distributed recovery,
        and reduces the impact on donor servers, since they have to
        retain and transfer fewer binary log files.
   </p>
  </div>
 </div>
 <br/>
</div>
