<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="replication-delayed">
      </a>
      19.4.11 Delayed Replication
     </h3>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045136114512">
  </a>
  <a class="indexterm" name="idm46045136113440">
  </a>
  <a class="indexterm" name="idm46045136111952">
  </a>
  <a class="indexterm" name="idm46045136110864">
  </a>
  <p>
   MySQL supports delayed replication such that a replica server
      deliberately executes transactions later than the source by at
      least a specified amount of time. This section describes how to
      configure a replication delay on a replica, and how to monitor
      replication delay.
  </p>
  <p>
   In MySQL 8.4, the method of delaying replication
      depends on two timestamps,
   <code class="literal">
    immediate_commit_timestamp
   </code>
   and
   <code class="literal">
    original_commit_timestamp
   </code>
   (see
   <a class="xref" href="replication-delayed.html#replication-delayed-timestamps" title="Replication Delay Timestamps">
    Replication Delay Timestamps
   </a>
   ); delayed
      replication is measured using these timestamps. If either the
      immediate source or replica is not using these timestamps, the
      implementation of delayed replication from MySQL 5.7 is used (see
   <a class="ulink" href="/doc/refman/5.7/en/replication-delayed.html" target="_top">
    Delayed Replication
   </a>
   ). This section
      describes delayed replication between servers which are all using
      these timestamps.
  </p>
  <p>
   The default replication delay is 0 seconds. Use 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
      SOURCE_DELAY=
     <em class="replaceable">
      <code>
       N
      </code>
     </em>
    </code>
   </a>
   statement to
      set the delay to
   <em class="replaceable">
    <code>
     N
    </code>
   </em>
   seconds. A
      transaction received from the source is not executed until at
      least
   <em class="replaceable">
    <code>
     N
    </code>
   </em>
   seconds later than its commit
      on the immediate source. The delay happens per transaction (not
      event as in previous MySQL versions) and the actual delay is
      imposed only on
   <code class="literal">
    gtid_log_event
   </code>
   or
   <code class="literal">
    anonymous_gtid_log_event
   </code>
   . The other events in
      the transaction always follow these events without any waiting
      time imposed on them.
  </p>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    <a class="link" href="start-replica.html" title="15.4.2.4 START REPLICA Statement">
     <code class="literal">
      START REPLICA
     </code>
    </a>
    and
    <a class="link" href="stop-replica.html" title="15.4.2.5 STOP REPLICA Statement">
     <code class="literal">
      STOP REPLICA
     </code>
    </a>
    take effect
        immediately and ignore any delay.
    <a class="link" href="reset-replica.html" title="15.4.2.3 RESET REPLICA Statement">
     <code class="literal">
      RESET
        REPLICA
     </code>
    </a>
    resets the delay to 0.
   </p>
  </div>
  <p>
   The
   <a class="link" href="performance-schema-replication-applier-configuration-table.html" title="29.12.11.2 The replication_applier_configuration Table">
    <code class="literal">
     replication_applier_configuration
    </code>
   </a>
   Performance Schema table contains the
   <code class="literal">
    DESIRED_DELAY
   </code>
   column which shows the delay
      configured using the
   <code class="literal">
    SOURCE_DELAY
   </code>
   option. The
   <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>
   Performance Schema table contains the
   <code class="literal">
    REMAINING_DELAY
   </code>
   column which shows the number
      of delay seconds remaining.
  </p>
  <p>
   Delayed replication can be used for several purposes:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      To protect against user mistakes on the source. With a delay
          you can roll back a delayed replica to the time just before
          the mistake.
     </p>
    </li>
    <li class="listitem">
     <p>
      To test how the system behaves when there is a lag. For
          example, in an application, a lag might be caused by a heavy
          load on the replica. However, it can be difficult to generate
          this load level. Delayed replication can simulate the lag
          without having to simulate the load. It can also be used to
          debug conditions related to a lagging replica.
     </p>
    </li>
    <li class="listitem">
     <p>
      To inspect what the database looked like in the past, without
          having to reload a backup. For example, by configuring a
          replica with a delay of one week, if you then need to see what
          the database looked like before the last few days' worth of
          development, the delayed replica can be inspected.
     </p>
    </li>
   </ul>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="replication-delayed-timestamps">
       </a>
       Replication Delay Timestamps
      </h4>
     </div>
    </div>
   </div>
   <p>
    MySQL 8.4 provides a new method for measuring delay
        (also referred to as replication lag) in replication topologies
        that depends on the following timestamps associated with the
        GTID of each transaction (instead of each event) written to the
        binary log.
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       <code class="literal">
        original_commit_timestamp
       </code>
       : the number of
            microseconds since epoch when the transaction was written
            (committed) to the binary log of the original source.
      </p>
     </li>
     <li class="listitem">
      <p>
       <code class="literal">
        immediate_commit_timestamp
       </code>
       : the number of
            microseconds since epoch when the transaction was written
            (committed) to the binary log of the immediate source.
      </p>
     </li>
    </ul>
   </div>
   <p>
    The output of
    <a class="link" href="mysqlbinlog.html" title="6.6.9 mysqlbinlog — Utility for Processing Binary Log Files">
     <span class="command">
      <strong>
       mysqlbinlog
      </strong>
     </span>
    </a>
    displays these
        timestamps in two formats, microseconds from epoch and also
    <code class="literal">
     TIMESTAMP
    </code>
    format, which is based on the user
        defined time zone for better readability. For example:
   </p>
   <div class="copytoclipboard-wrapper">
    <pre class="programlisting language-none"><div class="docs-select-all right" id="sa23259625"><div class="copy-help left">Press ⌘+C to copy</div> <div class="right"><button class="clipboard-btn" title="Copy to Clipboard"><span class="icon-clipboard"></span></button></div></div><code class="language-none">#170404 10:48:05 server id 1  end_log_pos 233 CRC32 0x016ce647     GTID    last_committed=0
