MySQL 8.0.17 GTID Crash Safety Improvement

I have known for some times that there is an interesting improvement in MySQL 8.0.17 regarding GTID Crash Safety, but I have not had the time nor the need to look into it before.  When writing my last post (Understanding MySQL Replication "fatal error 1236": [...]), I saw something interesting related to this, and it is now time to cover this on my blog. From my point of view, this change is very interesting, but the documentation about it should be improved (and more), so there will be bug reports.  Let's explore all this.

Understanding MySQL Replication "fatal error 1236": "Replica has more GTIDs than the source has, using the source's SERVER_UUID"

This MySQL replication error — fatal error 1236 / Replica has more GTIDs than the source has, using the source's SERVER_UUID — shows the importance of thinking before acting.  I am glad a non-DBA Colleague asked me about it, because if he had restarted replication, it would have caused a much bigger mess.

Often, we are tempted — or pushed — to just restart things as quickly as possible.  In this specific case, restarting replication is unsafe as it leads to a replication breakage in the best case, and to silent data corruption in the worse case.  It is a great example of the following two advice : 1) do not make a bigger mess, do not failover, do not reboot, and 2) we cannot just bring the database back up, we have things to do first to make this safe.  Let's explore all these.

MySQL Best Practice : not using date / time types, nor ENUM

Today, I was reminded of a MySQL Best Practice, probably generalizable to all databases : using simple types, not complex types.  Such complex types to avoid include the date and time data types (including TIMESTAMP) and ENUM.  Let's see why.

Do not uselessly grant CREATE and ALTER TABLE

This lesson should have been learned with the CREATE TABLE of death, but it is worth a refresh.

Do not uselessly grant CREATE and ALTER TABLE

The reason I am posting this reminder is that another crashing bug related to DDL came to my attention.  This bug is only fixed in a recent version of MySQL (probably not affecting 5.6 and 5.7), so if you are running the latest 8.0 or 8.4, you should be fine.  I am not sharing the detail, I might in the future (like I did for the CREATE TABLE of death).  For triggering it, one need CREATE and ALTER TABLE.

The even more scary thing about this bug / crash is that it is also triggered by a rollback.  So after the crash, when MySQL attempts crash recovery, it crashes again when rolling-back uncommitted transaction.  There might still be a way to recover data with innodb_force_recovery, but it would compromise atomicity and is probably a big hurdle.  In this respect, in addition to being a crashing bug, it can be considered a data corruption bug.

A crash in rollback is non-trivial to recover

I gave a talk about a similar situation at SRECon: Autopsy of a Cascading Outage from a MySQL Crashing Bug.  The slides are self-contained and were appreciated.  If you face this or a similar situation, I hope you have a good backup and can replay binlogs (maybe it is also good time to test backups and binlog replay).

Inserting in Two Tables in a Single Round-Trip with JSON Duality Views in MySQL 9.7

A few months ago, I was asking myself how to insert in two tables in a single round-trip to the database.  I wanted to do that to optimize a process.  My optimization involved splitting a table in two, which would need inserting in two tables atomically.  The downside was changing an auto-commit INSERT to a transaction with two inserts, which was changing the shape of the workload from a single round-trip to the database to four: BEGIN, INSERT1, INSERT2, and COMMIT.  I had no satisfying solution to that, I now have one: JSON Duality Views in MySQL 9.7.

Symlinks are Unsafe since MySQL 8.0.39 (and maybe even before)

You read this right, symbolic links (symlinks) are unsafe in MySQL since at least 8.0.39.  As always, it is a little more complicated than that, but if you are using symbolic links and in certain conditions, you risk a crash.  I think it is important to raise awareness on this, hence this post.

Thanks AWS Open Source

I would like to thank AWS Open Source for their support.

For some time, I am maintaining Planet for the MySQL Community, a blog / news aggregator for the MySQL Community/Ecosystem.  I am also maintaining a similar aggregator for the Valkey Community.

Maintaining blog / news aggregators is not free.  It incurs hosting, domain registration, and other costs (in addition to time, which I am volunteering).  To cover these costs, I set up a Buy me a Coffee page, but I was barely breaking even.

