Free audit

View Audit Scope
MySQL5.7 & 8.0 EOL to 8.4 LTS and 9.7 LTS upgrades

MySQL 5.7 & 8.0 to 8.4 LTS Upgrade Services

JusDB engineers minimal-downtime in-engine upgrades from MySQL 5.7 (EOL October 2023) and MySQL 8.0 (Sustaining Support since April 2026) to MySQL 8.4 LTS and 9.7 LTS. We run MySQL Shell util.checkForServerUpgrade() audits, migrate mysql_native_password accounts, promote GTID sidecar replicas or RDS Blue/Green environments, and eliminate AWS RDS Extended Support surcharges.

The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance.

  • NDA before access
  • MySQL Shell pre-upgrade audit
  • Reverse-GTID rollback gate

MySQL version lifecycle status

Select your current release

MySQL 5.7 (End of Life Oct 2023)

RDS Year 3 surcharge

Community patches ended in October 2023. On Amazon RDS and Aurora, remaining 5.7 instances pay Year 3 Extended Support ($0.200 per vCPU-hour).

Physical upgrades cannot skip 8.0: we step 5.7 -> 8.0.46 -> 8.4 LTS via sidecar replicas or use MySQL Shell parallel dump/load straight to 8.4 LTS.

Calculate your RDS Extended Support fee

Lifecycle dates verified against the Oracle MySQL Lifecycle Policy and AWS RDS Extended Support pricing schedule.

Key EOL & billing dates
MySQL 5.7 EOL: Oct 2023 · MySQL 8.0 EOL: Apr 2026 · RDS 8.0 Extended Support: Aug 2026
Primary LTS targets
MySQL 8.4 LTS (Premier Support to Apr 2029) & MySQL 9.7 LTS (Premier Support to Apr 2031)
Cutover architectures
Sidecar GTID replica promotion, AWS RDS Blue/Green Deployments, and MySQL Shell parallel dump/load

Selected clients

  • Innoviti
  • Blitz
  • Freecharge
  • Nango
  • Recochain
  • Screen Facts
  • Nexora
  • WeCredit

Why in-place upgrades fail

What breaks between MySQL 5.7, 8.0, and 8.4 LTS?

Six engine-level breaking changes cause unassisted MySQL 5.7 and 8.0 upgrades to fail at startup or degrade production traffic: disabled mysql_native_password accounts, removed my.cnf variables, utf8mb4_0900_ai_ci collation drift, removed SLAVE statements, the 5.7 two-step dictionary rule, and optimizer cost shifts.

