Skip to content

do-release-upgrade Can Purge mysql-server-8.0 Without Installing a Replacement

The Problem

After a do-release-upgrade (e.g. 24.04 → 26.04.1), a host that was serving a MySQL-backed app can come back up with no MySQL server installed at all — mysql-server-8.0, mysql-client-8.0, and related versioned packages get purged during the release transition, but no replacement mysql-server metapackage gets installed to take their place. The app (WordPress, Castopod, etc.) then fails to connect, or — worse — the box reboots cleanly and looks healthy until something actually hits the database.

Why It's Inconsistent Across Hosts

Whether this bites you depends on a detail that's easy to miss: whether the version-independent mysql-server metapackage itself was already installed before the upgrade, not just the versioned package it resolves to.

  • If only mysql-server-8.0 was explicitly installed (the metapackage was never pulled in), the upgrade purges the versioned package and there is nothing left pointing apt at a replacement. Result: MySQL is gone post-upgrade.
  • If the mysql-server metapackage was already present, the upgrade's normal package resolution carries it through cleanly — it gets upgraded to whatever version the new release pulls in (e.g. 8.0 → 8.4), with zero manual intervention needed.

Confirmed directly on a 5-host fleet upgrade: two hosts (dcaprod, tttpod) needed a manual mysql-server reinstall after the OS upgrade; a third (majorlinux) upgraded MySQL completely cleanly with no gap at all, because majorlinux had the metapackage installed and the other two didn't.

Diagnosis

After the OS upgrade (and ideally before rebooting into it), check whether MySQL survived:

dpkg -l | grep -i mysql-server     # any mysql-server-* package present?
systemctl status mysql             # does the unit even exist?

If mysql-server (any version) is missing, the data is almost certainly still fine — a package purge removes binaries and unit files, not the data directory:

du -sh /var/lib/mysql              # data directory size — should be non-trivial if data exists
ls /var/lib/mysql/                 # look for your actual database name among the subdirs

Also confirm the app is actually configured to use a local MySQL instance before assuming this applies — check for DB_HOST=localhost / database.default.hostname="localhost" (or equivalent) in the app's own config, not a remote managed database.

Fix

sudo apt-get install -y mysql-server

This resolves to whatever MySQL version the new release ships (e.g. 8.4.x on 26.04.1) and starts cleanly against the existing, untouched data directory — no data loss, no need to restore from backup, because the purge never touched /var/lib/mysql in the first place.

Catch this before rebooting, not after. If you run this check and fix while still in the pre-reboot upgrade session, the fix is zero-downtime — the old MySQL process (if still running from before the purge) keeps serving until the reboot, and the new package is ready to start immediately after. Discovering the gap only after rebooting means the app is down for however long it takes to notice and fix it.

Real-World Example: MajorsHouse Fleet (2026-10-02)

  • teelia (first host upgraded): the gap was discovered reactively, post-reboot — the app actually went down for a few minutes before mysql-server was reinstalled. This cost was the whole reason the remaining hosts got checked proactively.
  • dcaprod, tttpod: having learned from teelia, dpkg -l | grep mysql-server was checked before rebooting on both. Both were missing the metapackage, both got apt-get install -y mysql-server run pre-reboot, resolving to 8.4.11 against the existing data directory. Zero downtime on either host.
  • majorlinux: checked the same way, found the mysql-server metapackage was already present pre-upgrade — it upgraded automatically with no intervention needed at all. This is what explained the inconsistency across hosts after the fact: it isn't random, it's a direct function of what was installed before the upgrade started.
  • tttpod specifically runs Castopod — confirmed castopod_db was present and intact in /var/lib/mysql both before and after the reinstall, and the site came back up correctly for an app other than WordPress, which is useful confirmation this isn't WordPress-specific.

Prevention

  • Before starting a do-release-upgrade on any MySQL-backed host, check now whether the mysql-server metapackage (not just the versioned package) is installed: apt-cache policy mysql-server — if it shows (none) installed while mysql-server-8.0 shows a real version, this host will hit the gap.
  • If so, consider apt-get install mysql-server before the OS upgrade even starts, so the metapackage carries the upgrade through automatically like it did on the clean host above.
  • Either way, always check dpkg -l | grep mysql-server before rebooting out of a release-upgrade session on any host that's supposed to be running MySQL — this is cheap insurance against a multi-minute outage for a one-line check.