Group replication requirements
The data must be stored in the InnoDB transaction storage engine. The transaction is executed in an optimistic manner and then checked for conflicts when it is committed. If there is a conflict, in order to maintain the consistency of the entire group, some transactions will be rolled back, so a transactional storage engine is required. In addition, InnoDB also provides some additional features to better manage and handle conflicts when operating with group replication. Using other storage engines (including temporary MEMORY storage engines) may cause group replication errors. You can prevent the use of other storage engines by setting the disabled_storage_engines system variable on the group members, for example: disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
Each table replicated by the group must have a primary key or an equivalent non-empty unique key. They are necessary as a unique identifier for each row in the table, which enables the system to determine which transactions have conflicts by accurately identifying the rows that have been modified by each transaction.
Network performance will affect the performance of the group, and network latency and network bandwidth will affect the performance and stability of group replication. Therefore, the MySQL server instances in group replication should be deployed in a cluster environment very close to each other, so that all group members always maintain two-way communication. If the server instance is blocked from sending and receiving messages (for example, restricted by a firewall), the member cannot run in the group, and group members (including problematic members) may not be able to report the correct membership status of the affected server instance. Starting from MySQL 8.0.14, you can use IPv4 or IPv6 network infrastructure, or a mixture of the two, for TCP communication between remote group replication servers.
Set --log-bin [= log_file_name] to activate the binary log. This option is enabled by default in MySQL 8. Like other MySQL replication methods, group replication needs to replicate the contents of the binary log, so the binary log needs to be turned on to run.
Set --log-slave-updates to log slave updates. The server needs to record the binary log applied by the replication application. The servers in the group need to record all transactions they receive and apply from the group. This is necessary because distributed recovery relies on the binary logs of the members of the group. Therefore, a copy of every transaction needs to exist on every server, even for transactions that are not started on the server itself. This option is enabled by default in MySQL 8.
Set --binlog-format = row to set the binary log to row format. Group replication relies on a row-based replication format to propagate changes consistently among group members. It relies on a row-based infrastructure to extract the necessary information to detect conflicts between concurrent transactions executed by different servers in the group.
Set --binlog-checksum = NONE to turn off binary log verification. Due to the design limitation of replication event checksums, group replication cannot use them, so they must be disabled.
Set --gtid-mode = ON to turn on the global transaction identifier. Group replication uses the global transaction identifier to accurately track the transactions that have been committed on each server instance, so that it can infer which server transactions may conflict with transactions that have been committed elsewhere.
Set --master-info-repository = TABLE and --relay-log-info-repository = TABLE to store the replicated information repository in the table. Replication applications need to write master database information and relay log metadata into the mysql.slave_master_info and mysql.slave_relay_log_info system tables. This ensures that the group replication plug-in has consistent replicability and transaction management of replication metadata. Starting from MySQL 8.0.2, these options default to TABLE, and starting from MySQL 8.0.3, the FILE setting is not recommended.
Set --transaction-write-set-extraction = XXHASH64, so that the server will also collect write sets when recording data lines to the binary log. The write set is based on the primary key of each row to uniquely identify the changed row and is used to detect transaction conflicts. This option is enabled by default in MySQL 8.
It is recommended to set slave_parallel_workers to a value greater than zero to enable multi-threaded replication applications on group members. Up to 1024 parallel replication application threads can be specified. Set slave_preserve_commit_order = 1 to ensure that the final commit of a parallel transaction is in the same order as the original transaction. This is required for group replication. It relies on all group members to receive and apply committed transactions in the same order to ensure data consistency for parallel transactions . slave_preserved_commit_order = 1 requires setting slave_parallel_type = LOGICAL_CLOCK, which specifies the strategy used to determine which transactions are allowed to be executed in parallel on the slave library. Setting slave_parallel_workers = 0 disables parallel replication and provides a single application thread for the slave library instead of the coordinator thread. With this setting, the slave_parallel_type and slave_preserve_commit_order options are invalid and ignored.
Group copy limit
The certification process does not consider gap locks. Unless the application relies on REPEATABLE READ semantics, MySQL recommends using the READ COMMITTED isolation level with group replication. InnoDB does not use gap locks in READ COMMITTED. It unifies the local conflict detection in InnoDB with the distributed conflict detection performed by group replication.化.
The authentication process does not consider table locks (LOCK TABLES and UNLOCK TABLES) or named locks (GET_LOCK)
Replication does not support the SERIALIZABLE isolation level. Setting the transaction isolation level to SERIALIZABLE will make the group refuse to commit the transaction.
When using multi-primary mode, concurrent data definition statements (DDL) and data manipulation statements (DML) for the same object but executed on different servers are not supported.
Multi-primary mode does not support tables with multi-level foreign key dependencies, especially tables with defined CASCADING foreign key constraints. MySQL recommends setting group_replication_enforce_update_everywhere_checks = ON in multi-primary mode group replication to avoid undetected conflicts.
When group replication is running in multi-primary mode, the SELECT .. FOR UPDATE statement may cause a deadlock.
Global replication filters cannot be used on MySQL server instances configured for group replication.
If a single transaction is too large to replicate messages between group members over the network within 5 seconds, the member may be suspected of failure and be removed from the group. Due to memory allocation issues, large transactions may also slow down the system. To avoid these problems, use the following mitigation measures:
Try to limit the transaction size as much as possible. For example, split the file used with LOAD DATA into smaller chunks.
Use the system variable group_replication_transaction_size_limit to specify the maximum transaction size that the group receives. Transactions exceeding this size will be rolled back and will not be sent to the group. In MySQL 8.0, the default value of this system variable is 150,000,000 bytes (approximately 143 MB).
Starting from MySQL 8.0.13, the system variable group_replication_member_expel_timeout can be used to allow more time before the suspected failed member is removed. It can be extended by up to one hour after the initial 5 second detection period.
Starting from MySQL 8.0.16, large messages are automatically segmented, which means that large messages will not trigger the 5-second detection period that arouses suspicion, unless there are other network problems at this time. In order for the replication group to use segmentation, all group members must be in MySQL 8.0.16 or higher, and the group replication communication protocol version used by the group must allow segmentation. If the MySQL version does not support message segmentation, you can use the system variable group_replication_communication_max_message_size to adjust the maximum message size. The default value is 10485760 bytes (10 MB), or you can turn off segmentation by specifying a zero value.