A few weeks ago, I applied to the AWS Open Source Credits Program, and I recently received the good news that my application was accepted.  AWS Open Source allocated me two years worth of hosting credits.  Thanks AWS Open Source for supporting Planet for the MySQL Community and Planet for the Valkey Community.  Please show your appreciation by following AWS Open Source on X, and check the website of Open source at AWS, or the blog AWS Open Source.  Also a special mention to Kyle Davis for suggesting applying to the program, and to Miaolai Zhou processing  my application.

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.

Slack is a Suboptimal Feed Reader (RSS / Atom)

This is a MySQL Blog, why am I posting about Slack, Feed Readers, RSS and Atom ?  Because blog aggregators, which are usually consumed on their RSS or Atom interface via a Feed Reader, are an important knowledge sharing tool in the MySQL Community (and in other communities, see Valkey below).  I know some people are using Slack as their Feed Reader, and I recently realized Slack is a Suboptimal at this task.  This deserves a post.

Interesting Troubleshooting of a MySQL Crash : filling then freeing the disk

I recently troubleshoot an interesting MySQL crash, and I think it is worth sharing (with the related bugs).  MySQL crashed when the disk was full, you can see the free disk graph below.  The Y-axis is in the tens of GiB scale and the X-axis is in the hour scale.  Can you guess what happened ?

Interesting Binary Logging Optimization in MariaDB

As I wrote in a LinkedIn post, I am working on a blog post related to binary logging of big transactions.  I thought I would split this post in two, so here is the first part where I cover the recent binary logging optimization in MariaDB and its unspoken advantage.

Performance Regression in MySQL 8.0, Fixed in 8.4, Easy Workaround (innodb_doublewrite_pages)

While doing benchmarks on 5.7 and 8.0, I came across a performance regression in MySQL 8.0 over 5.7 and opened a bug (Bug #111353 : 3x Performance Regression from 5.7 to 8.0 on ALTER TABLE FORCE).  There has been recent activity on this bug, showing an easy workaround.  This, even if it is known since 16 July 2024, has not been talked about much, so this deserves a blog post.

Contrib RFC: Counters for Slow InnoDB Sync Reads

I just submitted a MySQL Contribution and I would like to gather feedback about it.  Depending on the received feedback, I might submit an updated contribution.  The contribution is Counters for Slow InnoDB Sync Reads, and its goal is to make MySQL easier to operate on “complex” IO subsystems (like network drives in the cloud).

The bug report / feature request Bug #117740 : Please consider adding Slow IO Counters contains all the details about the contribution and the problem this is solving, including what is a sync read.  If you prefer looking at a PR over a patch file, you can check the Contrib / RFC Fake PR : Bug #117740 - Counters for Slow InnoDB Sync Reads (and if you want to know what is a Fake PR, it is also detailed in there).  If you have thoughts or questions about this, feel free to comment below or in the Contrib Fake PR.

Thanks in advance for any feedback you might have : this will allow me to make the contribution and MySQL even better !

InnoDB Tablespace Duplicate Check Threads (and EBS Volumes for MySQL Startup with Many Tables)

In the last weeks / months, I have been working on understanding / improving MySQL startup with many tables.  I already wrote five posts on the subject, they are listed below.  In this post, I use the knowledge we gained in the previous two posts to show the interest of tuning InnoDB Tablespace Duplicate Check Threads, making startup 30% in one case (2:28 vs. 3:33) and 5% in another (5:33 vs. 5:53).

Problematic Improved Offline Mode Error in MySQL 9

I am writing this quick post to share what I think is a problematic new behavior of Offline Mode in MySQL 9.  Basically, the new default behavior in MySQL 9 is to write the username of the user which set offline_mode to ON.  I think this behavior has not been considered from a security point of view because it leaks a root username in the error message presented to the users.

The Light MySQL Startup Optimization on EBS Volumes

In the last weeks / months, I have been working on understanding / improving MySQL startup with many tables.  I already wrote four posts on the subject, they are listed below.  In this post, I use the system analysis of the previous post to revisit the light optimization on EBS volumes.  With this analysis, I am able to determine why the previous tests did not show improvements, and I am able to provide an example of a faster startup.