<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="replication-features-timeout">
      </a>
      19.5.1.32 Replication Retries and Timeouts
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045135079808">
  </a>
  <a class="indexterm" name="idm46045135078320">
  </a>
  <a class="indexterm" name="idm46045135076832">
  </a>
  <a class="indexterm" name="idm46045135075760">
  </a>
  <p>
   The global value of the system variable
   <a class="link" href="replication-options-replica.html#sysvar_replica_transaction_retries">
    <code class="literal">
     replica_transaction_retries
    </code>
   </a>
   sets the maximum number of times for applier threads on a
        single-threaded or multithreaded replica to automatically retry
        failed transactions before stopping. Transactions are
        automatically retried when the SQL thread fails to execute them
        because of an
   <code class="literal">
    InnoDB
   </code>
   deadlock, or when the
        transaction's execution time exceeds the
   <code class="literal">
    InnoDB
   </code>
   <a class="link" href="innodb-parameters.html#sysvar_innodb_lock_wait_timeout">
    <code class="literal">
     innodb_lock_wait_timeout
    </code>
   </a>
   value.
        If a transaction has a non-temporary error that prevents it from
        succeeding, it is not retried.
  </p>
  <p>
   The default setting for
   <a class="link" href="replication-options-replica.html#sysvar_replica_transaction_retries">
    <code class="literal">
     replica_transaction_retries
    </code>
   </a>
   is
        10, meaning that a failing transaction with an apparently
        temporary error is retried 10 times before the applier thread
        stops. Setting the variable to 0 disables automatic retrying of
        transactions. On a multithreaded replica, the specified number
        of transaction retries can take place on all applier threads of
        all channels. The Performance Schema table
   <a class="link" href="performance-schema-replication-applier-status-table.html" title="29.12.11.5 The replication_applier_status Table">
    <code class="literal">
     replication_applier_status
    </code>
   </a>
   shows
        the total number of transaction retries that took place on each
        replication channel, in the
   <code class="literal">
    COUNT_TRANSACTIONS_RETRIES
   </code>
   column.
  </p>
  <p>
   The process of retrying transactions can cause lag on a replica
        or on a Group Replication group member, which can be configured
        as a single-threaded or multithreaded replica. The Performance
        Schema table
   <a class="link" href="performance-schema-replication-applier-status-by-worker-table.html" title="29.12.11.7 The replication_applier_status_by_worker Table">
    <code class="literal">
     replication_applier_status_by_worker
    </code>
   </a>
   shows detailed information on transaction retries by the applier
        threads on a single-threaded or multithreaded replica. This data
        includes timestamps showing how long it took the applier thread
        to apply the last transaction from start to finish (and when the
        transaction currently in progress was started), and how long
        this was after the commit on the original source and the
        immediate source. The data also shows the number of retries for
        the last transaction and the transaction currently in progress,
        and enables you to identify the transient errors that caused the
        transactions to be retried. You can use this information to see
        whether transaction retries are the cause of replication lag,
        and investigate the root cause of the failures that led to the
        retries.
  </p>
 </div>
 <br/>
</div>
