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
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
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. A little history about this, Baron Schwartz, a MySQL Legend who is not involved in the community anymore, compared using the TIMESTAMP type to
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
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
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. My attention was brought to this via the now private Bug #120156: MySQL 8.0.39/8.0.42
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,
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
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
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
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. (if you are not interested in Caching and Flushing, you can jump directly to the section about Release Candidate)
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 (
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
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 ? Just to make sure we agree on the meaning of the graph above, let's describe it
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. (And this post is a way for me to see if Planet MySQL is still blocking posts mentioning MariaDB. This censorship /
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.
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 :
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
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. My
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
This post is a little long, please bear with me as after the intro, you can skip to the essential.In the last weeks / months, I have been working on understanding / improving MySQL startup with many tables. I already wrote three posts on the subject, they are listed below. In this post, I focus on describing the startup phase InnoDB Tablespace Duplicate Check (Duplicate Check for
In the last weeks / months, I have been working on understanding / improving MySQL startup with many tables. I already wrote two posts on the subject, the links are below. So far, I did not share what brought my attention to this, and it is the subject of this post. Also, and because it is related, I come back to the optimization / contribution I already made on
In the last weeks / months, I have been working on understanding / improving MySQL startup with many tables. I already wrote a post about my work (Faster MySQL Startup with Many Tables). In that post, I link to a bug report (Bug #115988 : Too Much Disk Read on Startup, penalizing deployments with many tables). In that bug report, I write, without much details, that the
I have been scratching my head about MySQL startup for some time. There is much to say about this, and many other posts will probably follow. For now, it is enough to know that with many tables (millions) the startup of MySQL 8.0+ (including 8.0, 8.4 and 9.0) is suboptimal (to say the least). With very little changes, I was able to speed it up, from 2:39 to 1:09 (1 minute and 9
When running tests, it is sometimes useful to slow down IOs to clearly show the impact of reading from the disk. Modern laptops and servers usually have fast local SSDs, and most cloud vendors provide, in addition to fast local disks, relatively fast network block devices (EBS for AWS and Persistent Disk for GCP). Even when using magnetic network block devices, IOs are not guaranteed