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.

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.