MySQL 9.1 Release Notes
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:
STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold = 2097152;
START GROUP_REPLICATION;
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.
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
group_replication_recovery_zstd_compression_level
system variables. For more information, see
Section 6.2.8, “Connection Compression Control”.
Binary log transaction compression, enabled by the
binlog_transaction_compression
system variable, can also be used to save bandwidth. The
transaction payloads remain compressed when they are transferred
between group members. If you use binary log transaction
compression in combination with Group Replication's message
compression, message compression has less opportunity to act on
the data, but can still compress headers and those events and
transaction payloads that are uncompressed. For more information
on binary log transaction compression, see
Section 7.4.4.5, “Binary Log Transaction Compression”.
Compression for messages sent in the group happens at the group
communication engine level, before the data is handed over to the
group communication thread, so it takes place within the context
of the mysql user session thread. If the
message payload size exceeds the threshold set by
group_replication_compression_threshold,
the transaction payload is compressed before being sent out to the
group, and decompressed when it is received. Upon receiving a
message, the member checks the message envelope to verify whether
it is compressed or not. If needed, then the member decompresses
the transaction, before delivering it to the upper layer. This
process is shown in the following figure.
When network bandwidth is a bottleneck, message compression can provide up to 30-40% throughput improvement at the group communication level. This is especially important within the context of large groups of servers under load. The TCP peer-to-peer nature of the interconnections between N participants in the group makes the sender send the same amount of data N times. Furthermore, binary logs are likely to exhibit a high compression ratio. This makes compression a compelling feature for Group Replication workloads that contain large transactions.