<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="replication-semisync">
      </a>
      19.4.10 Semisynchronous Replication
     </h3>
    </div>
   </div>
  </div>
  <div class="toc">
   <dl class="toc">
    <dt>
     <span class="section">
      <a href="replication-semisync-installation.html">
       19.4.10.1 Installing Semisynchronous Replication
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="replication-semisync-interface.html">
       19.4.10.2 Configuring Semisynchronous Replication
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="replication-semisync-monitoring.html">
       19.4.10.3 Semisynchronous Replication Monitoring
      </a>
     </span>
    </dt>
   </dl>
  </div>
  <a class="indexterm" name="idm46045136272896">
  </a>
  <a class="indexterm" name="idm46045136271840">
  </a>
  <p>
   In addition to the built-in asynchronous replication, MySQL
      8.4 supports an interface to semisynchronous
      replication that is implemented by plugins. This section discusses
      what semisynchronous replication is and how it works. The
      following sections cover the administrative interface to
      semisynchronous replication and how to install, configure, and
      monitor it.
  </p>
  <p>
   MySQL replication by default is asynchronous. The source writes
      events to its binary log and replicas request them when they are
      ready. The source does not know whether or when a replica has
      retrieved and processed the transactions, and there is no
      guarantee that any event ever reaches any replica. With
      asynchronous replication, if the source crashes, transactions that
      it has committed might not have been transmitted to any replica.
      Failover from source to replica in this case might result in
      failover to a server that is missing transactions relative to the
      source.
  </p>
  <p>
   With fully synchronous replication, when a source commits a
      transaction, all replicas have also committed the transaction
      before the source returns to the session that performed the
      transaction. Fully synchronous replication means failover from the
      source to any replica is possible at any time. The drawback of
      fully synchronous replication is that there might be a lot of
      delay to complete a transaction.
  </p>
  <p>
   Semisynchronous replication falls between asynchronous and fully
      synchronous replication. The source waits until at least one
      replica has received and logged the events (the required number of
      replicas is configurable), and then commits the transaction. The
      source does not wait for all replicas to acknowledge receipt, and
      it requires only an acknowledgement from the replicas, not that
      the events have been fully executed and committed on the replica
      side. Semisynchronous replication therefore guarantees that if the
      source crashes, all the transactions that it has committed have
      been transmitted to at least one replica.
  </p>
  <p>
   Compared to asynchronous replication, semisynchronous replication
      provides improved data integrity, because when a commit returns
      successfully, it is known that the data exists in at least two
      places. Until a semisynchronous source receives acknowledgment
      from the required number of replicas, the transaction is on hold
      and not committed.
  </p>
  <p>
   Compared to fully synchronous replication, semisynchronous
      replication is faster, because it can be configured to balance
      your requirements for data integrity (the number of replicas
      acknowledging receipt of the transaction) with the speed of
      commits, which are slower due to the need to wait for replicas.
  </p>
  <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Important
   </div>
   <p>
    With semisynchronous replication, if the source crashes and a
        failover to a replica is carried out, the failed source should
        not be reused as the replication source, and should be
        discarded. It could have transactions that were not acknowledged
        by any replica, which were therefore not committed before the
        failover.
   </p>
   <p>
    If your goal is to implement a fault-tolerant replication
        topology where all the servers receive the same transactions in
        the same order, and a server that crashes can rejoin the group
        and be brought up to date automatically, you can use Group
        Replication to achieve this. For information, see
    <a class="xref" href="group-replication.html" title="Chapter 20 Group Replication">
     Chapter 20,
     <i>
      Group Replication
     </i>
    </a>
    .
   </p>
  </div>
  <p>
   The performance impact of semisynchronous replication compared to
      asynchronous replication is the tradeoff for increased data
      integrity. The amount of slowdown is at least the TCP/IP roundtrip
      time to send the commit to the replica and wait for the
      acknowledgment of receipt by the replica. This means that
      semisynchronous replication works best for close servers
      communicating over fast networks, and worst for distant servers
      communicating over slow networks. Semisynchronous replication also
      places a rate limit on busy sessions by constraining the speed at
      which binary log events can be sent from source to replica. When
      one user is too busy, this slows it down, which can be useful in
      some deployment situations.
  </p>
  <p>
   Semisynchronous replication between a source and its replicas
      operates as follows:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      A replica indicates whether it is semisynchronous-capable when
          it connects to the source.
     </p>
    </li>
    <li class="listitem">
     <p>
      If semisynchronous replication is enabled on the source side
          and there is at least one semisynchronous replica, a thread
          that performs a transaction commit on the source blocks and
          waits until at least one semisynchronous replica acknowledges
          that it has received all events for the transaction, or until
          a timeout occurs.
     </p>
    </li>
    <li class="listitem">
     <p>
      The replica acknowledges receipt of a transaction's events
          only after the events have been written to its relay log and
          flushed to disk.
     </p>
    </li>
    <li class="listitem">
     <p>
      If a timeout occurs without any replica having acknowledged
          the transaction, the source reverts to asynchronous
          replication. When at least one semisynchronous replica catches
          up, the source returns to semisynchronous replication.
     </p>
    </li>
    <li class="listitem">
     <p>
      Semisynchronous replication must be enabled on both the source
          and replica sides. If semisynchronous replication is disabled
          on the source, or enabled on the source but on no replicas,
          the source uses asynchronous replication.
     </p>
    </li>
   </ul>
  </div>
  <p>
   While the source is blocking (waiting for acknowledgment from a
      replica), it does not return to the session that performed the
      transaction. When the block ends, the source returns to the
      session, which then can proceed to execute other statements. At
      this point, the transaction has committed on the source side, and
      receipt of its events has been acknowledged by at least one
      replica. The number of replica acknowledgments the source must
      receive per transaction before returning to the session is
      configurable, and defaults to one acknowledgement (see
   <a class="xref" href="replication-semisync-interface.html" title="19.4.10.2 Configuring Semisynchronous Replication">
    Section 19.4.10.2, “Configuring Semisynchronous Replication”
   </a>
   ).
  </p>
  <p>
   Blocking also occurs after rollbacks that are written to the
      binary log, which occurs when a transaction that modifies
      nontransactional tables is rolled back. The rolled-back
      transaction is logged even though it has no effect for
      transactional tables because the modifications to the
      nontransactional tables cannot be rolled back and must be sent to
      replicas.
  </p>
  <p>
   For statements that do not occur in transactional context (that
      is, when no transaction has been started with
   <a class="link" href="commit.html" title="15.3.1 START TRANSACTION, COMMIT, and ROLLBACK Statements">
    <code class="literal">
     START
      TRANSACTION
    </code>
   </a>
   or
   <a class="link" href="set-variable.html" title="15.7.6.1 SET Syntax for Variable Assignment">
    <code class="literal">
     SET autocommit =
      0
    </code>
   </a>
   ), autocommit is enabled and each statement commits
      implicitly. With semisynchronous replication, the source blocks
      for each such statement, just as it does for explicit transaction
      commits.
  </p>
  <p>
   By default, the source waits for replica acknowledgment of the
      transaction receipt after syncing the binary log to disk, but
      before committing the transaction to the storage engine. As an
      alternative, you can configure the source so that the source waits
      for replica acknowledgment after committing the transaction to the
      storage engine, using the
   <a class="link" href="replication-options-source.html#sysvar_rpl_semi_sync_source_wait_point">
    <code class="literal">
     rpl_semi_sync_source_wait_point
    </code>
   </a>
   system variable. This setting affects the replication
      characteristics and the data that clients can see on the source.
      For more information, see
   <a class="xref" href="replication-semisync-interface.html" title="19.4.10.2 Configuring Semisynchronous Replication">
    Section 19.4.10.2, “Configuring Semisynchronous Replication”
   </a>
   .
  </p>
  <p>
   You can improve the performance of semisynchronous replication by
      enabling the system variables
   <a class="link" href="replication-options-replica.html#sysvar_replication_sender_observe_commit_only">
    <code class="literal">
     replication_sender_observe_commit_only
    </code>
   </a>
   ,
      which limits callbacks, and
   <a class="link" href="replication-options-replica.html#sysvar_replication_optimize_for_static_plugin_config">
    <code class="literal">
     replication_optimize_for_static_plugin_config
    </code>
   </a>
   ,
      which adds shared locks and avoids unnecessary lock acquisitions.
      These settings help as the number of replicas increases, because
      contention for locks can slow down performance. Semisynchronous
      replication source servers can also get performance benefits from
      enabling these system variables, because they use the same locking
      mechanisms as the replicas.
  </p>
 </div>
 <br/>
</div>
