<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="replication-gtids-assign-anon">
      </a>
      19.1.3.6 Replication From a Source Without GTIDs to a Replica With GTIDs
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045145873440">
  </a>
  <p>
   You can set up replication channels to assign a GTID to replicated
      transactions that do not already have one. This feature enables
      replication from a source server that does not have GTIDs enabled
      and does not use GTID-based replication, to a replica that has
      GTIDs enabled. If it is possible to enable GTIDs on the
      replication source server, as described in
   <a class="xref" href="replication-mode-change-online.html" title="19.1.4 Changing GTID Mode on Online Servers">
    Section 19.1.4, “Changing GTID Mode on Online Servers”
   </a>
   , use that
      approach instead. This feature is designed for replication source
      servers where you cannot enable GTIDs. Note that as is standard
      for MySQL replication, this feature does not support replication
      from MySQL source servers earlier than the previous release
      series, so MySQL 8.3 is the earliest supported
      source for a MySQL 8.4 replica.
  </p>
  <p>
   You can enable GTID assignment on a replication channel using the
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   option
      of the
   <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.
   <code class="literal">
    LOCAL
   </code>
   assigns a GTID including the
      replica's own UUID (the
   <a class="link" href="replication-options.html#sysvar_server_uuid">
    <code class="literal">
     server_uuid
    </code>
   </a>
   setting).
   <code class="literal">
    <em class="replaceable">
     <code>
      uuid
     </code>
    </em>
   </code>
   assigns a GTID
      including the specified UUID, such as the
   <a class="link" href="replication-options.html#sysvar_server_uuid">
    <code class="literal">
     server_uuid
    </code>
   </a>
   setting for the
      replication source server. Using a nonlocal UUID lets you
      differentiate between transactions that originated on the replica
      and transactions that originated on the source, and for a
      multi-source replica, between transactions that originated on
      different sources. If any of the transactions sent by the source
      do have a GTID already, that GTID is retained.
  </p>
  <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Important
   </div>
   <p>
    A replica set up with
    <code class="literal">
     ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
    </code>
    on any
        channel cannot be promoted to replace the replication source
        server in the event that failover is required, and a backup
        taken from the replica cannot be used to restore the replication
        source server. The same restriction applies to replacing or
        restoring other replicas that use
    <code class="literal">
     ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
    </code>
    on any
        channel.
   </p>
  </div>
  <p>
   The replica must have
   <a class="link" href="replication-options-gtids.html#sysvar_gtid_mode">
    <code class="literal">
     gtid_mode=ON
    </code>
   </a>
   set, and this cannot
      be changed afterwards, unless you set
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS=OFF
   </code>
   . If
      the replica server is started without GTIDs enabled and with
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   set for
      any replication channels, the settings are not changed, but a
      warning message is written to the error log explaining how to
      change the situation.
  </p>
  <p>
   For a multi-source replica, you can have a mix of channels that
      use
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   , and
      channels that do not. Channels specific to Group Replication
      cannot use
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   , but an
      asynchronous replication channel for another source on a server
      instance that is a Group Replication group member can do so. For a
      channel on a Group Replication group member, do not specify the
      Group Replication group name as the UUID for creating the GTIDs.
  </p>
  <p>
   Using
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   on
      a replication channel is not the same as introducing GTID-based
      replication for the channel. The GTID set
      (
   <a class="link" href="replication-options-gtids.html#sysvar_gtid_executed">
    <code class="literal">
     gtid_executed
    </code>
   </a>
   ) from a replica
      set up with
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   should
      not be transferred to another server or compared with another
      server's
   <a class="link" href="replication-options-gtids.html#sysvar_gtid_executed">
    <code class="literal">
     gtid_executed
    </code>
   </a>
   set. The
      GTIDs that are assigned to the anonymous transactions, and the
      UUID you choose for them, only have significance for that
      replica's own use. The exception to this is any downstream
      replicas of the replica where you enabled
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   , and any
      servers that were created from a backup of that replica.
  </p>
  <p>
   If you set up any downstream replicas, these servers do not have
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   enabled.
      Only the replica that is receiving transactions directly from the
      non-GTID source server needs to have
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   set on
      the relevant replication channel. Among that replica and its
      downstream replicas, you can compare GTID sets, fail over from one
      replica to another, and use backups to create additional replicas,
      as you would in any GTID-based replication topology.
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   is used
      where transactions are received from a non-GTID server outside
      this group.
  </p>
  <p>
   A replication channel using
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   has the
      following behavior differences to GTID-based replication:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      GTIDs are assigned to the replicated transactions when they
          are applied (unless they already had a GTID). A GTID would
          normally be assigned on the replication source server when the
          transaction is committed, and sent to the replica along with
          the transaction. On a multi-threaded replica, this means the
          order of the GTIDs does not necessarily match the order of the
          transactions, even if
      <a class="link" href="replication-options-replica.html#sysvar_replica_preserve_commit_order">
       <code class="literal">
        replica_preserve_commit_order
       </code>
      </a>
      = 1.
     </p>
    </li>
    <li class="listitem">
     <p>
      The
      <code class="literal">
       SOURCE_LOG_FILE
      </code>
      and
      <code class="literal">
       SOURCE_LOG_POS
      </code>
      options of the
      <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 are used to position the replication I/O (receiver)
          thread, rather than the
      <code class="literal">
       SOURCE_AUTO_POSITION
      </code>
      option.
     </p>
    </li>
    <li class="listitem">
     <p>
      The
      <code class="literal">
       SET GLOBAL sql_replica_skip_counter
      </code>
      statement is used to skip transactions on a replication
          channel set up with
      <code class="literal">
       ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
      </code>
      ,
          rather than the method of committing empty transactions. For
          instructions, see
      <a class="xref" href="replication-administration-skip.html" title="19.1.7.3 Skipping Transactions">
       Section 19.1.7.3, “Skipping Transactions”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      The
      <code class="literal">
       UNTIL SQL_BEFORE_GTIDS
      </code>
      and
      <code class="literal">
       UNTIL_SQL_AFTER_GTIDS
      </code>
      options of the
      <a class="link" href="start-replica.html" title="15.4.2.4 START REPLICA Statement">
       <code class="literal">
        START REPLICA
       </code>
      </a>
      statement cannot
          be used for the channel.
     </p>
    </li>
    <li class="listitem">
     <p>
      The function
      <a class="link" href="gtid-functions.html#function_wait-for-executed-gtid-set">
       <code class="literal">
        WAIT_FOR_EXECUTED_GTID_SET()
       </code>
      </a>
      works across the server and can be used to wait for any
          downstream replicas of the server that have
      <code class="literal">
       ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
      </code>
      enabled. To wait for the channel with
      <code class="literal">
       ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
      </code>
      enabled to catch up with the source, which does not use GTIDs,
          use the
      <a class="link" href="replication-functions-synchronization.html#function_source-pos-wait">
       <code class="literal">
        SOURCE_POS_WAIT()
       </code>
      </a>
      function.
     </p>
    </li>
   </ul>
  </div>
  <p>
   The Performance Schema
   <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>
   table shows whether GTIDs are assigned to anonymous transactions
      on a replication channel, what the UUID is, and whether it is the
      UUID of the replica server (
   <code class="literal">
    LOCAL
   </code>
   ) or a
      user-specified UUID (
   <code class="literal">
    UUID
   </code>
   ). The information is
      also recorded in the applier metadata repository. A
   <a class="link" href="reset-replica.html" title="15.4.2.3 RESET REPLICA Statement">
    <code class="literal">
     RESET REPLICA
      ALL
    </code>
   </a>
   statement resets the
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   setting,
      but a
   <a class="link" href="reset-replica.html" title="15.4.2.3 RESET REPLICA Statement">
    <code class="literal">
     RESET REPLICA
    </code>
   </a>
   statement does
      not.
  </p>
 </div>
 <br/>
</div>