MySQL 5.7 and 8.0 to 8.4 LTS upgrade blockers, what happens at cutover, and how JusDB engineers remediate each breaking change
Breaking change / blockerWhat is usually happeningWhere we start
mysql_native_password removalApplication workers and replicas fail authentication on 8.4 LTSMySQL 8.4 LTS disables mysql_native_password by default and MySQL 9.x removes it completely, while also removing the default_authentication_plugin variable.Audit mysql.user for legacy password hashes, verify client driver TLS/RSA handshake support, and migrate accounts to caching_sha2_password before cutover.
Removed my.cnf variables & query_cachemysqld refuses to start after binary upgradeMySQL 8.0 removed query_cache_size and query_cache_type, and MySQL 8.4 LTS removes innodb_log_file_size, expire_logs_days, and table/relay-log repository directives.Run MySQL Shell util.checkForServerUpgrade() against your my.cnf or RDS parameter group and map redo sizing to innodb_redo_log_capacity.
utf8mb3 to utf8mb4_0900_ai_ciImplicit charset conversions disable B-tree indexes on JOINsLegacy 5.7 tables using utf8mb3_general_ci or latin1 joined against new 8.0/8.4 tables using utf8mb4_0900_ai_ci trigger per-row collation conversions and CPU spikes.Scan information_schema.columns for mixed character sets and normalize foreign-key and join columns online using gh-ost before switching traffic.
Removed SLAVE replication syntaxMonitoring exporters and failover scripts break on 8.4 LTSMySQL 8.4 LTS removes SHOW SLAVE STATUS, START SLAVE, STOP SLAVE, RESET SLAVE, and CHANGE MASTER TO statements across SQL and administrative scripts.Update Prometheus mysqld_exporter, Datadog checks, Orchestrator hooks, and runbooks to SHOW REPLICA STATUS and CHANGE REPLICATION SOURCE TO.
5.7 two-step dictionary ruleDirect physical upgrade from 5.7 to 8.4 LTS is blockedMySQL 5.7 uses file-based .frm metadata, and MySQL 8.4 LTS removed the 5.7-to-8.0 transactional InnoDB Data Dictionary conversion code path.Execute a chained sidecar replica hop (5.7 -> 8.0.46 -> 8.4 LTS) or run a parallel logical dump and load via MySQL Shell util.dumpInstance().
Reserved keywords & optimizer shiftsUnquoted column names fail and borderline query plans regressNew reserved words (MANUAL, PARALLEL, QUALIFY, TABLESAMPLE in 8.4; LATERAL, RANK, GROUPS, SYSTEM in 8.0) break unquoted SQL, while cost-model updates flip plans.Scan all views, triggers, and query digests with util.checkForServerUpgrade() and replay production SELECT digests with EXPLAIN ANALYZE on an 8.4 staging clone.

Technical scope

What does a MySQL 8.4 LTS upgrade engagement cover?

We handle every technical gate from the initial MySQL Shell readiness audit and authentication plugin migration to sidecar GTID replica seeding, query plan benchmarking, and guarded cutover.

  • MySQL Shell 25-point compatibility audit

    Before touching any production node, we run read-only compatibility checks against a replica to catalog every schema, auth, and parameter blocker.

    • Full JSON report from util.checkForServerUpgrade() for 8.0, 8.4 LTS, or 9.7 LTS
    • Line-by-line review of my.cnf or cloud DB parameter groups for removed directives

    MySQL Shell · util.checkForServerUpgrade()

  • Authentication plugin and driver hardening

    We transition application, monitoring, and replication accounts off deprecated password plugins without breaking active connection pools.

    • Staged account migration from mysql_native_password to caching_sha2_password
    • Verification of JDBC, Go, Python, Node.js, and PHP connector TLS/RSA handshakes

    caching_sha2_password · mysql.user · ProxySQL

  • Collation normalization and online DDL

    We eliminate utf8mb3, latin1, and MyISAM technical debt prior to cutover so your upgraded cluster runs cleanly on InnoDB and utf8mb4.

    • Non-blocking conversion of legacy MyISAM tables and utf8mb3 columns
    • Foreign-key collation alignment to prevent post-upgrade index bypasses

    gh-ost · utf8mb4_0900_ai_ci · ALGORITHM=INPLACE

  • Sidecar GTID replica and RDS Blue/Green seeding

    We never run an in-place binary upgrade on your live primary. Instead, we build and upgrade a side-by-side replica while production stays online.

    • Physical replica seeding via Percona XtraBackup, Clone plugin, or RDS Blue/Green
    • Two-step 5.7 -> 8.0 -> 8.4 LTS replica chaining or MySQL Shell parallel dump/load

    Percona XtraBackup · RDS Blue/Green · GTID auto-positioning

  • Query plan regression testing and checksum parity

    We replay your production query digests against the upgraded 8.4 LTS candidate and verify mathematical data parity before scheduling cutover.

    • EXPLAIN ANALYZE comparison of top 100 query digests between 5.7/8.0 and 8.4 LTS
    • Chunk-level CRC verification across all tables with pt-table-checksum

    pt-table-checksum · pt-query-digest · EXPLAIN ANALYZE

    Explore MySQL performance tuning
  • Guarded promotion with reverse-GTID rollback

    We switch traffic in seconds via ProxySQL, MySQL Router, or RDS switchover while streaming reverse replication back to the old primary for instant fallback.

    • Write fencing with super_read_only=ON and zero-lag GTID handoff
    • Live reverse GTID replication channel back to the standby 8.0 primary

    ProxySQL · MySQL Router · Reverse GTID replication

