Upgrading MySQL 8.4 LTS to 9.7 LTS: Path, Checks, and Rollback

MySQL 9.7.0 went GA on 21 April 2026 as the next long-term support (LTS) series after 8.4, and the 9.7 line reached 9.7.4 on 20 October 2026. For an 8.4 LTS server, this is the first major upgrade since 8.0. It also carries every removal from the 9.0 to 9.6 Innovation releases that an LTS-only shop never ran. Some of those removals stop a server from starting. A functional index or CHECK constraint that calls MD5() can end the upgrade with [ERROR] [MY-010020] Data Dictionary initialization failed. An account still on mysql_native_password can no longer log in, and a my.cnf line such as innodb_log_file_size names a variable that no longer exists. This guide covers the supported path, the changes to fix first, the upgrade checker run, a replica-first cutover, and how far you can roll back.

Scope and review date: November 2026. This post covers self-managed MySQL Community and Enterprise 8.4 LTS servers and asynchronous replication topologies moving to MySQL 9.7 LTS. Commands, defaults, and version numbers were checked against the MySQL 9.7 Reference Manual, the MySQL 9.0 to 9.7 release notes, and the MySQL Shell 26.10 release notes on 9 November 2026. They were not run in a lab, so rehearse them on staging. Managed services such as Amazon RDS publish their own version lists and upgrade tooling.

Which MySQL 9.7 release should you upgrade to?

The MySQL 9.7 release notes list 9.7.0 (21 April 2026), 9.7.1 (16 June), 9.7.2 (28 July), 9.7.3 (18 August), and 9.7.4 (20 October). On the same day as 9.7.4, the 8.4 series reached 8.4.13. Target 9.7.4 or the newest 9.7 patch on the day you upgrade. Patch your 8.4 servers to the newest 8.4 release first, since the manual recommends running the most recent release within a series for replication.

9.7.4 also fixes a regression from an earlier InnoDB deadlock fix. That fix made CREATE TABLE and ALTER TABLE row-size validation stricter, and some table definitions accepted by earlier LTS releases were rejected. 9.7.4 restores the old validation for most DDL. ALTER TABLE ... ALGORITHM=INSTANT keeps the stricter rule.

-- On every server, before and after the upgrade
SELECT @@version, @@version_comment, @@gtid_mode, @@enforce_gtid_consistency;

Interpretation: record the version and both GTID settings for every server in the topology. You will need the GTID values when you pin the configuration below.

9.7 is also the last series with sequential version numbers. The release model page says later releases use calendar versions, such as 26.7 for July 2026, on a separate Innovation track. An LTS series gets 5 years of Premier Support and 3 years of Extended Support, and features are removed only in its first release.

Can you upgrade to MySQL 9.7 directly from 8.0?

No. The 9.7 upgrade paths table says an LTS or bugfix series cannot be skipped. The 9.7 Yum repository guide gives this exact case: from 8.0, upgrade to MySQL 8.4 first, then to 9.7. MySQL 5.7 needs two hops before that (5.7 to 8.0 to 8.4). MySQL 8.0 reached end of life in April 2026, so that first hop is urgent on its own.

Three methods are supported for an LTS-to-next-LTS upgrade: in-place, logical dump and load, and replication. MySQL Clone is not one of them. The clone prerequisites require the same series, or consecutive LTS versions of 9.7.0 or higher. A 9.7 server cannot clone from an 8.4 donor, so you seed a new 9.7 replica from a backup or a logical dump.

What was removed or changed between MySQL 8.4 and 9.7?

The 9.7 "What Is New" page only describes changes since 9.6. For an 8.4 server, the real list is spread across the 9.0 to 9.6 release notes. These are the removals that break an upgrade or a running application:

Two more items need a test rather than a config change. The 9.2.0 notes fix a spatial index corruption bug and recommend dropping spatial indexes before the upgrade and re-creating them after. From 9.6.0, the SQL layer enforces foreign keys and runs cascades instead of InnoDB. Oracle calls it backward compatible, and innodb_native_foreign_keys restores InnoDB handling. If a CDC pipeline reads your binlog, replay cascading deletes on staging and compare what it receives.

Several defaults also changed, mostly in 9.5.0. They take effect the first time a server starts on 9.7, unless my.cnf sets them.

Tools that parse EXPLAIN output as a table will meet tree output. Ask for the old format explicitly instead of relying on the default:

EXPLAIN FORMAT=TRADITIONAL SELECT * FROM orders WHERE customer_id = 42;
-- or, per session, for a tool you cannot change yet
SET SESSION explain_format = 'TRADITIONAL';

