MySQL Patching Steps: Minor Version Upgrades on Linux, Windows, Containers and Amazon RDS

The short answer

To patch MySQL within a release series, such as 8.4.11 to 8.4.12, back up, stop the server, install the new packages and start it again on the same data directory. Since MySQL 8.0.16, the server performs the upgrade steps itself at startup: it upgrades the data dictionary and system tables, the sys schema and user schemas as needed. mysql_upgrade, deprecated since 8.0.16, is no longer part of the procedure. In a replicated topology, upgrade the replicas first and the source last.

The one step not to skip is the backup. MySQL's 8.4 manual describes restoring a backup taken before the upgrade as the supported way back, and RDS does not let you revert an upgrade at all.

What a MySQL patch release contains

For an LTS series such as 8.4 or 9.7, Oracle ships only necessary fixes and no removals, and supports in-place upgrades within the series. Oracle publishes MySQL security fixes on a fixed calendar: Critical Patch Updates on the third Tuesday of January, April, July and October, the next on 20 October 2026, and since May 2026 Critical Security Patch Updates in the months between. The current LTS releases are 8.4.12 and 9.7.3, both from 18 August 2026.

MySQL 8.0 is the exception. Oracle's last 8.0 release was 8.0.46 in April 2026, so there are no more community patches to apply. If you are still on 8.0, the patching question becomes an upgrade question; see MySQL 8.0 end of life and the MySQL 8.0 to 8.4 upgrade guide.

Before you patch

SELECT VERSION();

-- Uncommitted XA transactions must be resolved before the upgrade
XA RECOVER;

-- If you normally run with a cold shutdown (2), switch to fast or slow
SELECT @@innodb_fast_shutdown;
SET GLOBAL innodb_fast_shutdown = 1;

• Back up, including the mysql system schema, which holds the data dictionary.
• Read the release notes for every release between the one you run and the target, for behaviour changes and fixes that affect you.
• Resolve XA transactions with XA COMMIT or XA ROLLBACK if XA RECOVER returns any.
• Check innodb_fast_shutdown. If it is normally 2, set it to 1 (fast) or 0 (slow) before shutting down, as the manual's in-place upgrade steps require.
• Plan replica order. MySQL supports replication from an older source to a newer replica, not the other way round.

Linux: the MySQL APT repository (Debian and Ubuntu)

sudo apt-get update
sudo apt-get install mysql-server
mysql -e "SELECT VERSION();"

Two details from the MySQL documentation matter here. The MySQL server always restarts after an update by APT, so run the command inside your maintenance window. And a system-wide apt-get upgrade upgrades only the MySQL library and development packages; the server, client and other components need apt-get install. That is a common reason a host reports as patched while SELECT VERSION() shows the old release. List what is installed with dpkg -l | grep mysql | grep ii and update any other MySQL packages the same way.

Linux: the MySQL Yum repository (RHEL, Oracle Linux, Rocky, AlmaLinux)

# DNF-based systems
sudo dnf upgrade mysql-server
# Older Yum-based systems
sudo yum update mysql-server

mysql -e "SELECT VERSION();"

The server always restarts after an update by Yum as well. The repository file selects one release series at a time, so a patch update stays within the series you have enabled. Moving to another series means editing /etc/yum.repos.d/mysql-community.repo, and Oracle's advice is not to skip a series.

What happens when the new server starts

With the default --upgrade=AUTO, the server upgrades whatever it finds out of date in two steps: first the data dictionary, Performance Schema and INFORMATION_SCHEMA, then the remaining system tables, the sys schema and user schemas. Watch the error log during the first start. The option has three other values for special cases: NONE skips the upgrade and refuses to start if the data dictionary needs one, MINIMAL upgrades only the dictionary layer and leaves Group Replication unable to start, and FORCE checks every object in every schema, which makes startup slower. Leave it at AUTO unless you have a specific reason. The upgrade does not touch the contents of the time zone tables, so reload them separately if you depend on named time zones.

Windows: MSI or ZIP

MySQL Installer, which 8.0 used for installs and upgrades, is not available for MySQL 8.1 and later. For 8.4 and 9.7, the manual describes two routes:

• MSI. Download and run the latest MSI for your series, then run the bundled MySQL Configurator to finish configuration.
• ZIP archive. Stop the service, extract the new archive over the existing installation, and start the service again:

SC STOP MySQL84
rem extract the new ZIP over the existing installation directory
SC START MySQL84

Replace MySQL84 with your service name. As on Linux, the server upgrades what it needs when it starts.

