<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="group-replication-gtids">
      </a>
      20.4.1 GTIDs and Group Replication
     </h3>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045133721280">
  </a>
  <p>
   Group Replication uses GTIDs (global transaction identifiers) to
      track exactly which transactions have been committed on every
      server instance. The settings
   <a class="link" href="replication-options-gtids.html#sysvar_gtid_mode">
    <code class="literal">
     gtid_mode=ON
    </code>
   </a>
   and
   <a class="link" href="replication-options-gtids.html#sysvar_enforce_gtid_consistency">
    <code class="literal">
     enforce_gtid_consistency=ON
    </code>
   </a>
   are
      required on all group members. Incoming transactions from clients
      are assigned a GTID by the group member that receives them. Any
      replicated transactions that are received by group members on
      asynchronous replication channels from source servers outside the
      group retain the GTIDs that they have when they arrive on the
      group member.
  </p>
  <p>
   The GTIDs that are assigned to incoming transactions from clients
      use the group name specified by the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_group_name">
    <code class="literal">
     group_replication_group_name
    </code>
   </a>
   system variable as the UUID part of the identifier, rather than
      the server UUID of the individual group member that received the
      transaction. All the transactions received directly by the group
      can therefore be identified and are grouped together in GTID sets,
      and it does not matter which member originally received them. Each
      group member has a block of consecutive GTIDs reserved for its
      use, and when these are consumed it reserves more. The
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_gtid_assignment_block_size">
    <code class="literal">
     group_replication_gtid_assignment_block_size
    </code>
   </a>
   system variable sets the size of the blocks, with a default of 1
      million GTIDs in each block.
  </p>
  <p>
   View change events (
   <code class="literal">
    View_change_log_event
   </code>
   ),
      which are generated by the group itself when a new member joins,
      are given GTIDs when they are recorded in the binary log. By
      default, the GTIDs for these events also use the group name
      specified by the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_group_name">
    <code class="literal">
     group_replication_group_name
    </code>
   </a>
   system variable as the UUID part of the identifier. You can set
      the Group Replication system variable
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_view_change_uuid">
    <code class="literal">
     group_replication_view_change_uuid
    </code>
   </a>
   to use an alternative UUID in the GTIDs for view change events, so
      that they are easy to distinguish from transactions received by
      the group from clients. This can be useful if your setup allows
      for failover between groups, and you need to identify and discard
      transactions that were specific to the backup group. The
      alternative UUID must be different from the server UUIDs of the
      members. It must also be different from any UUIDs in the GTIDs
      applied to anonymous transactions using the
   <code class="literal">
    ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
   </code>
   option
      of the
   <code class="literal">
    CHANGE REPLICATION SOURCE TO
   </code>
   statement.
  </p>
  <p>
   <code class="literal">
    GTID_ONLY=1
   </code>
   ,
   <code class="literal">
    REQUIRE_ROW_FORMAT =
      1
   </code>
   , and
   <code class="literal">
    SOURCE_AUTO_POSITION = 1
   </code>
   are
      applied for the Group Replication channels
   <code class="literal">
    group_replication_applier
   </code>
   and
   <code class="literal">
    group_replication_recovery
   </code>
   . The settings are
      made automatically on the Group Replication channels when they are
      created, or when a member server in a replication group is
      upgraded. These options are normally set using 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
    </code>
   </a>
   statement, but note that you cannot disable them for a Group
      Replication channel. With these options set, the group member does
      not persist file names and file positions in the replication
      metadata repositories for these channels. GTID auto-positioning
      and GTID auto-skip are used to locate the correct receiver and
      applier positions when necessary.
  </p>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="group-replication-gtids-extra">
       </a>
       Extra Transactions
      </h4>
     </div>
    </div>
   </div>
   <p>
    If a joining member has transactions in its GTID set that are
        not present on the existing members of the group, it is not
        allowed to complete the distributed recovery process, and cannot
        join the group. If a remote cloning operation was carried out,
        these transactions would be deleted and lost, because the data
        directory on the joining member is erased. If state transfer
        from a donor's binary log was carried out, these transactions
        could conflict with the group's transactions.
   </p>
   <p>
    Extra transactions might be present on a member if an
        administrative transaction is carried out on the instance while
        Group Replication is stopped. To avoid introducing new
        transactions in that way, always set the value of the
    <a class="link" href="replication-options-binary-log.html#sysvar_sql_log_bin">
     <code class="literal">
      sql_log_bin
     </code>
    </a>
    system variable to
    <code class="literal">
     OFF
    </code>
    before issuing administrative statements,
        and back to
    <code class="literal">
     ON
    </code>
    afterwards:
   </p>
   <div class="copytoclipboard-wrapper">
    <pre class="programlisting language-sql"><div class="docs-select-all right" id="sa63015034"><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-sql"><span class="token keyword">SET</span> SQL_LOG_BIN<span class="token operator">=</span><span class="token number">0</span><span class="token punctuation">;</span>
<span class="token operator">&lt;</span>administrator <span class="token keyword">action</span><span class="token operator">&gt;</span>
<span class="token keyword">SET</span> SQL_LOG_BIN<span class="token operator">=</span><span class="token number">1</span><span class="token punctuation">;</span></code></pre>
   </div>
   <p>
    Setting this system variable to
    <code class="literal">
     OFF
    </code>
    means
        that the transactions that occur from that point until you set
        it back to
    <code class="literal">
     ON
    </code>
    are not written to the binary
        log and do not have GTIDs assigned to them.
   </p>
   <p>
    If an extra transaction is present on a joining member, check
        the binary log for the affected server to see what the extra
        transaction actually contains. The safest method to reconcile
        the joining member’s data and GTID set with the members
        currently in the group is to use MySQL's cloning functionality
        to transfer the content from a server in the group to the
        affected server. For instructions to do this, see
    <a class="xref" href="clone-plugin-remote.html" title="7.6.7.3 Cloning Remote Data">
     Section 7.6.7.3, “Cloning Remote Data”
    </a>
    . If the
        transaction is required, rerun it after the member has
        successfully rejoined.
   </p>
  </div>
 </div>
 <br/>
</div>
