The Binary Log of the  Transaction_payload_event , plus the bytes used for the event header. Note that compressed transaction payloads are sent as a single packet, rather than each event of the transaction being sent in an individual packet, as is the case when binary log transaction compression is not in use. For multithreaded workers, each transaction (including its GTID event and Transaction_payload_event ) is assigned to a worker thread. The worker thread decompresses the transaction payload and applies the individual events in it one by one. If an error is found applying any event within the  Transaction_payload_event , the complete transaction is reported to the co-ordinator as having failed. When  slave_parallel_type  is set to  DATABASE , all the databases affected by the transaction are mapped before the transaction is scheduled. The use of binary log transaction compression with the  DATABASE  policy can reduce parallelism compared to uncompressed transactions, which are mapped and scheduled for each event. For semisynchronous replication (see Section 17.4.10, “Semisynchronous Replication” ), the replica acknowledges the transaction when the complete  Transaction_payload_event  has been received. When binary log checksums are enabled (which is the default), the replication source server does not write checksums for individual events in a compressed transaction payload. Instead, a checksum is written for the complete  Transaction_payload_event , and indivdual checksums are written for any events that were not compressed, such as events relating to GTIDs. For the  SHOW BINLOG EVENTS  and  SHOW RELAYLOG EVENTS  statements, the Transaction_payload_event  is first printed as a single unit, then it is unpacked and each event inside it is printed. For operations that reference the end position of an event, such as  START REPLICA | SLAVE  with the  UNTIL  clause,  MASTER_POS_WAIT() , and  sql_slave_skip_counter , you must specify the end position of the compressed transaction payload (the  Transaction_payload_event ). When skipping events using  sql_slave_skip_counter , a compressed transaction payload is counted as a single counter value, so all the events inside it are skipped as a unit. MySQL Server releases that support binary log transaction compression can handle a mix of compressed and uncompressed transaction payloads. Combining Compressed and Uncompressed Transaction Payloads •The system variables relating to binary log transaction compression do not need to be set the same on all Group Replication group members, and are not replicated from sources to replicas in a replication topology. You can decide whether or not binary log transaction compression is appropriate for each MySQL Server instance that has a binary log. •If transaction compression is enabled then disabled on a server, compression is not applied to future transactions originated on that server, but transaction payloads that have been compressed can still be handled and displayed. •If transaction compression is specified for individual sessions by setting the session value of binlog_transaction_compression , the binary log can contain a mix of compressed and uncompressed transaction payloads. When a source in a replication topology and its replica both have binary log transaction compression enabled, the replica receives compressed transaction payloads and writes them compressed to its relay log. It decompresses the transaction payloads to apply the transactions, and then compresses them again after applying for writing to its binary log. Any downstream replicas receive the compressed transaction payloads. When a source in a replication topology has binary log transaction compression enabled but its replica does not, the replica receives compressed transaction payloads and writes them compressed to its 1061