Group Replication Limitations • 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 Cloning for Other Purposes. Limit on Group Size Limits on Transaction Size •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. 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: 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. 3720