This is a follow-up for MySQL GTID tags and binlog events , but you don’t need to read that first. One of the recent innovations in MySQL was the addition of Tagged GTID’s. These tagged GTID’s take the format of <uuid>:<tag>:<transaction_id> . And this change means that the GTID_LOG_EVENT ’s in the binary logs needed to be changed. The MySQL team at Oracle decided to not change the existing format, but introduce a new event: GTID_TAGGED_LOG_EVENT . Initially I assumed that decoding the new event would me mostly identical to the original event, but with just a single field added. But this isn’t the case as Oracle MySQL deciced to use a new serialization format (Yes, more innovation) and use it for this new event. The new serialization format is documented here . Oracle MySQL did their best to document the library and the format, but I guess the target audience is people using this library to encode and decode the format and not people working on implementations in...

MySQL 8.4 and newer have extended the Global Transaction ID (GTID) functionality with a new “tag” option. Refresher on GTID A GTID is a unique ID that is assigned to a transaction. This is used if gtid_mode is set to ON . The benefit of this is that a transaction can be uniquely identified in a MySQL replication setup with multiple levels. Among others this makes it easier to refactor a replication tree as a MySQL replica knows which transactions it has seen and can use this to find the right position to start replicating from a new source. The format of GTIDs is documented here . Before GTID was used replication worked based on a file and offset (e.g. file= binlog.000001 ,offset= 4 ), which is unique to every server. A GTID without tag looks like this: 896e7882-18fe-11ef-ab88-22222d34d411:1 This is in the format of <server_uuid>:<txid> . The UUID of the server is in the server_uuid global variable and the txid is the transaction id, which is an increasing number....