Bug #114694 binlog_transaction_compression not effect on slave

Description:

HELLO,

Neither 5.7 Nor 8.0 ,include the 8.0.34,binlog_transaction_compression not effect on slave ,even if the master has opened the variable 'binlog_transaction_compression '。

How to repeat:
Just set global binlog_transaction_compression  =on

and next watch the table performance_schema.binary_log_transaction_compression_stats

you will see  the binlog on the slave never be compressed .

Hi,

I'm not sure I understand.

Do you have binlog_transaction_compression configured on master or on slave or on both?

yes ,i configured on both of master and slave ,
and The result is only effective on the master .
I draw the conclusion through the table performance_schema.binary_log_transaction_compression_stats

you can see that the relay log has been compressed ,but the binlog on the slave havent

mysql> select *from binary_log_transaction_compression_stats \G
*************************** 1. row ***************************
                            LOG_TYPE: BINARY
                    COMPRESSION_TYPE: NONE
                 TRANSACTION_COUNTER: 572237986
            COMPRESSED_BYTES_COUNTER: 1369785185610
          UNCOMPRESSED_BYTES_COUNTER: 1369785185610
              COMPRESSION_PERCENTAGE: 0
                FIRST_TRANSACTION_ID: e7a33628-63f3-11ed-823e-005056a996a5:6412742781
  FIRST_TRANSACTION_COMPRESSED_BYTES: 1438
FIRST_TRANSACTION_UNCOMPRESSED_BYTES: 1438
         FIRST_TRANSACTION_TIMESTAMP: 2024-03-27 17:46:43.945436
                 LAST_TRANSACTION_ID: e7a33628-63f3-11ed-823e-005056a996a5:6984980766
   LAST_TRANSACTION_COMPRESSED_BYTES: 4016
 LAST_TRANSACTION_UNCOMPRESSED_BYTES: 4016
          LAST_TRANSACTION_TIMESTAMP: 2024-04-24 23:07:55.232027
*************************** 2. row ***************************
                            LOG_TYPE: RELAY
                    COMPRESSION_TYPE: ZSTD
                 TRANSACTION_COUNTER: 572238159
            COMPRESSED_BYTES_COUNTER: 482102960301
          UNCOMPRESSED_BYTES_COUNTER: 1376504826536
              COMPRESSION_PERCENTAGE: 65
                FIRST_TRANSACTION_ID: e7a33628-63f3-11ed-823e-005056a996a5:6412742781
  FIRST_TRANSACTION_COMPRESSED_BYTES: 839
FIRST_TRANSACTION_UNCOMPRESSED_BYTES: 1452
         FIRST_TRANSACTION_TIMESTAMP: 2104-01-22 14:22:31.160152
                 LAST_TRANSACTION_ID: e7a33628-63f3-11ed-823e-005056a996a5:6984980946
   LAST_TRANSACTION_COMPRESSED_BYTES: 728
 LAST_TRANSACTION_UNCOMPRESSED_BYTES: 1847
          LAST_TRANSACTION_TIMESTAMP: 2104-10-30 19:54:24.365174
*************************** 3. row ***************************
                            LOG_TYPE: RELAY
                    COMPRESSION_TYPE: NONE
                 TRANSACTION_COUNTER: 7
            COMPRESSED_BYTES_COUNTER: 3677
          UNCOMPRESSED_BYTES_COUNTER: 3677
              COMPRESSION_PERCENTAGE: 0
                FIRST_TRANSACTION_ID: e7a33628-63f3-11ed-823e-005056a996a5:6666700724
  FIRST_TRANSACTION_COMPRESSED_BYTES: 905
FIRST_TRANSACTION_UNCOMPRESSED_BYTES: 905
         FIRST_TRANSACTION_TIMESTAMP: 2104-05-28 12:18:02.912914
                 LAST_TRANSACTION_ID: e7a33628-63f3-11ed-823e-005056a996a5:6785935524
   LAST_TRANSACTION_COMPRESSED_BYTES: 162
 LAST_TRANSACTION_UNCOMPRESSED_BYTES: 162
          LAST_TRANSACTION_TIMESTAMP: 2104-07-26 03:36:14.288387

Hi,

Thanks for the report, looks like there is something unclear here, let's see what the replication team has to say about it.