MySQL 8.0 → 8.4 LTS upgrade (in-place)

Upgrades an installed MySQL 8.0 to 8.4 LTS on the same server (in-place): single server, source + replicas (replicas first, source last) or InnoDB Cluster (Router → Shell → metadata → secondaries one by one → primary last). Includes the util.checkForServerUpgrade pre-check on every server, the variables removed in 8.4 and mysql_native_password disabled by default, a fallback point with a cold copy, verification, and a runbook for falling back to 8.0. Downgrade is not supported, so the only way back is the pre-upgrade copy. To migrate by moving to new servers (dump/load), use the "Migrate to another server" mode of the logical backup guide.

Topology: 1 server, source + replicas, or InnoDB Cluster (3+ members + MySQL Router servers)

Before you start

• The server(s) run the latest MySQL 8.0 minor release (8.0.4x), installed from the official MySQL repo. A direct upgrade from 8.0 to 8.4 is supported; a direct upgrade from 5.7 to 8.4 is not supported (go to 8.0 first).
• There is free space under … equal to the data directory + binlog size (for the cold copy).
• There is a recent successful backup (XtraBackup 8.0 or mysqldump) and a restore test. After the upgrade you must switch to XtraBackup 8.4 (the 8.0 release cannot back up an 8.4 server).
• Support for MySQL 8.4 and caching_sha2_password in the application and the client drivers (JDBC, PHP mysqlnd, Python…) has been verified in a test environment.
• The maintenance window is approved…; read traffic may drop because the replicas are upgraded one at a time, and there is a write outage while the source is upgraded….
• The binlog retention on the source is longer than the replica upgrade time (binlogs that the stopped replicas still need must not be purged).
• The cluster is healthy: all members ONLINE, single-primary mode; the first member in the form is the current primary. Do not start the upgrade while there is a RECOVERING member or an OK_PARTIAL / OK_NO_TOLERANCE status.
• The cluster admin account … can connect to all members on port … and its password is known (MySQL Shell asks for it on every connection).
• On the Router servers, MySQL Router is installed from the official MySQL repo and runs as the systemd service (mysqlrouter). If application traffic comes through several Routers, the Routers are upgraded one at a time.
• The application connects only through Router (an application that connects directly to a member name cannot write when the primary role changes).

Phases of the guide

• Pre-check — Current state · Add the 8.4 repo and install MySQL Shell 8.4 · Run the Upgrade Checker · Search the configuration for removed variables · Migrate the mysql_native_password accounts
• InnoDB Cluster pre-check — Record the cluster status and the Routers · Check whether a metadata upgrade is needed (dryRun)
• Metadata upgrade — Run dba.upgradeMetadata()
• Preparing for the primary change — Verify that the secondaries are on 8.4 and ONLINE
• InnoDB Cluster final check — Check the extended cluster status · Hand the primary role back to the first member
• After the upgrade — Check replication (…) · Move XtraBackup to 8.4 and take a new full backup · Migrate the mysql_native_password accounts (permanent fix) · Deciding when to delete the fallback copy
• Fallback (back to 8.0) — Fallback: stop 8.4, move the data directory aside · Fallback: stop 8.4, move the data directory aside · Fallback: return to the 8.0 software · Fallback: return to the 8.0 software · Fallback: restore the cold copy · Fallback: restore the cold copy …