FinOps & version compatibility matrix

How much does AWS RDS Extended Support cost vs. upgrading to MySQL 8.4 LTS?

AWS RDS and Aurora Extended Support bills $0.100 per vCPU-hour in Years 1–2 and $0.200 per vCPU-hour in Year 3 ($876 to $1,752 per vCPU per year). Estimate your fleet surcharge below and compare breaking changes across MySQL 5.7, 8.0, 8.4 LTS, and 9.x.

Interactive AWS RDS / Aurora Extended Support Surcharge Estimator

Calculate Your Annual MySQL 5.7 & 8.0 Extended Support Surcharge

Amazon RDS and Aurora bill Extended Support per provisioned vCPU-hour across every primary, Multi-AZ standby, and read replica instance still running MySQL 5.7 or MySQL 8.0. Upgrading to MySQL 8.4 LTS eliminates this surcharge.

$0.100 per vCPU-hour (US East / EU Ireland baseline rate for Year 1 & Year 2 after standard support ended July 2026)

32 vCPUs
2 (large)16 (4xlarge)64 (16xlarge)128
3 nodes
1 node3 (Multi-AZ + Replica)1020 nodes
Total Fleet vCPUs Billed:96 vCPUs × 730 hrs/mo
Estimated Monthly Extended Support Surcharge
$7,008 / month
Annual Extended Support Penalty (Pure Surcharge)
$84,096 / year
Upgrading to MySQL 8.4 LTS reduces this surcharge to $0/year through April 2029 (Oracle Premier Support) and July 2029+ on AWS RDS.

MySQL 5.7 EOL → 8.0 (Sustaining Apr 2026) → 8.4 LTS → 9.x breaking-changes matrix

Comparison of support status, authentication plugins, collations, redo log configuration, and replication syntax across MySQL 5.7, 8.0, 8.4 LTS, and 9.x
Engine dimensionMySQL 5.7 (EOL)MySQL 8.0 (Sustaining Apr 2026)MySQL 8.4 LTS (Target)MySQL 9.7 LTS / 9.x
Support Status & Cloud BillingEOL Oct 2023. AWS RDS Year 3 Extended Support ($0.200 / vCPU-hr).EOL Apr 2026 (final 8.0.46). AWS RDS Extended Support since Aug 2026 ($0.100 / vCPU-hr).Active LTS through Apr 2029 (Extended to Apr 2032). $0 Extended Support surcharge.9.7 LTS GA Apr 2026 (Premier to Apr 2031). Requires upgrading from 8.4 LTS first.
Authentication Pluginmysql_native_password default; caching_sha2_password unavailable.caching_sha2_password default; mysql_native_password enabled but deprecated.mysql_native_password disabled by default; default_authentication_plugin variable removed.mysql_native_password plugin removed completely from server binary.
Character Set & Collationlatin1 default; 3-byte utf8 (utf8mb3) alias standard.utf8mb4 with utf8mb4_0900_ai_ci default; utf8mb3 deprecated.utf8mb4_0900_ai_ci enforced on new objects; mixed utf8mb3/utf8mb4 joins defeat indexes.Strict utf8mb4 standard across system tables and stored routines.
Redo Log & Query Cachequery_cache_type / query_cache_size present; innodb_log_file_size used.Query cache removed completely; innodb_redo_log_capacity introduced in 8.0.30.innodb_log_file_size and innodb_log_files_in_group removed; innodb_redo_log_capacity required.Dynamic innodb_redo_log_capacity and modern adaptive flushing only.
Replication & Reserved WordsFile-based master.info / relay-log.info defaults; legacy SLAVE syntax.TABLE repositories default; REPLICA syntax added alongside deprecated SLAVE aliases.SHOW SLAVE STATUS / START SLAVE / CHANGE MASTER TO removed; MANUAL, PARALLEL, QUALIFY reserved.GTID and REPLICA syntax mandatory; Vector data type and updated JSON functions.