Interpretation: both forms work on 8.4 and 9.7, so you can deploy the change before the upgrade.

Why can MD5() and SHA1() block a 9.7 upgrade?

In 9.6.0, MD5(), SHA1(), and SHA() left the server binary for the legacy hashing component. Where they sit decides how badly an 8.4 schema breaks. Bug #120948 tested an 8.4 to 9.7.1 in-place upgrade. With the function in a functional index or CHECK constraint, the server failed to start during the data dictionary upgrade. With it in a generated column, the server started but the table could not be used, even after installing the component.

-- Run on 8.4: schema objects that must change before the upgrade
SELECT 'column' AS kind, table_schema, table_name, column_name AS object_name
FROM information_schema.columns
WHERE table_schema NOT IN ('mysql', 'sys', 'performance_schema', 'information_schema')
  AND (LOWER(generation_expression) REGEXP '(md5|sha1|sha)\\('
       OR LOWER(column_default) REGEXP '(md5|sha1|sha)\\(')
UNION ALL
SELECT 'index', table_schema, table_name, index_name
FROM information_schema.statistics
WHERE LOWER(expression) REGEXP '(md5|sha1|sha)\\('
UNION ALL
SELECT 'check', constraint_schema, NULL, constraint_name
FROM information_schema.check_constraints
WHERE LOWER(check_clause) REGEXP '(md5|sha1|sha)\\(';

