In this eleventh and final post of our series, we decode the GTID_TAGGED_LOG_EVENT — the event MySQL 8.4 introduced to carry user-defined tags alongside the classic UUID and GNO, and along the way meet the new mysql::serialization framework that encodes it.

Introduction

Back in Part 5 we deferred one event: the GTID_TAGGED_LOG_EVENT (event type 42, 0x2a). It was introduced in MySQL 8.4 to support tagged GTIDs, which extend the classic UUID:GNO form with an optional user-defined label:

55778904-0299-11f1-b1b8-4ef0c4956feb:mytag:3
└────────── SID (UUID) ───────────┘ └tag┘ └GNO

A tag …

In this tenth post of our series, we decode the ROTATE_EVENT — the event that closes a binary log file and tells every reader, replica or local, where to look next.

Introduction

The ROTATE_EVENT (event type 4, 0x04) is the bookmark MySQL leaves at the end of a binary log file. It carries two pieces of information:

• The name of the binary log file to read next.
• The starting position within that next file (always 4, the byte right after the 4-byte magic number from Part 2).

Together those two fields are enough for any reader — a replica's I/O thread, a mysqlbinlog invocation, a CDC tool — to seamlessly continue from one file into the next. …

In this ninth post of our series, we decode the XID_EVENT — the smallest event in the binary log, and the one that marks every transactional commit.

Introduction

Every DML transaction we've decoded so far ends the same way: with an XID_EVENT (event type 16, 0x10). At only 31 bytes on the wire, it carries a single piece of information — an 8-byte transaction identifier — but it does some of the heaviest lifting in MySQL replication. The XID_EVENT is what allows replication to be crash-safe with the default binlog_format = ROW and transaction-isolation = REPEATABLE-READ.

When the source commits a transaction that touches an XA-capable storage engine (in practice: InnoDB), it writes an XID_EVENT as the final event of the transaction in the binary log. The numeric XID …

In this eighth post of our series, we decode the three row events — WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT, and DELETE_ROWS_EVENT — that carry the actual row data for INSERT, UPDATE, and DELETE operations in row-based replication.

Introduction

In the previous posts, we decoded the events that set the stage for row-based replication: the GTID_LOG_EVENT identifies the transaction, the QUERY_EVENT opens it with BEGIN, and the TABLE_MAP_EVENT describes the table's schema. Now we finally arrive at the events that carry the actual data — the row events.

All three row events share the same base structure defined by the Rows_event class. The differences come down to which row images each event carries: …