<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="replication-features-errors">
      </a>
      19.5.1.29 Replica Errors During Replication
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045135163632">
  </a>
  <a class="indexterm" name="idm46045135162144">
  </a>
  <a class="indexterm" name="idm46045135160656">
  </a>
  <a class="indexterm" name="idm46045135159168">
  </a>
  <p>
   If a statement produces the same error (identical error code) on
        both the source and the replica, the error is logged, but
        replication continues.
  </p>
  <p>
   If a statement produces different errors on the source and the
        replica, the replication SQL thread terminates, and the replica
        writes a message to its error log and waits for the database
        administrator to decide what to do about the error. This
        includes the case that a statement produces an error on the
        source or the replica, but not both. To address the issue,
        connect to the replica manually and determine the cause of the
        problem.
   <a class="link" href="show-replica-status.html" title="15.7.7.35 SHOW REPLICA STATUS Statement">
    <code class="literal">
     SHOW REPLICA STATUS
    </code>
   </a>
   is
        useful for this. Then fix the problem and run
   <a class="link" href="start-replica.html" title="15.4.2.4 START REPLICA Statement">
    <code class="literal">
     START REPLICA
    </code>
   </a>
   . For example, you
        might need to create a nonexistent table before you can start
        the replica again.
  </p>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    If a temporary error is recorded in the replica's error log,
            you do not necessarily have to take any action suggested in
            the quoted error message. Temporary errors should be handled
            by the client retrying the transaction. For example, if the
            replication SQL thread records a temporary error relating to
            a deadlock, you do not need to restart the transaction
            manually on the replica, unless the replication SQL thread
            subsequently terminates with a nontemporary error message.
   </p>
  </div>
  <p>
  </p>
  <p>
   If this error code validation behavior is not desirable, some or
        all errors can be masked out (ignored) with the
   <a class="link" href="replication-options-replica.html#sysvar_replica_skip_errors">
    <code class="option">
     --replica-skip-errors
    </code>
   </a>
   option.
  </p>
  <p>
   For nontransactional storage engines such as
   <a class="link" href="myisam-storage-engine.html" title="18.2 The MyISAM Storage Engine">
    <code class="literal">
     MyISAM
    </code>
   </a>
   , it is possible to have a
        statement that only partially updates a table and returns an
        error code. This can happen, for example, on a multiple-row
        insert that has one row violating a key constraint, or if a long
        update statement is killed after updating some of the rows. If
        that happens on the source, the replica expects execution of the
        statement to result in the same error code. If it does not, the
        replication SQL thread stops as described previously.
  </p>
  <p>
   If you are replicating between tables that use different storage
        engines on the source and replica, keep in mind that the same
        statement might produce a different error when run against one
        version of the table, but not the other, or might cause an error
        for one version of the table, but not the other. For example,
        since
   <code class="literal">
    MyISAM
   </code>
   ignores foreign key constraints,
        an
   <a class="link" href="insert.html" title="15.2.7 INSERT Statement">
    <code class="literal">
     INSERT
    </code>
   </a>
   or
   <a class="link" href="update.html" title="15.2.17 UPDATE Statement">
    <code class="literal">
     UPDATE
    </code>
   </a>
   statement accessing an
   <code class="literal">
    InnoDB
   </code>
   table on the source might cause a
        foreign key violation but the same statement performed on a
   <code class="literal">
    MyISAM
   </code>
   version of the same table on the
        replica would produce no such error, causing replication to
        stop.
  </p>
  <p>
   Replication filter rules are applied first, prior to making any
        privilege or row format checks, making it possible to filter out
        any transactions that fail validation; no checks are performed
        and thus no errors are raised for transactions which have been
        filtered out. This means that the replica can accept only that
        part of the database to which a given user has been granted
        access (as long as any updates to this part of the database use
        the row-based replication format). This may be helpful when
        performing an upgrade or when migrating to a system or
        application that uses administration tables to which the inbound
        replication user does not have access. See also
   <a class="xref" href="replication-rules.html" title="19.2.5 How Servers Evaluate Replication Filtering Rules">
    Section 19.2.5, “How Servers Evaluate Replication Filtering Rules”
   </a>
   .
  </p>
 </div>
 <br/>
</div>
