Bug #114736 performance_schema.binary_log_transaction_compression_stats with wrong timestamp
Submitted: 23 Apr 2024 7:54 Modified: 25 Apr 2024 9:02
Reporter: phoenix Zhang (OCA) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Group Replication Severity:S3 (Non-critical)
Version:8.0.32, 8.0.36 OS:Any
Assigned to: CPU Architecture:Any

[23 Apr 2024 7:54] phoenix Zhang
Description:
When start group_replication cluster, the TRANSACTION_TIMESTAMP (both first and last) in performance_schema.binary_log_transaction_compression_stats may return an unexpected value

How to repeat:
1. mysql-test/mtr group_replication --start

2. connect 13000:
set global group_replication_bootstrap_group=on;
set persist group_replication_group_name='aabbccdd-aabb-aabb-aabb-aabbccddee11', persist group_replication_group_seeds='127.0.0.1:33065,127.0.0.1:33066', persist group_replication_start_on_boot=ON, persist group_replication_local_address='127.0.0.1:33066'; CHANGE MASTER TO MASTER_USER='root'  FOR CHANNEL 'group_replication_recovery';
start group_replication;

3. connect 13002:
set persist group_replication_group_name='aabbccdd-aabb-aabb-aabb-aabbccddee11', persist group_replication_group_seeds='127.0.0.1:33065,127.0.0.1:33066', persist group_replication_start_on_boot=ON, persist group_replication_local_address='127.0.0.1:33065'; CHANGE MASTER TO MASTER_USER='root'  FOR CHANNEL 'group_replication_recovery';
start group_replication;

4. query from 13002, wrong timestamp at 2104-10-17
mysql> select * from performance_schema.binary_log_transaction_compression_stats\G
*************************** 1. row ***************************
                            LOG_TYPE: BINARY
                    COMPRESSION_TYPE: NONE
                 TRANSACTION_COUNTER: 2
            COMPRESSED_BYTES_COUNTER: 506
          UNCOMPRESSED_BYTES_COUNTER: 506
              COMPRESSION_PERCENTAGE: 0
                FIRST_TRANSACTION_ID: aabbccdd-aabb-aabb-aabb-aabbccddee11:1
  FIRST_TRANSACTION_COMPRESSED_BYTES: 233
FIRST_TRANSACTION_UNCOMPRESSED_BYTES: 233
         FIRST_TRANSACTION_TIMESTAMP: 2024-04-23 10:48:39.927012
                 LAST_TRANSACTION_ID: aabbccdd-aabb-aabb-aabb-aabbccddee11:2
   LAST_TRANSACTION_COMPRESSED_BYTES: 273
 LAST_TRANSACTION_UNCOMPRESSED_BYTES: 273
          LAST_TRANSACTION_TIMESTAMP: 2024-04-23 10:48:39.929170
*************************** 2. row ***************************
                            LOG_TYPE: RELAY
                    COMPRESSION_TYPE: NONE
                 TRANSACTION_COUNTER: 3
            COMPRESSED_BYTES_COUNTER: 449
          UNCOMPRESSED_BYTES_COUNTER: 449
              COMPRESSION_PERCENTAGE: 0
                FIRST_TRANSACTION_ID: aabbccdd-aabb-aabb-aabb-aabbccddee11:1
  FIRST_TRANSACTION_COMPRESSED_BYTES: 245
FIRST_TRANSACTION_UNCOMPRESSED_BYTES: 245
         FIRST_TRANSACTION_TIMESTAMP: 2104-10-17 13:41:51.255447
                 LAST_TRANSACTION_ID: aabbccdd-aabb-aabb-aabb-aabbccddee11:2
   LAST_TRANSACTION_COMPRESSED_BYTES: 18446744073709551535
 LAST_TRANSACTION_UNCOMPRESSED_BYTES: 18446744073709551535
          LAST_TRANSACTION_TIMESTAMP: 2104-10-17 13:41:51.796938
2 rows in set (0.00 sec)
[25 Apr 2024 9:02] MySQL Verification Team
Hello phoenix Zhang!

Thank you for the report and test case

regards,
Umesh