Bug #114694 binlog_transaction_compression not effect on slave
Submitted: 19 Apr 2:24 Modified: 7 May 7:32
Reporter: xincheng xie Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:8.0.34 OS:Any (CentOS Linux release 7.6.1810 (Core) )
Assigned to: CPU Architecture:Any

[19 Apr 2:24] xincheng xie
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 .
[24 Apr 11:37] MySQL Verification Team
Hi,

I'm not sure I understand.

Do you have binlog_transaction_compression configured on master or on slave or on both?
[24 Apr 15:12] xincheng xie
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
[24 Apr 15:18] xincheng xie
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
[7 May 7:32] MySQL Verification Team
Hi,

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