Interactive upgrade architecture

How sidecar GTID replica promotion avoids in-place outages

Step through our three-stage upgrade topology to see how we audit compatibility, upgrade a sidecar replica while production serves traffic, and keep your existing primary synchronized for instant rollback.

Side-by-side MySQL 8.0 to 8.4 LTS replica-promotion cutover

Select a stage to inspect query routing, data dictionary state, and reverse-GTID rollback readiness.

Application & ProxySQL / Router / RDS endpoint

Application reads and writes stay on the existing MySQL 5.7 or 8.0 cluster while we run util.checkForServerUpgrade() and seed the 8.4 LTS sidecar.

8.0 Primary online · Live traffic unaffected
  • MySQL 8.0 Primary

    Continues serving live application traffic undisturbed

    ONLINE · Primary R/W

  • Read Replica (Audit Source)

    Runs util.checkForServerUpgrade() & Percona XtraBackup stream

    Read-only · Snapshot source

  • MySQL 8.4 LTS Sidecar

    Seeded from backup, upgraded in-place off-line, joined via GTID

    Upgrading dictionary · Read-only

Instead of upgrading your live primary in place (which locks tables for 20 to 90 minutes with no fast rollback), we upgrade an isolated sidecar clone or RDS Blue/Green green environment while production runs normally.

Representative upgrade runbook

What our MySQL Shell pre-upgrade check and promotion script look like

Every upgrade engagement begins with a read-only MySQL Shell audit report and culminates in a rehearsed GTID switchover script with reverse replication.

Example pre-upgrade audit & cutover specimen (MySQL 8.0.36 → 8.4.3 LTS)Sample deliverable

Pre-Flight Audit · 25 Checks Run

14 legacy auth accounts and 4 removed my.cnf directives remediated before cutover

Running util.checkForServerUpgrade() against the customer's read replica flagged 14 microservice accounts still using mysql_native_password plus innodb_log_file_size and default_authentication_plugin in my.cnf. We remediated both in staging, verified zero query plan regressions on an 8.4 LTS sidecar, and promoted the replica in 14 seconds.

Startup blockers cleared18 → 0
Write switchover pause14 seconds

1. Read-only MySQL Shell 8.4 LTS compatibility audit & auth check

Bash & SQL · Pre-Upgrade Audit

# Run Oracle's 25+ point pre-upgrade verification against a read replica
mysqlsh readonly_auditor@10.0.1.25:3306 --js -e "
  util.checkForServerUpgrade(null, {
    targetVersion: '8.4.3',
    configPath: '/etc/mysql/my.cnf',
    outputFormat: 'JSON'
  });
" > /tmp/mysql_84_upgrade_audit.json

-- Audit accounts that must migrate off mysql_native_password before 8.4 LTS
SELECT user, host, plugin, account_locked
FROM mysql.user
WHERE plugin = 'mysql_native_password';

2. Sidecar GTID promotion & reverse-replication rollback gate

SQL · Sidecar Promotion & Rollback

-- 1. On 8.0 primary: fence writes and capture final GTID set
SET GLOBAL super_read_only = ON;
SELECT @@GLOBAL.gtid_executed AS final_80_gtid;

-- 2. On 8.4 LTS sidecar: confirm GTID catch-up and promote to Primary
SELECT WAIT_FOR_EXECUTED_GTID_SET('4a92bc11-82ef-11ee-b9d1-0242ac120002:1-19402811', 10);
STOP REPLICA;
SET GLOBAL super_read_only = OFF;

