MySQL upgrade services: from 5.7 and 8.0 to 8.4 LTS

MySQL upgrade paths: what is supported from 5.7 and 8.0

MySQL's long-term-support series cannot be skipped. The 8.4 documentation says so in its own example: to go from 5.7 to 8.4, upgrade to 8.0 first and then to 8.4. Where you start decides how many changes there are.

What breaks when a server goes to MySQL 8.4

Most 8.0 to 8.4 failures come from a short list of removals. They are cheap to find on a copy and expensive to find in a change window.

Accounts keep the authentication plugin stored for them, so a client that still depends on mysql_native_password fails at login after the upgrade, not during it. That is why account and driver inventory belongs in the rehearsal and not in the change window.

Upgrading a replicated estate without a long outage

MySQL's documentation upgrades a replication topology with a rolling scheme in which each server is moved by one of the supported single-server methods. Replicas go first and the source last, because a newer replica can replicate from an older source but not the other way round.

• Replicas first — One replica is upgraded, rejoined and watched for lag and errors before the next is touched.
• Switchover — Writes move to an upgraded replica in a planned, rehearsed step; applications reconnect through the proxy, DNS name or virtual IP they already use.
• Old source last — The old source is upgraded and rejoins as a replica. Until then it is the way back.
• Acceptance — A replica on the old version is kept until the agreed acceptance period ends, then retired.

How long writes are interrupted depends on your failover tooling and your applications' reconnect behaviour, not on MySQL alone. The plan states the exposure for each step, and the rehearsal measures it.

What waiting costs on RDS, Aurora and Azure

On a managed platform, staying on MySQL 8.0 after the provider's standard support ends is a monthly charge, not a free choice. The dates below are each provider's own.

On RDS the charge is per vCPU-hour, depends on the version, the Region and the years since standard support ended, applies to Multi-AZ standbys and replicas, and is not reduced by Reserved Instance discounts. AceMQ prints no rate because the providers publish and change their own. The comparison uses your instance count and the price list on the day it is made.

When staying on MySQL 8.0 is the right call

Not every 8.0 server should move this quarter. Three cases hold up:

• A short remaining life — The system is being retired within months, and the upgrade would cost more than the exposure.
• A certified dependency — A vendor product supports only 8.0 and the vendor has not published an 8.4 date.
• Compensating controls — The server is isolated and monitored, the risk is accepted in writing, and a date to revisit is set.

If you stay, you need patches: Oracle's own are available under its support terms, and OSSeva supplies patched builds of MySQL 5.7 and 8.0 Community. AceMQ's 24/7 support covers the version you run, and AceMQ does not sell patched builds.

Where this service is not a fit

• MariaDB and forks — MariaDB has its own versions and upgrade rules. This page covers Oracle MySQL Community and the managed MySQL services named above.
• Application code — We tell you which statements, drivers and settings to change. Your developers make the change, or we work with them.
• Provider-controlled steps — On RDS, Aurora and Azure the provider performs the engine upgrade. We plan, check and sequence it and do not replace the console.
• Moving off MySQL — A move to PostgreSQL is a different project, set out in our PostgreSQL practice, not an upgrade.
• No downtime guarantee — Rolling upgrades are designed to keep writes interrupted as briefly as the design allows. The plan states the exposure for each step.