The latest from the MySQL community

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

This article is also available in Chinese: 中文版. Browse all English articles.

Since MySQL 5.6, the MySQL replication team has been working to reduce replication lag. The first step was schema-level parallel application of the binlog, but schema-level parallelism only helps when writes are spread across many databases; in the common case, where most write traffic hits a single database, it provides almost no parallelism. MySQL 5.7 then introduced the Commit-Order parallel-replay strategy, which depends on how many transactions run concurrently on the primary: the replica can replay quickly only when the primary is highly concurrent. When concurrency on the primary is low, the replica still replays slowly and lag builds up. To fix that, MySQL 5.7 also …

This article is also available in Chinese: 中文版. Browse all English articles.

Large transactions are a notorious problem in MySQL: they cause not only replication lag but also stability problems. A previous article, MySQL Large Transaction Commit Optimization, covered the problems a large transaction causes at commit time and the optimizations we made in AliSQL. This article looks at the problems a large transaction causes during semi-synchronous replication, and how AliSQL solves them.

In MySQL Large Transaction Commit …

Introduction Replication performance depends on every stage in the pipeline, from the source database to transport and ultimately to commit on the replica. On the replica side, much of that performance comes down to how efficiently changes are read, scheduled, and applied under real operational pressure. In practice, that directly affects steady-state lag, backlog recovery […]

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

MySQL replication has been around forever, and yet… people still manage to set it up in ways that break at the worst possible moment. Even in 2025, you can get burned by tiny schema differences, missing primary keys, or one forgotten config flag. I’ve seen replicas drift so far out of sync they might as well live in a different universe.

This guide covers the practical best practices—the stuff real DBAs use every day to keep replication stable, predictable, and boring. (Boring is a compliment in database land.)

Always Use GTIDs. Yes, Always.

GTID-based replication is one of those features that people resist turning on, and then once they do, they never want to go back.

Why GTIDs?

• Failover become sane
• Reparenting replicas stops being a headache
• Missing transactions are easy to detect

Your my.cnf should absolutely include:

Copy Copied!

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

Used to be that replication lag was as simple as Seconds_Behind_Master (renamed to Seconds_Behind_Source). But with multi-threaded replication (MTR) this is no longer the case. It’s time to relearn replication lag monitoring using Performance Schema tables.

With multi-threaded replication (MTR), a replica can commit transactions in the same order as the source, or not. This is determined by sysvar replica_preserve_commit_order (RPCO). As of MySQL v8.0.27 (released October 2021) it’s ON by default, but it was OFF by default for several years prior. In either case, it’s relatively new compared to 20+ years of single-threaded replication for which commit order was not an issue or option. But with MTR, it’s important to understand the affects of RPCO, especially with respect to the focus of this three-part series: replication lag.