-- 3. On former 8.0 primary: start reverse GTID replication from 8.4 LTS
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'mysql84-sidecar.internal',
  SOURCE_AUTO_POSITION = 1;
START REPLICA;

Ways to work together

Choose a fixed-scope 8.4 LTS upgrade, post-EOL support, or cloud migration

Exit AWS RDS Extended Support with a rehearsed upgrade project, or cover your remaining 5.7 and 8.0 instances under a support agreement while we stage the move.

Fixed-scope upgrade projectRecommended

MySQL 5.7 & 8.0 to 8.4 LTS Upgrade Engineering

We own the MySQL Shell compatibility audit, auth plugin and charset remediation, sidecar GTID replica or RDS Blue/Green build, staging dress rehearsal, and production cutover.

  1. 1. Modify live primary20–90 min outage during dictionary upgrade
  2. 2. Startup crash riskRemoved 8.4 variables abort mysqld boot
  3. 3. No fast rollbackDowngrade blocked; requires full restore
While you plan the upgrade

24x7 Post-EOL MySQL 5.7 & 8.0 Support

Need operational cover for MySQL 5.7 or 8.0 while application teams remediate legacy queries and drivers? We support EOL versions under your service agreement.

Post-EOL coverage under your service agreement:

  • 15-minute P1 initial-response target with 24x7 on-call coverage
  • Crash recovery, deadlock triage, and replication stabilization
  • Staged upgrade roadmap to MySQL 8.4 LTS or 9.7 LTS
Cross-engine or cloud move

Heterogeneous & Cloud MySQL Migration

Combining your MySQL 8.4 LTS upgrade with a move from EC2/on-prem to Amazon RDS, Aurora, Cloud SQL, or Azure Flexible Server? We run both in one replication cutover.

Combined platform + version modernization:

  • On-prem or EC2 to RDS, Aurora, Cloud SQL, or Azure Flexible Server
  • Percona Server and MariaDB to Oracle MySQL 8.4 LTS
  • MySQL 8.4 parameter group and InnoDB buffer pool tuning

For procurement and security

NDA first, read-only pre-checks, and rehearsed rollback gates

We run every pre-upgrade check read-only against a replica or parameter export first, and we rehearse the full promotion and failback sequence in staging before touching production.Raguraman, Engineering Manager · Allen D, Lead Database SRE
  • Mutual NDA
  • MySQL Shell JSON audit
  • Staging dress rehearsal
  • Reverse-GTID rollback
  • NDA before access

    Signed before any diagnostic access. No credentials are required for the initial scoping call.

  • Written compatibility report

    Every removed variable, auth plugin, charset mismatch, and reserved word documented with its exact fix.

  • Least-privilege accounts

    Read-only audit credentials over your VPN or bastion host, with full session logging.

  • Runbooks your team keeps

    Your team keeps the my.cnf / parameter group diffs, cutover scripts, and rollback procedures. Meet the JusDB team.

JusDB's security practices are aligned with ISO 27001 and SOC 2 Type II, and JusDB is pursuing both certifications (see Terms, section 12). Read the stated status.

Technical FAQ

MySQL 5.7 & 8.0 to 8.4 LTS upgrade questions

Answers on MySQL 8.0 EOL dates, AWS RDS Extended Support billing, mysql_native_password removal, two-step 5.7 upgrades, and reverse-replication rollback.

Still have a question?

Ask it on a scoping call. No production access needed.

Book a 30-min scoping call (opens Google Calendar in a new tab)

When did MySQL 8.0 reach End of Life (EOL) and when does AWS RDS Extended Support start?

Oracle MySQL 8.0 reached community and Premier Support End of Life in April 2026 (with 8.0.46 as the final release). On Amazon RDS for MySQL, standard support for MySQL 8.0 ended on July 31, 2026, automatically enrolling remaining 8.0 instances into paid AWS RDS Extended Support billed per vCPU-hour.

