MySQL 8.0 Reference Manual Including MySQL NDB Cluster 8.0
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.
Group Replication is built on GTID based replication, therefore you should also be aware of Section 17.1.3.7, “Restrictions on Replication with GTIDs”.
--upgrade=MINIMAL
option.
Group Replication cannot be started following a MySQL Server
upgrade that uses the MINIMAL option
(--upgrade=MINIMAL
), which does not
upgrade system tables on which the replication internals
depend.
Gap Locks.
Group Replication's certification process for concurrent
transactions does not take into account
gap locks, as
information about gap locks is not available outside of
InnoDB
. See
Gap Locks for more information.
For a group in multi-primary mode, unless you rely on
REPEATABLE READ
semantics
in your applications, we recommend using the
READ COMMITTED
isolation
level with Group Replication. InnoDB does not use gap locks
in READ COMMITTED
, 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 READ
COMMITTED
isolation level is not important to
Group Replication.
Table Locks and Named Locks.
The certification process does not take into account table
locks (see Section 13.3.6, “LOCK TABLES and UNLOCK TABLES Statements”) or named locks
(see GET_LOCK()
).
Binary Log Checksums.
Up to and including MySQL 8.0.20, Group Replication cannot
make use of checksums and does not support their presence in
the binary log, so you must set
binlog_checksum=NONE
when
configuring a server instance to become a group member. From
MySQL 8.0.21, Group Replication supports checksums, so group
members may use the default setting
binlog_checksum=CRC32
. The
setting for binlog_checksum
does not have to be the same for all members of a group.
When checksums are available, Group Replication does not use
them to verify incoming events on the
group_replication_applier
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
group_replication_recovery
channel and on
any other replication channels on group members.
SERIALIZABLE Isolation Level.
SERIALIZABLE
isolation
level is not supported in multi-primary groups by default.
Setting a transaction isolation level to
SERIALIZABLE
configures Group Replication
to refuse to commit the transaction.
Concurrent DDL versus DML Operations. 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.
Foreign Keys with Cascading Constraints.
Multi-primary mode groups (members all configured with
group_replication_single_primary_mode=OFF
)
do not support tables with multi-level foreign key
dependencies, specifically tables that have defined
CASCADING
foreign key
constraints. 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
group_replication_enforce_update_everywhere_checks=ON
on server instances used in multi-primary mode groups to
avoid undetected conflicts.
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.
Multi-primary Mode Deadlock.
When a group is operating in multi-primary mode,
SELECT .. FOR UPDATE
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.
Replication Filters.
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 group_replication_applier
or group_replication_recovery
channels.
Encrypted Connections. Support for the TLSv1.3 protocol is available in MySQL Server as of MySQL 8.0.16, provided that MySQL was compiled using OpenSSL 1.1.1 or higher. In MySQL 8.0.16 and MySQL 8.0.17, if the server supports TLSv1.3, the protocol is not supported in the group communication engine and cannot be used by Group Replication. Group Replication supports TLSv1.3 from MySQL 8.0.18, where it can be used for group communication connections and distributed recovery connections.
In MySQL 8.0.18, TLSv1.3 can be used in Group Replication for
the distributed recovery connection, but the
group_replication_recovery_tls_version
and
group_replication_recovery_tls_ciphersuites
system variables are not available. The donor servers must
therefore permit the use of at least one TLSv1.3 ciphersuite
that is enabled by default, as listed in
Section 6.3.2, “Encrypted Connection TLS Protocols and Ciphers”. From
MySQL 8.0.19, you can use the options to configure client
support for any selection of ciphersuites, including only
non-default ciphersuites if you want.
Cloning Operations.
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. In releases
before MySQL 8.0.20, you cannot initiate a cloning operation
manually if the operation involves a group member on which
Group Replication is running. From MySQL 8.0.20, you can do
this, 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
DATA DIRECTORY
clause if Group
Replication is running. See
Section 18.5.4.2.4, “Cloning for Other Purposes”.
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.
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:
If unnecessary expulsions occur due to large messages, use
the system variable
group_replication_member_expel_timeout
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. From MySQL 8.0.21, an
additional 5 seconds is allowed by default.
Where possible, try and limit the size of your transactions
before they are handled by Group Replication. For example,
split up files used with LOAD DATA
into
smaller chunks.
Use the system variable
group_replication_transaction_size_limit
to specify a maximum transaction size that the group
accepts. In MySQL 8.0, this system variable defaults to a
maximum transaction size of 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.
Use the system variable
group_replication_compression_threshold
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
group_replication_transaction_size_limit
setting but exceeds the
group_replication_compression_threshold
setting. For more information, see
Section 18.7.4, “Message Compression”.
Use the system variable
group_replication_communication_max_message_size
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
group_replication_communication_max_message_size
limit. In order for a replication group to use
fragmentation, all group members must be at MySQL 8.0.16 or
above, and the Group Replication communication protocol
version in use by the group must allow fragmentation. For
more information, see
Section 18.7.5, “Message Fragmentation”.
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
replica_max_allowed_packet
or
slave_max_allowed_packet
system
variable, which have 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.