MySQL Version Lock Policy for Production Stability

Pinning a database version stops a routine dnf update or apt upgrade from installing a release you haven't tested. That can protect a production server, but a pin left in place for too long becomes a risk of its own. This guide explains when to pin MySQL on your own server, how to do it on RHEL-family and Debian/Ubuntu systems, and why the once-popular "lock at 8.0.37" advice should be retired.

1. Why the 8.0.37 lock existed, and why it's obsolete

In July 2024, MySQL 8.0.38 (and 8.4.1 and 9.0.0) shipped with a bug that could crash mysqld on restart when a server had a very large number of tables, above about 10,000. Oracle withdrew those releases and published fixed ones, 8.0.39, 8.4.2 and 9.0.1, within weeks. Many administrators locked at 8.0.37 in the meantime, which was reasonable for a few weeks.

Two things have changed since:

• The bug is fixed. Any 8.0.39 or later release doesn't have it.
• MySQL 8.0 is end of life. Oracle ended support for the 8.0 series in April 2026. An 8.0.37 lock now means running a release that is two years behind on security fixes, with no further fixes coming for 8.0 at all.

A lock that made sense for a month becomes the bigger risk after that. The right move today is to move to a supported series, and to pin that instead.

2. When pinning is the right call

Pin for a clear reason and a limited time:

• a new release has a known regression that affects you, and you're waiting for the fix;
• you're about to change the major series (8.0 to 8.4) and want updates held until you have tested;
• an application vendor certifies only a specific series.

Don't pin because "updates are risky" in general. That stops security fixes along with everything else. Always write down why the pin exists and the date you'll review it.

3. Pin the series, not one patch release

Locking one exact patch release (8.0.37) blocks every later fix. A better pattern is to allow patch updates within a supported series and hold back only the jump to the next one:

• Choose the series in the repository. The MySQL yum and apt repository setup lets you enable one release series, such as 8.4 LTS. With only that series enabled, updates stay inside it.
• Lock with a wildcard when you want to hold patch updates too, for example while testing: lock 8.4.* rather than a single build.

4. How to pin on AlmaLinux, Rocky Linux and other RHEL-family systems

Install the versionlock plugin, then lock the MySQL packages that are installed:

sudo dnf install python3-dnf-plugin-versionlock
rpm -qa 'mysql-community-*'
sudo dnf versionlock add 'mysql-community-*'
sudo dnf versionlock list

versionlock add locks each matching package at the version currently installed. List the packages first so that you know exactly what you're holding.

To upgrade later, remove the lock, update, and lock again if you still need to:

sudo dnf versionlock delete 'mysql-community-*'
sudo dnf upgrade 'mysql-community-*'

If you installed MySQL from the operating system's own repositories rather than Oracle's, the package names differ (for example mysql-server). Lock whichever names rpm -qa | grep -i mysql shows.

5. How to pin on Ubuntu and Debian

The simplest hold uses apt-mark:

dpkg -l | grep -i mysql
sudo apt-mark hold mysql-server mysql-client mysql-common
apt-mark showhold

Release it with sudo apt-mark unhold and the same package names. For finer control, an APT preferences file can pin a version pattern:

# /etc/apt/preferences.d/mysql
Package: mysql-*
Pin: version 8.4.*
Pin-Priority: 1001

A priority above 1000 also allows a downgrade to the pinned version, so check apt-cache policy mysql-server after adding the file.

6. Moving off 8.0: upgrading to 8.4 LTS

8.4 is the current long-term support series. Plan the move rather than letting an update do it:

7. Review the pin every quarter

Put a date on it. At each review:

• read the release notes for the series you're on and the next one;
• check the end-of-life date of your series;
• test the latest patch release on a copy of your data;
• unlock, upgrade and re-lock, or remove the pin if you no longer need it.

A pin with no review date is how servers end up years out of date.

8. Where Domain India fits

• Shared hosting (cPanel, DirectAdmin): the database server is MariaDB, maintained by us. You don't manage versions; you use phpMyAdmin or connect as described in How to connect to the MySQL database. Port 3306 is closed from outside, so remote tools connect through an SSH tunnel (jailed SSH is available on request; ask support to enable it).
• VPS: you have full root access and choose your own database and version, so everything in this guide applies. A VPS is self-managed: you install, update and pin MySQL yourself. See VPS hosting.

If a MySQL dump from an 8.0 server fails to import on shared hosting with an unknown utf8mb4_0900_ai_ci collation, see Database troubleshooting; we recommend utf8mb4_unicode_ci.

Running your own database server? Compare plans on VPS hosting. For a site on shared hosting, the database is looked after for you; if something isn't working, open a ticket.