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....

In this post I will talk about release management with MySQL as example. Release management has to do with what to put in a release, how often to do a release, how to long to support a release and how to number or name the releases. The early years Today software is almost exclusively delivered over the internet, but this didn’t use to be the case. Software used to be delivered in a box that you had to buy at a physical store. These were often shrink wrapped and forced you to agree with the EULA by opening the box. The box then contained floppies, CD’s, DVD’s or any other suitable medium. There were multiple reasons why physical media were used, even when the internet arrived. One of the main limitations was bandwidth, this is also why FreeBSD, Linux, etc were sold on physical media. And one of the other reasons was that online payment wasn’t as ubiquitous as it is today. Then there were also ways of copy protection that relied on physical media and/or dongles. For operating systems...

This story starts with a pull request for go-mysql to allow setting the collation in auth handshake that I was reviewing. The reason why the author wanted to do this is to speedup the connection setup as he has a latency sensitive application and a lot of connection setups and tear downs. While looking at this I noticed that the collation would be stored in a single byte. However the list of supported collations shows collations with an ID that’s more than 255. mysql> SELECT MIN(ID),MAX(ID) FROM information_schema.collations; +---------+---------+ | MIN(ID) | MAX(ID) | +---------+---------+ | 1 | 323 | +---------+---------+ 1 row in set (0.00 sec) The protocol documentation for Protocol::HandshakeResponse41 says that the value sent here is only the lower 8-bits. So I was wondering how do other connectors send this to the server? Are the other 8-bits sent elsewhere in the protocol? So I used MySQL Connector/Python to try this out. import mysql.connector c = mysq...