<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="binlog-replication-configuration-overview">
      </a>
      19.1.1 Binary Log File Position Based Replication Configuration Overview
     </h3>
    </div>
   </div>
  </div>
  <p>
   This section describes replication between MySQL servers based on
      the binary log file position method, where the MySQL instance
      operating as the source (where the database changes take place)
      writes updates and changes as
   <span class="quote">
    “
    <span class="quote">
     events
    </span>
    ”
   </span>
   to the binary
      log. The information in the binary log is stored in different
      logging formats according to the database changes being recorded.
      Replicas are configured to read the binary log from the source and
      to execute the events in the binary log on the replica's local
      database.
  </p>
  <p>
   Each replica receives a copy of the entire contents of the binary
      log. It is the responsibility of the replica to decide which
      statements in the binary log should be executed. Unless you
      specify otherwise, all events in the source's binary log are
      executed on the replica. If required, you can configure the
      replica to process only events that apply to particular databases
      or tables.
  </p>
  <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Important
   </div>
   <p>
    You cannot configure the source to log only certain events.
   </p>
  </div>
  <p>
   Each replica keeps a record of the binary log coordinates: the
      file name and position within the file that it has read and
      processed from the source. This means that multiple replicas can
      be connected to the source and executing different parts of the
      same binary log. Because the replicas control this process,
      individual replicas can be connected and disconnected from the
      server without affecting the source's operation. Also, because
      each replica records the current position within the binary log,
      it is possible for replicas to be disconnected, reconnect and then
      resume processing.
  </p>
  <p>
   The source and each replica must be configured with a unique ID
      (using the
   <a class="link" href="replication-options.html#sysvar_server_id">
    <code class="literal">
     server_id
    </code>
   </a>
   system
      variable). In addition, each replica must be configured with
      information about the source's host name, log file name, and
      position within that file. These details can be controlled from
      within a MySQL session using a
   <a class="link" href="change-replication-source-to.html" title="15.4.2.2 CHANGE REPLICATION SOURCE TO Statement">
    <code class="literal">
     CHANGE
      REPLICATION SOURCE TO
    </code>
   </a>
   statement on the replica. The
      details are stored within the replica's connection metadata
      repository (see
   <a class="xref" href="replica-logs.html" title="19.2.4 Relay Log and Replication Metadata Repositories">
    Section 19.2.4, “Relay Log and Replication Metadata Repositories”
   </a>
   ).
  </p>
 </div>
 <br/>
</div>
