<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="replica-logs">
      </a>
      19.2.4 Relay Log and Replication Metadata Repositories
     </h3>
    </div>
   </div>
  </div>
  <div class="toc">
   <dl class="toc">
    <dt>
     <span class="section">
      <a href="replica-logs-relaylog.html">
       19.2.4.1 The Relay Log
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="replica-logs-status.html">
       19.2.4.2 Replication Metadata Repositories
      </a>
     </span>
    </dt>
   </dl>
  </div>
  <a class="indexterm" name="idm46045137975408">
  </a>
  <a class="indexterm" name="idm46045137973952">
  </a>
  <a class="indexterm" name="idm46045137972448">
  </a>
  <a class="indexterm" name="idm46045137971376">
  </a>
  <a class="indexterm" name="idm46045137970288">
  </a>
  <a class="indexterm" name="idm46045137969200">
  </a>
  <a class="indexterm" name="idm46045137968112">
  </a>
  <p>
   A replica server creates several repositories of information to
      use for the replication process:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      The replica's
      <span class="emphasis">
       <em>
        relay log
       </em>
      </span>
      , which is written
          by the replication I/O (receiver) thread, contains the
          transactions read from the replication source server's binary
          log. The transactions in the relay log are applied on the
          replica by the replication SQL (applier) thread. For
          information about the relay log, see
      <a class="xref" href="replica-logs-relaylog.html" title="19.2.4.1 The Relay Log">
       Section 19.2.4.1, “The Relay Log”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      The replica's
      <span class="emphasis">
       <em>
        connection metadata
          repository
       </em>
      </span>
      contains information that the
          replication receiver thread needs to connect to the
          replication source server and retrieve transactions from the
          source's binary log. The connection metadata repository is
          written to the
      <code class="literal">
       mysql.slave_master_info
      </code>
      table.
     </p>
    </li>
    <li class="listitem">
     <p>
      The replica's
      <span class="emphasis">
       <em>
        applier metadata repository
       </em>
      </span>
      contains information that the replication applier thread needs
          to read and apply transactions from the replica's relay log.
          The applier metadata repository is written to the
      <code class="literal">
       mysql.slave_relay_log_info
      </code>
      table.
     </p>
    </li>
   </ul>
  </div>
  <p>
   The replica's connection metadata repository and applier metadata
      repository are collectively known as the replication metadata
      repositories. For information about these, see
   <a class="xref" href="replica-logs-status.html" title="19.2.4.2 Replication Metadata Repositories">
    Section 19.2.4.2, “Replication Metadata Repositories”
   </a>
   .
  </p>
  <p>
   <a name="replication-implementation-crash-safe">
   </a>
   <b>
    Making replication resilient to unexpected halts.
   </b>
   The
   <code class="literal">
    mysql.slave_master_info
   </code>
   and
   <code class="literal">
    mysql.slave_relay_log_info
   </code>
   tables are created
        using the transactional storage engine
   <a class="link" href="innodb-storage-engine.html" title="Chapter 17 The InnoDB Storage Engine">
    <code class="literal">
     InnoDB
    </code>
   </a>
   . Updates to the replica's
        applier metadata repository table are committed together with
        the transactions, meaning that the replica's progress
        information recorded in that repository is always consistent
        with what has been applied to the database, even in the event of
        an unexpected server halt. For information on the combination of
        settings on the replica that is most resilient to unexpected
        halts, see
   <a class="xref" href="replication-solutions-unexpected-replica-halt.html" title="19.4.2 Handling an Unexpected Halt of a Replica">
    Section 19.4.2, “Handling an Unexpected Halt of a Replica”
   </a>
   .
  </p>
 </div>
 <br/>
</div>