\ sequence_number=1    original_committed_timestamp=1491299285661130    immediate_commit_timestamp=1491299285843771
# original_commit_timestamp=1491299285661130 (2017-04-04 10:48:05.661130 WEST)
# immediate_commit_timestamp=1491299285843771 (2017-04-04 10:48:05.843771 WEST)
 /*!80001 SET @@SESSION.original_commit_timestamp=1491299285661130*//*!*/;
   SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'/*!*/;
# at 233</code></pre>
   </div>
   <p>
    As a rule, the
    <code class="literal">
     original_commit_timestamp
    </code>
    is
        always the same on all replicas where the transaction is
        applied. In source-replica replication, the
    <code class="literal">
     original_commit_timestamp
    </code>
    of a transaction in
        the (original) source’s binary log is always the same as its
    <code class="literal">
     immediate_commit_timestamp
    </code>
    . In the
        replica’s relay log, the
    <code class="literal">
     original_commit_timestamp
    </code>
    and
    <code class="literal">
     immediate_commit_timestamp
    </code>
    of the transaction
        are the same as in the source’s binary log; whereas in its own
        binary log, the transaction’s
    <code class="literal">
     immediate_commit_timestamp
    </code>
    corresponds to
        when the replica committed the transaction.
   </p>
   <p>
    In a Group Replication setup, when the original source is a
        member of a group, the
    <code class="literal">
     original_commit_timestamp
    </code>
    is generated when
        the transaction is ready to be committed. In other words, when
        it finished executing on the original source and its write set
        is ready to be sent to all members of the group for
        certification. When the original source is a server outside the
        group, the
    <code class="literal">
     original_commit_timestamp
    </code>
    is
        preserved. The same
    <code class="literal">
     original_commit_timestamp
    </code>
    for a particular transaction is replicated to all servers in the
        group, and to any replica outside the group that is replicating
        from a member. Each recipient of the transaction also stores the
        local commit time in its binary log using
    <code class="literal">
     immediate_commit_timestamp
    </code>
    .
   </p>
   <p>
    View change events, which are exclusive to Group Replication,
        are a special case. Transactions containing these events are
        generated by each group member but share the same GTID (so, they
        are not first executed in a source and then replicated to the
        group, but all members of the group execute and apply the same
        transaction). Group members set local timestamp values for
        transactions associated with view change events.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="replication-delayed-monitoring">
       </a>
       Monitoring Replication Delay
      </h4>
     </div>
    </div>
   </div>
   <p>
    One of the most common ways to monitor replication delay (lag)
        in previous MySQL versions was by relying on the
    <code class="literal">
     Seconds_Behind_Master
    </code>
    field in the output of
    <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>
    . However,
        this metric is not suitable when using replication topologies
        more complex than the traditional source-replica setup, such as
        Group Replication. The addition of
    <code class="literal">
     immediate_commit_timestamp
    </code>
    and
    <code class="literal">
     original_commit_timestamp
    </code>
    to MySQL 8 provides
        a much finer degree of information about replication delay. The
        recommended method to monitor replication delay in a topology
        that supports these timestamps is using the following
        Performance Schema tables.
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       <a class="link" href="performance-schema-replication-connection-status-table.html" title="29.12.11.13 The replication_connection_status Table">
        <code class="literal">
         replication_connection_status
        </code>
       </a>
       :
            current status of the connection to the source, provides
            information on the last and current transaction the
            connection thread queued into the relay log.
      </p>
     </li>
     <li class="listitem">
      <p>
       <a class="link" href="performance-schema-replication-applier-status-by-coordinator-table.html" title="29.12.11.6 The replication_applier_status_by_coordinator Table">
        <code class="literal">
         replication_applier_status_by_coordinator
        </code>
       </a>
       :
            current status of the coordinator thread that only displays
            information when using a multithreaded replica, provides
            information on the last transaction buffered by the
            coordinator thread to a worker’s queue, as well as the
            transaction it is currently buffering.
      </p>
     </li>
     <li class="listitem">
      <p>
       <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>
       :
            current status of the thread(s) applying transactions
            received from the source, provides information about the
            transactions applied by the replication SQL thread, or by
            each worker thread when using a multithreaded replica.
      </p>
     </li>
    </ul>
   </div>
   <p>
    Using these tables you can monitor information about the last
        transaction the corresponding thread processed and the
        transaction that thread is currently processing. This
        information comprises:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       a transaction’s GTID
      </p>
     </li>
     <li class="listitem">
      <p>
       a transaction's
       <code class="literal">
        original_commit_timestamp
       </code>
       and
       <code class="literal">
        immediate_commit_timestamp
       </code>
       , retrieved
            from the replica’s relay log
      </p>
     </li>
     <li class="listitem">
      <p>
       the time a thread started processing a transaction
      </p>
     </li>
     <li class="listitem">
      <p>
       for the last processed transaction, the time the thread
            finished processing it
      </p>
     </li>
    </ul>
   </div>
   <p>
    In addition to the Performance Schema tables, the output of
    <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>
    has three
        fields that show:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       <code class="literal">
        SQL_Delay
       </code>
       : A nonnegative integer
            indicating the replication delay configured using
       <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
            SOURCE_DELAY=
         <em class="replaceable">
          <code>
           N
          </code>
         </em>
        </code>
       </a>
       , where
       <em class="replaceable">
        <code>
         N
        </code>
       </em>
       is measured in seconds.
      </p>
     </li>
     <li class="listitem">
      <p>
       <code class="literal">
        SQL_Remaining_Delay
       </code>
       : When
       <code class="literal">
        Replica_SQL_Running_State
       </code>
       is
       <code class="literal">
        Waiting until SOURCE_DELAY seconds after master
            executed event
       </code>
       , this field contains an integer
            indicating the number of seconds left of the delay. At other
            times, this field is
       <code class="literal">
        NULL
       </code>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <code class="literal">
        Replica_SQL_Running_State
       </code>
       : A string
            indicating the state of the SQL thread (analogous to
       <code class="literal">
        Replica_IO_State
       </code>
       ). The value is identical
            to the
       <code class="literal">
        State
       </code>
       value of the SQL thread as
            displayed by
       <a class="link" href="show-processlist.html" title="15.7.7.31 SHOW PROCESSLIST Statement">
        <code class="literal">
         SHOW
            PROCESSLIST
        </code>
       </a>
       .
      </p>
     </li>
    </ul>
   </div>
   <p>
    When the replication SQL thread is waiting for the delay to
        elapse before executing an event,
    <a class="link" href="show-processlist.html" title="15.7.7.31 SHOW PROCESSLIST Statement">
     <code class="literal">
      SHOW
        PROCESSLIST
     </code>
    </a>
    displays its
    <code class="literal">
     State
    </code>
    value as
    <code class="literal">
     Waiting until SOURCE_DELAY seconds after
        master executed event
    </code>
    .
   </p>
  </div>
 </div>
 <br/>
</div>
