<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="group-replication-limitations">
      </a>
      20.3.2 Group Replication Limitations
     </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-limitations.html#group-replication-limitations-group-size" title="Limit on Group Size">
       Limit on Group Size
      </a>
     </p>
    </li>
    <li class="listitem">
     <p>
      <a class="xref" href="group-replication-limitations.html#group-replication-limitations-transaction-size" title="Limits on Transaction Size">
       Limits on Transaction Size
      </a>
     </p>
    </li>
   </ul>
  </div>
  <a class="indexterm" name="idm46045133836080">
  </a>
  <p>
   The following known limitations exist for Group Replication. Note
      that the limitations and issues described for multi-primary mode
      groups can also apply in single-primary mode clusters during a
      failover event, while the newly elected primary flushes out its
      applier queue from the old primary.
  </p>
  <div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Tip
   </div>
   <p>
    Group Replication is built on GTID based replication, therefore
        you should also be aware of
    <a class="xref" href="replication-gtids-restrictions.html" title="19.1.3.7 Restrictions on Replication with GTIDs">
     Section 19.1.3.7, “Restrictions on Replication with GTIDs”
    </a>
    .
   </p>
  </div>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <b>
       <code class="literal">
        --upgrade=MINIMAL
       </code>
       option.
      </b>
      Group Replication cannot be started following a MySQL Server
            upgrade that uses the MINIMAL option
            (
      <code class="literal">
       --upgrade=MINIMAL
      </code>
      ), which does not
            upgrade system tables on which the replication internals
            depend.
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       Gap Locks.
      </b>
      Group Replication's certification process for concurrent
            transactions does not take into account
      <a class="link" href="glossary.html#glos_gap_lock" title="gap lock">
       gap locks
      </a>
      , as
            information about gap locks is not available outside of
      <a class="link" href="innodb-storage-engine.html" title="Chapter 17 The InnoDB Storage Engine">
       <code class="literal">
        InnoDB
       </code>
      </a>
      . See
      <a class="xref" href="innodb-locking.html#innodb-gap-locks" title="Gap Locks">
       Gap Locks
      </a>
      for more information.
     </p>
     <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
      <div class="admon-title">
       Note
      </div>
      <p>
       For a group in multi-primary mode, unless you rely on
       <a class="link" href="innodb-transaction-isolation-levels.html#isolevel_repeatable-read">
        <code class="literal">
         REPEATABLE READ
        </code>
       </a>
       semantics
            in your applications, we recommend using the
       <a class="link" href="innodb-transaction-isolation-levels.html#isolevel_read-committed">
        <code class="literal">
         READ COMMITTED
        </code>
       </a>
       isolation
            level with Group Replication. InnoDB does not use gap locks
            in
       <a class="link" href="innodb-transaction-isolation-levels.html#isolevel_read-committed">
        <code class="literal">
         READ COMMITTED
        </code>
       </a>
       , which
            aligns the local conflict detection within InnoDB with the
            distributed conflict detection performed by Group
            Replication. For a group in single-primary mode, only the
            primary accepts writes, so the
       <a class="link" href="innodb-transaction-isolation-levels.html#isolevel_read-committed">
        <code class="literal">
         READ
            COMMITTED
        </code>
       </a>
       isolation level is not important to
            Group Replication.
      </p>
     </div>
    </li>
    <li class="listitem">
     <p>
      <b>
       Table Locks and Named Locks.
      </b>
      The certification process does not take into account table
            locks (see
      <a class="xref" href="lock-tables.html" title="15.3.6 LOCK TABLES and UNLOCK TABLES Statements">
       Section 15.3.6, “LOCK TABLES and UNLOCK TABLES Statements”
      </a>
      ) or named locks
            (see
      <a class="link" href="locking-functions.html#function_get-lock">
       <code class="literal">
        GET_LOCK()
       </code>
      </a>
      ).
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       Binary Log Checksums.
      </b>
      Group Replication in MySQL 8.4 supports
            checksums, so group members may use the default setting
      <a class="link" href="replication-options-binary-log.html#sysvar_binlog_checksum">
       <code class="literal">
        binlog_checksum=CRC32
       </code>
      </a>
      . The
            setting for
      <a class="link" href="replication-options-binary-log.html#sysvar_binlog_checksum">
       <code class="literal">
        binlog_checksum
       </code>
      </a>
      does not have to be the same for all members of a group.
     </p>
     <p>
      When checksums are available, Group Replication does not use
          them to verify incoming events on the
      <code class="literal">
       group_replication_applier
      </code>
      channel, because
          events are written to that relay log from multiple sources and
          before they are actually written to the originating server's
          binary log, which is when a checksum is generated. Checksums
          are used to verify the integrity of events on the
      <code class="literal">
       group_replication_recovery
      </code>
      channel and on
          any other replication channels on group members.
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       SERIALIZABLE Isolation Level.
      </b>
      <a class="link" href="innodb-transaction-isolation-levels.html#isolevel_serializable">
       <code class="literal">
        SERIALIZABLE
       </code>
      </a>
      isolation
            level is not supported in multi-primary groups by default.
            Setting a transaction isolation level to
      <code class="literal">
       SERIALIZABLE
      </code>
      configures Group Replication
            to refuse to commit the transaction.
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       Concurrent DDL versus DML Operations.
      </b>
      Concurrent data definition statements and data manipulation
            statements executing against the same object but on
            different servers is not supported when using multi-primary
            mode. During execution of Data Definition Language (DDL)
            statements on an object, executing concurrent Data
            Manipulation Language (DML) on the same object but on a
            different server instance has the risk of conflicting DDL
            executing on different instances not being detected.
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       Foreign Keys with Cascading Constraints.
      </b>
      Multi-primary mode groups (members all configured with
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_single_primary_mode">
       <code class="literal">
        group_replication_single_primary_mode=OFF
       </code>
      </a>
      )
            do not support tables with multi-level foreign key
            dependencies, specifically tables that have defined
      <code class="literal">
       CASCADING
      </code>
      <a class="link" href="glossary.html#glos_foreign_key_constraint" title="FOREIGN KEY constraint">
       foreign key
            constraints
      </a>
      . This is because foreign key constraints
            that result in cascading operations executed by a
            multi-primary mode group can result in undetected conflicts
            and lead to inconsistent data across the members of the
            group. Therefore we recommend setting
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_enforce_update_everywhere_checks">
       <code class="literal">
        group_replication_enforce_update_everywhere_checks=ON
       </code>
      </a>
      on server instances used in multi-primary mode groups to
            avoid undetected conflicts.
     </p>
     <p>
      In single-primary mode this is not a problem as it does not
          allow concurrent writes to multiple members of the group and
          thus there is no risk of undetected conflicts.
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       Multi-primary Mode Deadlock.
      </b>
      When a group is operating in multi-primary mode,
      <code class="literal">
       SELECT .. FOR UPDATE
      </code>
      statements can
            result in a deadlock. This is because the lock is not shared
            across the members of the group, therefore the expectation
            for such a statement might not be reached.
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       Replication Filters.
      </b>
      Global replication filters cannot be used on a MySQL server
            instance that is configured for Group Replication, because
            filtering transactions on some servers would make the group
            unable to reach agreement on a consistent state. Channel
            specific replication filters can be used on replication
            channels that are not directly involved with Group
            Replication, such as where a group member also acts as a
            replica to a source that is outside the group. They cannot
            be used on the
      <code class="literal">
       group_replication_applier
      </code>
      or
      <code class="literal">
       group_replication_recovery
      </code>
      channels.
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       Encrypted Connections.
      </b>
      Support for the TLSv1.3 protocol is available in MySQL,
            provided that it was compiled using OpenSSL 1.1.1 or higher.
            Group Replication supports TLSv1.3, where it can be used for
            group communication connections and distributed recovery
            connections.
     </p>
     <p>
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_tls_version">
       <code class="literal">
        group_replication_recovery_tls_version
       </code>
      </a>
      and
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_tls_ciphersuites">
       <code class="literal">
        group_replication_recovery_tls_ciphersuites
       </code>
      </a>
      can be used to configure client support for any selection of
          ciphersuites, including only non-default ciphersuites if
          desired. See
      <a class="xref" href="encrypted-connection-protocols-ciphers.html" title="8.3.2 Encrypted Connection TLS Protocols and Ciphers">
       Section 8.3.2, “Encrypted Connection TLS Protocols and Ciphers”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       Cloning Operations.
      </b>
      Group Replication initiates and manages cloning operations
            for distributed recovery, but group members that have been
            set up to support cloning may also participate in cloning
            operations that a user initiates manually. You can initiate
            a cloning operation manually if the operation involves a
            group member on which Group Replication is running, provided
            that the cloning operation does not remove and replace the
            data on the recipient. The statement to initiate the cloning
            operation must therefore include the
      <code class="literal">
       DATA
            DIRECTORY
      </code>
      clause if Group Replication is running.
            See
      <a class="xref" href="group-replication-cloning.html#group-replication-cloning-manual" title="20.5.4.2.4 Cloning for Other Purposes">
       Section 20.5.4.2.4, “Cloning for Other Purposes”
      </a>
      .
     </p>
    </li>
   </ul>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="group-replication-limitations-group-size">
       </a>
       Limit on Group Size
      </h4>
     </div>
    </div>
   </div>
   <p>
    The maximum number of MySQL servers that can be members of a
        single replication group is 9. If further members attempt to
        join the group, their request is refused. This limit has been
        identified from testing and benchmarking as a safe boundary
        where the group performs reliably on a stable local area
        network.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="group-replication-limitations-transaction-size">
       </a>
       Limits on Transaction Size
      </h4>
     </div>
    </div>
   </div>
   <p>
    If an individual transaction results in message contents which
        are large enough that the message cannot be copied between group
        members over the network within a 5-second window, members can
        be suspected of having failed, and then expelled, just because
        they are busy processing the transaction. Large transactions can
        also cause the system to slow due to problems with memory
        allocation. To avoid these issues use the following mitigations:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       If unnecessary expulsions occur due to large messages, use
            the system variable
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_member_expel_timeout">
        <code class="literal">
         group_replication_member_expel_timeout
        </code>
       </a>
       to allow additional time before a member under suspicion of
            having failed is expelled. You can allow up to an hour after
            the initial 5-second detection period before a suspect
            member is expelled from the group. An additional 5 seconds
            is allowed by default.
      </p>
     </li>
     <li class="listitem">
      <p>
       Where possible, try and limit the size of your transactions
            before they are handled by Group Replication. For example,
            split up files used with
       <code class="literal">
        LOAD DATA
       </code>
       into
            smaller chunks.
      </p>
     </li>
     <li class="listitem">
      <p>
       Use the system variable
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_transaction_size_limit">
        <code class="literal">
         group_replication_transaction_size_limit
        </code>
       </a>
       to specify a maximum transaction size that the group
            accepts. The default maximum transaction size is 150000000
            bytes (approximately 143 MB); transactions above this size
            are rolled back and are not sent to Group Replication's
            Group Communication System (GCS) for distribution to the
            group. Adjust the value of this variable depending on the
            maximum message size that you need the group to tolerate,
            bearing in mind that the time taken to process a transaction
            is proportional to its size.
      </p>
     </li>
     <li class="listitem">
      <p>
       Use the system variable
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_compression_threshold">
        <code class="literal">
         group_replication_compression_threshold
        </code>
       </a>
       to specify a message size above which compression is
            applied. This system variable defaults to 1000000 bytes (1
            MB), so large messages are automatically compressed.
            Compression is carried out by Group Replication's Group
            Communication System (GCS) when it receives a message that
            was permitted by the
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_transaction_size_limit">
        <code class="literal">
         group_replication_transaction_size_limit
        </code>
       </a>
       setting but exceeds the
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_compression_threshold">
        <code class="literal">
         group_replication_compression_threshold
        </code>
       </a>
       setting. For more information, see
       <a class="xref" href="group-replication-message-compression.html" title="20.7.4 Message Compression">
        Section 20.7.4, “Message Compression”
       </a>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       Use the system variable
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_communication_max_message_size">
        <code class="literal">
         group_replication_communication_max_message_size
        </code>
       </a>
       to specify a message size above which messages are
            fragmented. This system variable defaults to 10485760 bytes
            (10 MiB), so large messages are automatically fragmented.
            GCS carries out fragmentation after compression if the
            compressed message still exceeds the
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_communication_max_message_size">
        <code class="literal">
         group_replication_communication_max_message_size
        </code>
       </a>
       limit. For more information, see
       <a class="xref" href="group-replication-performance-message-fragmentation.html" title="20.7.5 Message Fragmentation">
        Section 20.7.5, “Message Fragmentation”
       </a>
       .
      </p>
     </li>
    </ul>
   </div>
   <p>
    The maximum transaction size, message compression, and message
        fragmentation can all be deactivated by specifying a zero value
        for the relevant system variable. If you have deactivated all
        these safeguards, the upper size limit for a message that can be
        handled by the applier thread on a member of a replication group
        is the value of the member's
    <a class="link" href="replication-options-replica.html#sysvar_replica_max_allowed_packet">
     <code class="literal">
      replica_max_allowed_packet
     </code>
    </a>
    system variable, which has a default and maximum value of
        1073741824 bytes (1 GB). A message that exceeds this limit fails
        when the receiving member attempts to handle it. The upper size
        limit for a message that a group member can originate and
        attempt to transmit to the group is 4294967295 bytes
        (approximately 4 GB). This is a hard limit on the packet size
        that is accepted by the group communication engine for Group
        Replication (XCom, a Paxos variant), which receives messages
        after GCS has handled them. A message that exceeds this limit
        fails when the originating member attempts to broadcast it.
   </p>
  </div>
 </div>
 <br/>
</div>
