Bug #114310 Master_compression_algorithm output is wrong
Submitted: 12 Mar 2024 4:14 Modified: 12 Mar 2024 18:33
Reporter: Demon Chen Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:8.0.33 OS:Any
Assigned to: CPU Architecture:Any

[12 Mar 2024 4:14] Demon Chen
Description:
https://dev.mysql.com/doc/refman/8.0/en/connection-compression-control.html says:
1.
If the replica_compressed_protocol or slave_compressed_protocol system variable is enabled, it takes precedence over MASTER_COMPRESSION_ALGORITHMS and connections to the source use zlib compression if both source and replica permit that algorithm. If replica_compressed_protocol or slave_compressed_protocol is disabled, the value of MASTER_COMPRESSION_ALGORITHMS applies.
2.
For source/replica replication connections, the configured compression algorithms and compression level are available from multiple sources:

The Performance Schema replication_connection_configuration table has COMPRESSION_ALGORITHMS and ZSTD_COMPRESSION_LEVEL columns.

The mysql.slave_master_info system table has Master_compression_algorithms and Master_zstd_compression_level columns. If the master.info file exists, it contains lines for those values as well.

now I set slave_compressed_protocol=on on both master and slave side, and execute stop slave;start slave;
Then the connection between master and slave should be compressed.

select * from slave_master_info \G
*************************** 1. row ***************************
                Number_of_lines: 32
                Master_log_name: binlog.000049
                 Master_log_pos: 31704724
                           Host: 172.21.16.12
                      User_name: tdsqlsys_repl
                  User_password: G1LCYqO6b%qUHxUM0q
                           Port: 4008
                  Connect_retry: 60
                    Enabled_ssl: 0
                         Ssl_ca: 
                     Ssl_capath: 
                       Ssl_cert: 
                     Ssl_cipher: 
                        Ssl_key: 
         Ssl_verify_server_cert: 0
                      Heartbeat: 1800
                           Bind: 
             Ignored_server_ids: 0
                           Uuid: 9f800d30-bf16-11ee-a37b-525400eb8e01
                    Retry_count: 86400
                        Ssl_crl: 
                    Ssl_crlpath: 
          Enabled_auto_position: 1
                   Channel_name: 
                    Tls_version: 
                Public_key_path: 
                 Get_public_key: 0
              Network_namespace: 
   Master_compression_algorithm: uncompressed
  Master_zstd_compression_level: 3
               Tls_ciphersuites: NULL
Source_connection_auto_failover: 0

select * from performance_schema.replication_connection_configuration \G
*************************** 1. row ***************************
                   CHANNEL_NAME: 
                           HOST: 172.21.16.12
                           PORT: 4008
                           USER: tdsqlsys_repl
              NETWORK_INTERFACE: 
                  AUTO_POSITION: 1
                    SSL_ALLOWED: NO
                    SSL_CA_FILE: 
                    SSL_CA_PATH: 
                SSL_CERTIFICATE: 
                     SSL_CIPHER: 
                        SSL_KEY: 
  SSL_VERIFY_SERVER_CERTIFICATE: NO
                   SSL_CRL_FILE: 
                   SSL_CRL_PATH: 
      CONNECTION_RETRY_INTERVAL: 60
         CONNECTION_RETRY_COUNT: 86400
             HEARTBEAT_INTERVAL: 1800.000
                    TLS_VERSION: 
                PUBLIC_KEY_PATH: 
                 GET_PUBLIC_KEY: NO
              NETWORK_NAMESPACE: 
          COMPRESSION_ALGORITHM: uncompressed
         ZSTD_COMPRESSION_LEVEL: 3
               TLS_CIPHERSUITES: NULL
SOURCE_CONNECTION_AUTO_FAILOVER: 0

it seems that performance_schema.replication_connection_configuration gets the data from slave_master_info.

the COMPRESSION_ALGORITHM still display uncompressed.
I think it should be output zlib.

How to repeat:
see above
[12 Mar 2024 18:33] MySQL Verification Team
Hi,

Thank you for your report. I can reproduce this as described but I am not 100% sure if this is a bug or expected behavior. Let's see what the replication team has to say about it. Thanks