Interpretation: every row is an upgrade blocker. The pattern does not match sha2(, so rows that already use SHA2() do not appear.

Views, routines, triggers, and events are less severe. They fail when called, and installing the component restores the functions for them.

-- On 9.7, only if views or routines still call MD5() or SHA1()
INSTALL COMPONENT 'file://component_classic_hashing';
SELECT MD5('test');

Interpretation: the component's documented URN is file://component_classic_hashing. Under FIPS mode, its MD5() always returns NULL. Treat it as a bridge while you move to SHA2().

Moving a generated column to SHA2(expr, 256) changes the value and widens it from 32 to 64 hex characters, so update code that compares stored hashes. To keep the old value, the component page suggests filling the column from triggers instead.

How do you run util.checkForServerUpgrade() for 9.7?

Run the upgrade checker utility against every 8.4 server, replicas included. Use MySQL Shell 26.10.0 (20 October 2026) or later. Its release notes add a removedLegacyHashingFunctions check for the MD5() problem above and extend reservedKeywords to QUALIFY, TABLESAMPLE, LIBRARY, and EXTERNAL. Earlier Shell releases have no check for the MD5() removal, so they can return a clean report for a schema that the 9.7 upgrade will break.

Always set the target. Without targetVersion, the checker targets the server release that matches the Shell's own version. With Shell 26.10, that means a check against 26.10 Innovation, not 9.7.

// The same check from an interactive mysqlsh session (JavaScript mode)
util.checkForServerUpgrade('admin@db-replica-2:3306', {
  targetVersion: '9.7.4',
  configPath: '/etc/my.cnf',
  outputFormat: 'JSON'
})

Interpretation: JSON output is easier to diff between servers. The account needs PROCESS and SELECT. Checks that read the option file fail without configPath.

Which settings must you fix before the first 9.7 server starts?

Remove deleted variables and old plugins from my.cnf

# Option files accept dashes or underscores; this pattern matches both
grep -nE '(innodb.log.file.size|innodb.log.files.in.group|innodb.undo.tablespaces|temptable.use.mmap|replica.parallel.type|allow.local.lower.version.join|mysql.native.password|semisync_master|semisync_slave|rpl.semi.sync.master|rpl.semi.sync.slave)' \
  /etc/my.cnf /etc/my.cnf.d/*.cnf

Interpretation: any hit must change before 9.7 starts. Replace innodb_log_file_size and innodb_log_files_in_group with innodb_redo_log_capacity. Load semisync_source.so and semisync_replica.so, and rename the variables to rpl_semi_sync_source_* and rpl_semi_sync_replica_*. A loose- prefix hides an unknown option, so check those lines too.

SELECT plugin_name, plugin_status
FROM information_schema.plugins
WHERE plugin_name LIKE 'rpl_semi_sync%'
   OR plugin_name IN ('version_tokens', 'keyring_aws');

Interpretation: rpl_semi_sync_master, rpl_semi_sync_slave, and version_tokens do not exist on 9.7. keyring_aws still loads but is deprecated since 9.1.0 in favor of the AWS keyring component.

Move accounts off mysql_native_password

SELECT user, host FROM mysql.user WHERE plugin = 'mysql_native_password';

ALTER USER 'app_legacy'@'10.0.%'
  IDENTIFIED WITH caching_sha2_password BY 'new-strong-password';

Interpretation: the first query must return no rows before you upgrade. Test each client first: caching_sha2_password needs TLS or RSA key exchange for full authentication, and old connectors and proxies are the usual failures.

Pin the GTID settings and replication TLS

[mysqld]
# Copy the values each server runs today. Example for a topology without GTIDs:
gtid_mode = OFF
enforce_gtid_consistency = OFF

Interpretation: in the gtid_mode compatibility table, a replica at ON cannot replicate from a source at OFF. Without these lines, the first 9.7 replica starts at ON under an 8.4 source still at OFF. Move to GTIDs as a separate change, before or after the upgrade.

The SOURCE_SSL default also flips to 1. Any CHANGE REPLICATION SOURCE TO run on 9.7 without the option now expects TLS, so state SOURCE_SSL explicitly in switchover scripts and failover tooling.

In-place, logical, or replica-based: which method fits?

All three are supported from 8.4 to 9.7. Replicated setups usually combine them: replicas upgrade in place, then the source switches over.

# Logical route with MySQL Shell: dump 8.4, load into a fresh 9.7 server
mysqlsh admin@db-84:3306 -- util dump-instance /backup/db84-dump --threads=8
mysqlsh admin@db-97:3306 -- util load-dump /backup/db84-dump --threads=8

Interpretation: the dump records the binary log position or GTID set, so the new 9.7 server can replicate from 8.4 and catch up before the switchover. The logical route does not bypass the MD5() and authentication blockers.

How do you run a replica-first rolling upgrade to 9.7?

The replication topology upgrade procedure is fixed: upgrade every replica before the source, deepest replicas first, then switch over to an upgraded replica. Replication from an 8.4 source to a 9.7 replica is supported because 8.4 to 9.7 is a supported upgrade path. The reverse direction is generally not supported.

-- Step 7, on the 9.7 replica, with GTIDs: wait up to 60 s for the source's set
SELECT WAIT_FOR_EXECUTED_GTID_SET('<gtid_executed copied from the source>', 60);

Interpretation: a result of 0 means the replica has applied every transaction, and 1 means it timed out. Without GTIDs, compare the source's SHOW BINARY LOG STATUS with the replica's executed position in SHOW REPLICA STATUS.

How far can you roll back from MySQL 9.7 to 8.4?

Not in place. The 9.7 downgrade paths table allows only a logical dump and load or replication when moving from an LTS series to the previous one. It also says this is "only supported for rollback purposes", meaning no new server functionality has been applied to the data. The table's example row still reads 8.4 to 8.0, but the 9.7 to 8.4 rollback falls under the same rule. The Yum repository also does not support in-place downgrades.

That leaves three practical positions:

• Before step 8. Repoint to the 8.4 source and rebuild upgraded replicas from 8.4 copies.
• After step 8, with a reverse replica. An 8.4 server replicating from the 9.7 source can work with row-based logging and no 9.7-only DDL. The manual calls newer-to-older replication "generally not supported", so prove it on staging before you count on it.
• After step 8, without one. Dump the 9.7 data with util.dumpInstance(), load it into a fresh 8.4 server, and accept the outage for the load.

-- On 9.7.4 or later: the exact release this server runs
SELECT @@version, VERSION_WITH_UPDATE();

Interpretation: VERSION_WITH_UPDATE() was added in 9.7.4 and returns the four-part release identity; the server's mysql_upgrade_history record keeps each transition. A patch downgrade within 9.7, such as 9.7.4 to 9.7.3, is a separate case: within an LTS series, in-place downgrade is supported.

Frequently asked questions

Key takeaways

Plan your MySQL 9.7 upgrade with JusDB

JusDB's MySQL upgrade team can review your 8.4 servers against the 9.0 to 9.7 removals, run and interpret the upgrade checker across your topology, and write a replica-first runbook with a rollback plan your team has rehearsed on staging.

Bring your server versions, my.cnf files, replication layout, client and connector inventory, and the maintenance windows you have. Your team approves every production change.

Related reading

• MySQL 8.0 is EOL: upgrade checklist for 8.4 LTS
• MySQL 8.4 LTS production readiness checklist
• MySQL 8.4 GTID replication: setup, failover, and monitoring
• MySQL 9.7 Reference Manual: Upgrade Paths