Binary Log Compression is Safe since MySQL 8.0.34

This is a quick one.  My attention was recently brought (thanks Simon) on a relatively recent comment (25 Nov 2025) in Bug #103672 - Binlog compression transaction payload event exceeds max allowed packet :

The underlying server bug was fixed in 8.0.34 in BUG#33588473. The server now falls back to writing the transaction without compression, if the compressed size would exceed 1 GiB.

So Binary Log Transaction Compression is safe since MySQL 8.0.34.  But this also means that it is unsafe before, as also clearly mentioned in Bug #103672 :

It is true that an 8.0.33 server (or older) will produce a corrupted binary log and that replicas may have to recover from backup. It would be better to document this clearly and to advise to not use compression on 8.0.33 and older.

However, even if updating the documentation is mentioned in the above quote, my quick check did not find any reference to the risk of using binlog compression before 8.0.34 (including in the documentation of the global variable binlog_transaction_compression).  I thought this deserved wider knowledge, hence this post.

Row Deletion Jobs Done Right

I am continuing my blog post series on using indexes — or tables — as queues.  In this post, I cover Row Deletion Jobs (I do not call these purge jobs, to avoid confusion with the InnoDB Purge).  Such jobs are tempting to implement using an index, but this might be a wrong / suboptimal way.  I write about the right / better / cheaper way below, with cheaper meaning potentially significant savings on a Cloud bill !

Mind the InnoDB Purge on Queue / Row Deletion Job (else slow queries)

I am starting a blog post series on using indexes — or tables — as queues.  I had this series in the back of my mind for some time.  This started a few years back when I worked on optimizing a row deletion job (I do not call this a purge job, to avoid confusion with the InnoDB Purge).  Such jobs can be generalized to using indexes (or tables) as queues (this is fairly cryptic, I come back to this).  In this post, I explain why queries, which are expected to be fast, might become slow, and as the title of this post implies, it is related to the InnoDB Purge.

More than Flushing (also Caching) for innodb_flush_method, and Missing Release Candidate

Something changed in MySQL 8.4 related to caching, and it is easy to miss, so it deserves a post.  And a subject adjacent to this is the missing Release Candidate for MySQL 8.4 LTS, with my hope that the next LTS will have a Release Candidate, so I also cover this topic below.

Undo Log Truncation Bug in 8.0 leads to Data Corruption

I am upset about this one : I have a hard time not seeing this as negligence, and it starts to become a pattern...  So please forgive me if this post is not my most diplomatic, because I really think someone deserves a kick in the butt !  But what is all this about...

There is a MySQL bug, which can lead to data corruption, opened for 8.0 in September 2023, fixed in MySQL 8.4.0 (released in February 2024), AND STILL NOT FIXED IN MySQL 8.0.44 !  Luckily for some, it is fixed in Percona Server 8.0.39 (released in October 2024).  As usual, I start this post with some context before diving in the nitty-gritty details.