Can we upgrade directly from MySQL 5.7 to MySQL 8.4 LTS in a single step?

No. Oracle MySQL does not support skipping a major LTS release series during an in-place or physical binary data directory upgrade. A MySQL 5.7 database must either step through MySQL 8.0 (5.7 to 8.0.46 to 8.4 LTS) so the InnoDB data dictionary upgrades cleanly, or use a logical parallel dump via MySQL Shell util.dumpInstance() loaded into a fresh MySQL 8.4 LTS instance.

Why do applications fail to authenticate after upgrading from MySQL 8.0 to MySQL 8.4 LTS?

MySQL 8.0 deprecated the legacy mysql_native_password plugin, MySQL 8.4 LTS disables mysql_native_password by default (and removes the default_authentication_plugin system variable), and MySQL 9.x removes it completely. Before upgrading to 8.4 LTS, all application accounts and replication users must be migrated to caching_sha2_password and client drivers verified for SHA-256 TLS or RSA handshakes.

How does JusDB achieve minimal-downtime cutovers during a MySQL 8.0 to 8.4 LTS upgrade?

Rather than running an in-place binary upgrade on your active primary, which locks tables and leaves no fast rollback path, we provision a side-by-side MySQL 8.4 LTS replica (or AWS RDS Blue/Green deployment) seeded via Percona XtraBackup or storage snapshot, synchronize live traffic via GTID auto-positioned replication, verify row parity with pt-table-checksum, and switch traffic via ProxySQL or MySQL Router in seconds.

How do we roll back safely if an application query regresses on MySQL 8.4 LTS?

Before promoting the MySQL 8.4 LTS replica to primary, we configure reverse GTID replication from the new 8.4 LTS node back to the existing MySQL 8.0 primary (kept fenced in super_read_only=ON). If an unexpected optimizer plan regression appears after cutover, we can repoint traffic back to the MySQL 8.0 node within seconds without losing post-cutover transactions.

Should we upgrade to MySQL 8.4 LTS or MySQL 9.7 LTS?

For production OLTP estates currently on MySQL 5.7 or 8.0, MySQL 8.4 LTS is the required first Long-Term Support target, offering Oracle Premier Support through April 2029 and Extended Support through April 2032, plus broad compatibility across AWS RDS, Aurora, Google Cloud SQL, Azure Flexible Server, and Percona Server 8.4. Once on 8.4 LTS, teams can adopt MySQL 9.7 LTS on their own schedule.

What happens to utf8mb3 columns and latin1 collations during an 8.4 LTS upgrade?

MySQL 8.0 and 8.4 LTS deprecate utf8mb3 (the legacy 3-byte alias for utf8) in favor of 4-byte utf8mb4 with the utf8mb4_0900_ai_ci default collation. Mixing utf8mb3 and utf8mb4 columns across JOIN predicates or foreign keys causes implicit charset conversion that defeats B-tree index usage. We audit and normalize character sets via gh-ost or pt-online-schema-change before cutover.

Which my.cnf configuration parameters were removed in MySQL 8.4 LTS?

MySQL 8.4 LTS removes numerous deprecated 5.7 and 8.0 variables that prevent mysqld from starting if left in my.cnf, including default_authentication_plugin, innodb_log_file_size, innodb_log_files_in_group (replaced by innodb_redo_log_capacity), expire_logs_days (replaced by binlog_expire_logs_seconds), master_info_repository, relay_log_info_repository, and legacy SLAVE replication statements.

Next step

Stop paying Extended Support fees for MySQL 5.7 and 8.0

Share your MySQL version, instance count, and hosting platform. The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance, subject to availability: mutual NDA before read-only access, a prioritized report within one week after access is ready, and no obligation.

NDA before access · MySQL Shell pre-check · reverse-GTID rollback

Explore all MySQL database services

Need a different MySQL service? Browse our complete offerings.