MySQL 8.4 First Peek

MySQL 8.4 has now been officially released, and this is a quick review of what is in the release notes. This is momentous as it is designated a Long-Term Support (LTS) release. Various 8.0 releases introduced material changes that impacted speed and stability, causing hair-pulling and swearing among those affected. Please note this is a first peek at the release notes, and comments in italics are mine and not reflective of my employer or colleagues.

How does LTS impact future releases?

The introduction of the LTS software means that MySQL 8.0.34+ will become a bugfix-only release. Innovation releases will likely happen quarterly, and a new long-term support version will be released roughly every two years. We have 8.4 until early 2026. Hopefully, those quarterly innovation releases will have enough new goodies to entertain us. But remember, it will take up to two years to get them into the mainstream LTS if we like them!

So, what has changed in the last six years?

The following points were gathered by reading the release notes and the 8.0 to 8.4 changes guide.

• MySQL native password has long been depreciated, but it is no longer loaded by default. However, it is still loadable for those who should have ditched it years ago. And yes, this is a security issue, so please upgrade already!
• The Innodb_flush_method has changed from fsync to ODIRECT on Linux. The innodb_log_buffersize has from 16 to 64 MiB. We will need side-by-side comparisons to see how this helps or hinders saving data. 
• The Clone PlugIn is more tolerant of allowing us to go between different point versions. Clone is handy, and this is a welcome change.
• GTIDs have been extended to allow groups of transactions to be processed. This should help speed processing.
• Mysqldump can now produce output for older versions of itself. This will be handy for those moving data to systems before 8.0.23 or 8.0.23 to 8.1 inclusive. How many of us will be dumping data from 8.4 to a much earlier version? This could be handy when needed.
• Histograms are automatically updated when ANALYZE TABLE is run. Good!
• And there is a new FLUSH_PRIVILEGES privilege to grant. It is time to upgrade that tattoo of MySQL privs.
• Using the terms MASTER and SLAVE in replication commands may finally be replaced by SOURCE and REPLICA. This has been in the works for many years, and hopefully, it will go for good—also, mysqlpump and mysql_upgrade head to the great bit bucket in the cloud.  This seems to have dragged on too long.
• And 143 bugs were fixed. Yea!

Want more details? See  https://docs.oracle.com/cd/E17952_01/mysql-8.4-en/mysql-nutshell.html and https://docs.oracle.com/cd/E17952_01/mysql-8.4-relnotes-en/mysql-8.4-relnotes-en.pdf

The old rule of MySQL upgrading

Many MySQL DBAs would wait a year or more after the initial release of a new version of a major MySQL release in hopes that the delay would allow bugs to be discovered and fixed before committing their data.  This was a cautious practice, but is it now out the window? One year from now, in April or May of 2025, we will be halfway through the expected lifecycle of MySQL 8.4. If this LTS release is stable, you will have another year of use before contemplating another upgrade to the next LTS release. This could be a good strategy for the risk-averse.

Does going to 8.4 make sense for anyone not directly impacted by one of the fixed bugs? Changing just for change’s sake is not a good idea if you want stability.  8.4 needs heavy testing and a careful eye on the bug list before it will be considered for production. Hopefully, fingers crossed, Oracle’s MySQL engineers have produced a rugged, durable, long-term version of their server, which is all the promised things. But we suspenders and belt type will want to see some track record before investing in a cutover. 

More on the way

I will test MySQL 8.4 in upcoming blogs and let you know. Plus, the hardworking engineers are working to add our Enterprise features, which are free, BTW, to the release of Percona Server for MySQL 8.4.