Containers

With the official mysql image, pin the exact patch tag, for example mysql:8.4.12, so the version changes only when you decide. Patching is a new tag on the same data volume; the server runs its upgrade steps when the new container starts:

docker compose pull db
docker compose up -d db
docker compose exec db mysql -uroot -p -e "SELECT VERSION();"

On Kubernetes, change the image through the operator, which rolls it through the cluster. Our MySQL operator comparison covers the options.

Amazon RDS for MySQL

RDS applies minor upgrades automatically when Auto minor version upgrade is enabled and the backup retention period is greater than zero. The upgrade happens in your maintenance window once RDS has tested a release and designated it as the automatic upgrade target; it does not adopt every community release automatically. To upgrade yourself:

aws rds describe-db-engine-versions --engine mysql --engine-version 8.4.11 \
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
  --output table

aws rds modify-db-instance --db-instance-identifier mydb \
  --engine-version 8.4.12 --no-apply-immediately

Plan for downtime: a minor upgrade of a Multi-AZ DB instance deployment can take several minutes, while a Multi-AZ DB cluster upgrades readers one at a time and then fails over, which AWS says typically brings downtime to about 35 seconds. Upgrade read replicas before their source. RDS takes up to two snapshots before the upgrade, if backup retention is above zero, and after the upgrade you cannot revert; going back means restoring that snapshot as a new instance.

Replicated topologies

MySQL's replication upgrade procedure is the same for patch releases:

1. Upgrade each replica: shut down, update the packages, start, let the server upgrade itself, then START REPLICA. With replicas of replicas, start with the ones furthest from the source.
2. When only the source remains, switch over to one of the upgraded replicas, then upgrade the former source.

Never leave a newer source replicating to an older replica: the manual warns that an older replica may not be able to process transactions from a newer source.

Rollback: plan on the backup

MySQL's documentation is not consistent on this point. The 8.4 manual's downgrade page lists in-place downgrade within the 8.4 LTS series as supported, while its "Before You Begin" page says downgrading to a previous 8.4 release is not supported and the only alternative is restoring a backup taken before the upgrade. For 8.0, in-place downgrade within the series is supported only from 8.0.35 onwards. Given that, treat a tested pre-upgrade backup as the rollback plan, and an in-place downgrade as something to rehearse on a copy first, never as the primary option. On RDS the snapshot is the only way back.

Where OSSeva fits

OSSeva for MySQL supports MySQL 8.4 and 9.7 LTS and keeps 5.7 and 8.0 patched after Oracle's end of life, with signed builds of the Community Edition you already run, following each quarterly Critical Patch Update. A patched build stays on the same major version, data directory and configuration, so installing one follows the steps above: replace the packages and restart, replicas first. Our post on verifying signed database packages shows how to check a build before it is installed. OSSeva Operate patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High within 7 days, and runs rolling upgrades replica by replica. For how quickly PostgreSQL, MySQL, MariaDB and Valkey ship security fixes, see open source database CVE response times. MySQL sits under one contract with PostgreSQL, MariaDB, Redis, Valkey and Kafka, priced per cluster. Book a discovery call for a quote.

Frequently asked questions

What are the steps to patch MySQL on Linux?

Back up, resolve XA transactions, check innodb_fast_shutdown, then run apt-get install mysql-server or dnf upgrade mysql-server from the MySQL repository. The server restarts and upgrades itself. Confirm with SELECT VERSION().

Do I still need to run mysql_upgrade?

No. Since MySQL 8.0.16 the server performs those tasks at startup, and mysql_upgrade has been deprecated since then.

Why does apt-get upgrade not update the MySQL server?

MySQL's documentation notes that a system-wide apt-get upgrade updates only the MySQL library and development packages. Use apt-get install mysql-server to upgrade the server.

Can I roll back a MySQL patch upgrade?

Restore a backup taken before the upgrade; that is the route MySQL's documentation consistently supports. In-place downgrade within a series has conditions and conflicting documentation, so rehearse it before relying on it. On RDS, restore the pre-upgrade snapshot.

How does RDS apply MySQL minor version upgrades?

Automatically in the maintenance window, if auto minor version upgrade is on and backup retention is above zero, once RDS designates a release as the automatic target. Or manually with modify-db-instance. Upgrade read replicas first.

How do I patch MySQL 8.0 now that it is end of life?

Oracle publishes no more 8.0 releases, so either upgrade to 8.4 LTS or use a source of patched 8.0 builds while you plan the move.