<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="group-replication-requirements">
      </a>
      20.3.1 Group Replication Requirements
     </h3>
    </div>
   </div>
  </div>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <a class="xref" href="group-replication-requirements.html#group-replication-infrastructure" title="Infrastructure">
       Infrastructure
      </a>
     </p>
    </li>
    <li class="listitem">
     <p>
      <a class="xref" href="group-replication-requirements.html#group-replication-configuration" title="Server Instance Configuration">
       Server Instance Configuration
      </a>
     </p>
    </li>
   </ul>
  </div>
  <a class="indexterm" name="idm46045133918768">
  </a>
  <p>
   Server instances that you want to use for Group Replication must
      satisfy the following requirements.
  </p>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="group-replication-infrastructure">
       </a>
       Infrastructure
      </h4>
     </div>
    </div>
   </div>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       <b>
        InnoDB Storage Engine.
       </b>
       Data must be stored in the
       <a class="link" href="innodb-storage-engine.html" title="Chapter 17 The InnoDB Storage Engine">
        <code class="literal">
         InnoDB
        </code>
       </a>
       transactional storage
              engine. Transactions are executed optimistically and then,
              at commit time, are checked for conflicts. If there are
              conflicts, in order to maintain consistency across the
              group, some transactions are rolled back. This means that
              a transactional storage engine is required. Moreover,
       <a class="link" href="innodb-storage-engine.html" title="Chapter 17 The InnoDB Storage Engine">
        <code class="literal">
         InnoDB
        </code>
       </a>
       provides some
              additional functionality that enables better management
              and handling of conflicts when operating together with
              Group Replication. The use of other storage engines,
              including the temporary
       <a class="link" href="memory-storage-engine.html" title="18.3 The MEMORY Storage Engine">
        <code class="literal">
         MEMORY
        </code>
       </a>
       storage engine, might
              cause errors in Group Replication. Convert any tables in
              other storage engines to use
       <a class="link" href="innodb-storage-engine.html" title="Chapter 17 The InnoDB Storage Engine">
        <code class="literal">
         InnoDB
        </code>
       </a>
       before using the
              instance with Group Replication. You can prevent the use
              of other storage engines by setting the
       <a class="link" href="server-system-variables.html#sysvar_disabled_storage_engines">
        <code class="literal">
         disabled_storage_engines
        </code>
       </a>
       system variable on group members, for example:
      </p>
      <div class="copytoclipboard-wrapper">
       <pre class="programlisting one-line language-ini"><div class="docs-select-all right" id="sa68254029"><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-ini"><span class="token constant">disabled_storage_engines</span><span class="token attr-value"><span class="token punctuation">=</span>"MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"</span></code></pre>
      </div>
     </li>
     <li class="listitem">
      <p>
       <b>
        Primary Keys.
       </b>
       Every table that is to be replicated by the group must
              have a defined primary key, or primary key equivalent
              where the equivalent is a non-null unique key. Such keys
              are required as a unique identifier for every row within a
              table, enabling the system to determine which transactions
              conflict by identifying exactly which rows each
              transaction has modified. Group Replication has its own
              built-in set of checks for primary keys or primary key
              equivalents, and does not use the checks carried out by
              the
       <a class="link" href="server-system-variables.html#sysvar_sql_require_primary_key">
        <code class="literal">
         sql_require_primary_key
        </code>
       </a>
       system variable. You may set
       <code class="literal">
        sql_require_primary_key=ON
       </code>
       for a server
              instance where Group Replication is running, and you may
              set the
       <code class="literal">
        REQUIRE_TABLE_PRIMARY_KEY_CHECK
       </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 to
       <code class="literal">
        ON
       </code>
       for a Group Replication channel.
              However, be aware that you might find some transactions
              that are permitted under Group Replication's built-in
              checks are not permitted under the checks carried out when
              you set
       <code class="literal">
        sql_require_primary_key=ON
       </code>
       or
       <code class="literal">
        REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON
       </code>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <b>
        Network Performance.
       </b>
       MySQL Group Replication is designed to be deployed in a
              cluster environment where server instances are very close
              to each other. The performance and stability of a group
              can be impacted by both network latency and network
              bandwidth. Bi-directional communication must be maintained
              at all times between all group members. If either inbound
              or outbound communication is blocked for a server instance
              (for example, by a firewall, or by connectivity issues),
              the member cannot function in the group, and the group
              members (including the member with issues) might not be
              able to report the correct member status for the affected
              server instance.
      </p>
      <p>
       You can use a network infrastructure based on IPv4, IPv6, or
            a mix of the two, for TCP communication between remote Group
            Replication servers. There is also nothing preventing Group
            Replication from operating over a virtual private network
            (VPN).
      </p>
      <p>
       Where Group Replication server instances are co-located and
            share a local group communication engine (XCom) instance, a
            dedicated input channel with lower overhead is used for
            communication where possible instead of the TCP socket. For
            certain Group Replication tasks that require communication
            between remote XCom instances, such as joining a group, the
            TCP network is still used, so network performance influences
            the group's performance.
      </p>
     </li>
    </ul>
   </div>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="group-replication-configuration">
       </a>
       Server Instance Configuration
      </h4>
     </div>
    </div>
   </div>
   <p>
    The following options must be configured as shown on server
        instances that are members of a group.
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       <b>
        Unique Server Identifier.
       </b>
       Use the
       <a class="link" href="replication-options.html#sysvar_server_id">
        <code class="literal">
         server_id
        </code>
       </a>
       system
              variable to configure the server with a unique server ID,
              as required for all servers in replication topologies. The
              server ID must be a positive integer between 1 and
              (2
       <sup>
        32
       </sup>
       )−1, and it must be
              different from every other server ID in use by any other
              server in the replication topology.
      </p>
     </li>
     <li class="listitem">
      <p>
       <b>
        Binary Log Active.
       </b>
       In MySQL 8.4, binary logging is enabled by
              default. You can optionally specify the names of the
              binary log files using
       <a class="link" href="replication-options-binary-log.html#sysvar_log_bin">
        <code class="literal">
         --log-bin[=log_file_name]
        </code>
       </a>
       .
              Group Replication replicates the binary log's contents,
              therefore the binary log needs to be on for it to operate.
              See
       <a class="xref" href="binary-log.html" title="7.4.4 The Binary Log">
        Section 7.4.4, “The Binary Log”
       </a>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <b>
        Replica Updates Logged.
       </b>
       Set
       <a class="link" href="replication-options-binary-log.html#sysvar_log_replica_updates">
        <code class="literal">
         log_replica_updates=ON
        </code>
       </a>
       if
              it is not already enabled. (In MySQL 8.4,
              this is the default.) Group members need to log
              transactions that are received from their donors at
              joining time and applied through the replication applier,
              and to log all transactions that they receive and apply
              from the group. This enables Group Replication to carry
              out distributed recovery by state transfer from an
              existing group member's binary log.
      </p>
     </li>
     <li class="listitem">
      <p>
       <b>
        Binary Log Row Format.
       </b>
       Set
       <a class="link" href="replication-options-binary-log.html#sysvar_binlog_format">
        <code class="literal">
         binlog_format=ROW
        </code>
       </a>
       if
              necessary; in MySQL 8.4, this is the default.
              Group Replication relies on the row-based replication
              format to propagate changes consistently among the servers
              in the group, and extract the necessary information to
              detect conflicts among transactions that execute
              concurrently in different servers in the group. The
              setting for
       <code class="literal">
        REQUIRE_ROW_FORMAT
       </code>
       is
              automatically added to Group Replication's channels to
              enforce the use of row-based replication when the
              transactions are applied. See
       <a class="xref" href="replication-formats.html" title="19.2.1 Replication Formats">
        Section 19.2.1, “Replication Formats”
       </a>
       and
       <a class="xref" href="replication-privilege-checks.html" title="19.3.3 Replication Privilege Checks">
        Section 19.3.3, “Replication Privilege Checks”
       </a>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <b>
        Global Transaction Identifiers On.
       </b>
       Set
       <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>
       .
              These settings are not the defaults. GTID-based
              replication is required for Group Replication, which uses
              global transaction identifiers to track the transactions
              that have been committed on every server instance in the
              group. See
       <a class="xref" href="replication-gtids.html" title="19.1.3 Replication with Global Transaction Identifiers">
        Section 19.1.3, “Replication with Global Transaction Identifiers”
       </a>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <b>
        Default Table Encryption.
       </b>
       Set
       <a class="link" href="server-system-variables.html#sysvar_default_table_encryption">
        <code class="literal">
         default_table_encryption
        </code>
       </a>
       to the same value on all group members. Default schema and
              tablespace encryption can be either enabled
              (
       <code class="literal">
        ON
       </code>
       ) or disabled
              (
       <code class="literal">
        OFF
       </code>
       , the default) as long as the
              setting is the same on all members.
      </p>
     </li>
     <li class="listitem">
      <p>
       <b>
        Lower Case Table Names.
       </b>
       Set
       <a class="link" href="server-system-variables.html#sysvar_lower_case_table_names">
        <code class="literal">
         lower_case_table_names
        </code>
       </a>
       to
              the same value on all group members. A setting of 1 is
              correct for the use of the
       <a class="link" href="innodb-storage-engine.html" title="Chapter 17 The InnoDB Storage Engine">
        <code class="literal">
         InnoDB
        </code>
       </a>
       storage engine, which
              is required for Group Replication. Note that this setting
              is not the default on all platforms.
      </p>
     </li>
     <li class="listitem">
      <p>
       <b>
        Multithreaded Appliers.
       </b>
       Group Replication members can be configured as
              multithreaded replicas, enabling transactions to be
              applied in parallel. All replicas are configured as
              multithreaded by default. A nonzero value for
       <a class="link" href="replication-options-replica.html#sysvar_replica_parallel_workers">
        <code class="literal">
         replica_parallel_workers
        </code>
       </a>
       enables the multithreaded applier on the member. The
              default is 4 parallel applier threads; up to 1024 parallel
              applier threads can be specified.
      </p>
      <p>
       Setting
       <a class="link" href="replication-options-replica.html#sysvar_replica_parallel_workers">
        <code class="literal">
         replica_parallel_workers=0
        </code>
       </a>
       disables parallel execution and gives the replica a single
            applier thread and no coordinator thread. With that setting,
            the
       <a class="link" href="replication-options-replica.html#sysvar_replica_parallel_type">
        <code class="literal">
         replica_parallel_type
        </code>
       </a>
       and
       <a class="link" href="replication-options-replica.html#sysvar_replica_preserve_commit_order">
        <code class="literal">
         replica_preserve_commit_order
        </code>
       </a>
       options have no effect and are ignored. If parallel
            execution is disabled when GTIDs are in use on a replica,
            the replica actually uses one parallel worker, to take
            advantage of the method for retrying transactions without
            accessing the file positions. However, this behavior does
            not change anything for the user.
      </p>
     </li>
     <li class="listitem">
      <p>
       <b>
        Detached XA transactions.
       </b>
       MySQL 8.4 and later supports detached XA
              transactions. A detached transaction is one which, once
              prepared, is no longer connected to the current session.
              This happens automatically as part of executing
       <a class="link" href="xa-statements.html" title="15.3.8.1 XA Transaction SQL Statements">
        <code class="literal">
         XA
              PREPARE
        </code>
       </a>
       . The prepared XA transaction can be
              committed or rolled back by another connection, and the
              current session can then initiate another XA transaction
              or local transaction without waiting for the transaction
              that was just prepared to complete.
      </p>
      <p>
       When detached XA transaction support is enabled
            (
       <a class="link" href="server-system-variables.html#sysvar_xa_detach_on_prepare">
        <code class="literal">
         xa_detach_on_prepare = ON
        </code>
       </a>
       )
            it is possible for any connection to this server to list
            (using
       <a class="link" href="xa-statements.html" title="15.3.8.1 XA Transaction SQL Statements">
        <code class="literal">
         XA
            RECOVER
        </code>
       </a>
       ), roll back, or commit any prepared XA
            transaction. In addition, you cannot use temporary tables
            within detached XA transactions.
      </p>
      <p>
       You can disable support for detached XA transactions by
            setting
       <a class="link" href="server-system-variables.html#sysvar_xa_detach_on_prepare">
        <code class="literal">
         xa_detach_on_prepare
        </code>
       </a>
       to
       <code class="literal">
        OFF
       </code>
       , but this is not recommended. In
            particular, if this server is being set up as an instance in
            MySQL group replication, you should leave this variable set
            to its default value (
       <code class="literal">
        ON
       </code>
       ).
      </p>
      <p>
       See
       <a class="xref" href="xa-states.html" title="15.3.8.2 XA Transaction States">
        Section 15.3.8.2, “XA Transaction States”
       </a>
       , for more information.
      </p>
     </li>
    </ul>
   </div>
  </div>
 </div>
 <br/>
</div>
