Message Compression Therefore, metrics acquired from all members are the basis for calculating the capacity of each member: if a member has a large queue (for certification or the applier thread), then the capacity to execute new transactions should be close to ones certified or applied in the last period. The lowest capacity of all the members in the group determines the real capacity of the group, while the number of local transactions determines how many members are writing to it, and, consequently, how many members should that available capacity be shared with. This means that every member has an established write quota based on the available capacity, in other words a number of transactions it can safely issue for the next period. The writer-quota is enforced by the throttling mechanism if the queue size of the certifier or the binary log applier exceeds a user-defined threshold. The quota is reduced by the number of transactions that were delayed in the last period, and then also further reduced by 10% to allow the queue that triggered the problem to reduce its size. In order to avoid large jumps in throughput once the queue size goes beyond the threshold, the throughput is only allowed to grow by the same 10% per period after that. The current throttling mechanism does not penalize transactions below quota, but delays finishing those transactions that exceed it until the end of the monitoring period. As a consequence, if the quota is very small for the write requests issued some transactions may have latencies close to the monitoring period. For messages sent between online group members, Group Replication enables message compression by default. Whether a specific message is compressed depends on the threshold that you configure using the  group_replication_compression_threshold  system variable. Messages that have a payload larger than the specified number of bytes are compressed. The default compression threshold is 1000000 bytes. You could use the following statements to increase the compression threshold to 2MB, for example: If you set  group_replication_compression_threshold  to zero, message compression is disabled. Group Replication uses the LZ4 compression algorithm to compress messages sent in the group. Note that the maximum supported input size for the LZ4 compression algorithm is 2113929216 bytes. This limit is lower than the maximum possible value for the  group_replication_compression_threshold system variable, which is matched to the maximum message size accepted by XCom. The LZ4 maximum input size is therefore a practical limit for message compression, and transactions above this size cannot be committed when message compression is enabled. With the LZ4 compression algorithm, do not set a value greater than 2113929216 bytes for  group_replication_compression_threshold . The value of  group_replication_compression_threshold  is not required by Group Replication to be the same on all group members. However, it is advisable to set the same value on all group members in order to avoid unnecessary rollback of transactions, failure of message delivery, or failure of message recovery. From MySQL 8.0.18, you can also configure compression for messages sent for distributed recovery by the method of state transfer from a donor’s binary log. Compression for these messages, which are sent from a donor already in the group to a joining member, is controlled separately using the  group_replication_recovery_compression_algorithms  and 3775 18.7.3 Message Compression STOP GROUP_REPLICATION; SET GLOBAL group_replication_compression_threshold = 2097152; START GROUP_REPLICATION;