Bug #101262 performance_schema.binary_log_transaction_compression_stats timestamps
Submitted: 21 Oct 8:57 Modified: 21 Oct 9:21
Reporter: Simon Mudd (OCA) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:8.0.21 OS:Any
Assigned to: CPU Architecture:Any

[21 Oct 8:57] Simon Mudd
Description:
Also seen in 8.0.22 (shown below):

While a minor issue the timestamp shown for relay logs looks broken (can't be in the future). binlog stats look fine:

root@myhost [performance_schema]> select * from binary_log_transaction_compression_stats;
+----------+------------------+---------------------+--------------------------+----------------------------+------------------------+-------------------------------------------------+------------------------------------+--------------------------------------+-----------------------------+-------------------------------------------------+-----------------------------------+-------------------------------------+----------------------------+
| LOG_TYPE | COMPRESSION_TYPE | TRANSACTION_COUNTER | COMPRESSED_BYTES_COUNTER | UNCOMPRESSED_BYTES_COUNTER | COMPRESSION_PERCENTAGE | FIRST_TRANSACTION_ID                            | FIRST_TRANSACTION_COMPRESSED_BYTES | FIRST_TRANSACTION_UNCOMPRESSED_BYTES | FIRST_TRANSACTION_TIMESTAMP | LAST_TRANSACTION_ID                             | LAST_TRANSACTION_COMPRESSED_BYTES | LAST_TRANSACTION_UNCOMPRESSED_BYTES | LAST_TRANSACTION_TIMESTAMP |
+----------+------------------+---------------------+--------------------------+----------------------------+------------------------+-------------------------------------------------+------------------------------------+--------------------------------------+-----------------------------+-------------------------------------------------+-----------------------------------+-------------------------------------+----------------------------+
| BINARY   | NONE             |               17159 |                713977376 |                  713977376 |                      0 | aaa5cd90-0b78-11ea-83c0-e4434b389ba8:5938995738 |                            1032035 |                              1032035 | 2020-10-21 10:46:49.081824  | aaa5cd90-0b78-11ea-83c0-e4434b389ba8:5939012896 |                               616 |                                 616 | 2020-10-21 10:47:31.406079 |
| RELAY    | NONE             |               17159 |                715784112 |                  715784112 |                      0 | aaa5cd90-0b78-11ea-83c0-e4434b389ba8:5938995738 |                            1081083 |                              1081083 | 2069-09-30 22:23:15.866619  | aaa5cd90-0b78-11ea-83c0-e4434b389ba8:5939012896 |                               640 |                                 640 | 2069-09-30 22:30:26.054077 |
+----------+------------------+---------------------+--------------------------+----------------------------+------------------------+-------------------------------------------------+------------------------------------+--------------------------------------+-----------------------------+-------------------------------------------------+-----------------------------------+-------------------------------------+----------------------------+
2 rows in set (0.00 sec)

root@myhost [performance_schema]> select @@version;
+-----------+
| @@version |
+-----------+
| 8.0.22    |
+-----------+
1 row in set (0.00 sec)

Note: the timestamp in 2069!

This does not seem to cause any issues but the timestamp is clearly wrong.

How to repeat:
check the table on a server running 8.0.21+
I'm not sure under what circumstances this is triggered but even with binlog compression disabled this shows up:

root@myhost [(none)]> show global variables like 'binlog_transaction_%';
+--------------------------------------------+----------+
| Variable_name                              | Value    |
+--------------------------------------------+----------+
| binlog_transaction_compression             | OFF      |
| binlog_transaction_compression_level_zstd  | 3        |
| binlog_transaction_dependency_history_size | 25000    |
| binlog_transaction_dependency_tracking     | WRITESET |
+--------------------------------------------+----------+
4 rows in set (0.00 sec)

Suggested fix:
Fix the timestamp to show correct values.
[21 Oct 9:21] MySQL Verification Team
Hello Simon,

Thank you for the report and feedback.
Verifying for now as my colleague Ronan already verified internally.

regards,
Umesh