MySQL 8.0 to 8.4 LTS Upgrade Guide — Part 4: Rollback Strategy and Post-Upgrade Validation

Replication-Based Rollback (Recommended)

If you used the replication-based or rolling replica upgrade approach, rollback is straightforward:

1. Redirect application connections back to the original MySQL 8.0 source
2. The 8.0 source was untouched and continues to hold the authoritative data
3. Stop and decommission the 8.4 instance(s)

Logical Backup Rollback (In-Place Upgrade)

If the in-place upgrade fails, you must restore from the pre-upgrade backup:

1. Stop the failed MySQL 8.4 instance
2. Install a fresh MySQL 8.0.37 instance (on same or different server)
3. Restore the logical backup taken before the upgrade:

mysql -u root -p < full_backup_pre_upgrade.sql

4. If you need to recover writes between the backup time and the upgrade start, apply the 8.0-era binary logs:

mysqlbinlog --start-position=XXX binlog.000YYY | mysql -u root -p

5. Redirect application connections back to the 8.0 instance

Not Recommended Rollback Approaches

Reverse Replication (8.4 to 8.0)

Not officially supported by Oracle. Binary log format differences between major versions can cause replication failures or silent data corruption. Do not rely on this.

Physical Backup + Binary Log Replay

Technically possible but complex, error-prone, and not officially supported as a downgrade path. Carries significant risk of data inconsistency. Use logical backup restore instead.

Immediate Checks (First 30 Minutes)

After a successful upgrade, thorough validation ensures the system is healthy and production-ready.

Verify MySQL version:

SELECT VERSION();  -- Expected: 8.4.8

Review the error log for warnings or errors:

tail -500 /var/log/mysql/mysqld.log
grep -i 'error\|warning' /var/log/mysql/mysqld.log | tail -50

Verify all system tables upgraded successfully:

mysqlcheck -u root -p --all-databases --check

Verify all user accounts can authenticate:

SELECT user, host, plugin FROM mysql.user ORDER BY plugin;

Run the Upgrade Checker to confirm no remaining issues:

mysqlsh -- util checkForServerUpgrade root@localhost:3306 --target-version=8.4.8

Replication Validation (If Applicable)

Verify replication status:

SHOW REPLICA STATUS\G
-- Verify: Replica_IO_Running = Yes
-- Verify: Replica_SQL_Running = Yes
-- Verify: Seconds_Behind_Source = 0

Verify GTID consistency (if using GTID):

SELECT @@gtid_executed;

Test failover procedures in a controlled manner.

Refresh Optimizer Statistics

After a major version upgrade, the query optimizer may use different cost models. Refreshing statistics on key tables prevents query plan regressions:

-- For specific critical tables:
ANALYZE TABLE schema.important_table;

-- For all tables (run during low-traffic period):
mysqlcheck -u root -p --all-databases --analyze

Application and Performance Monitoring

• Run full application test suites / smoke tests
• Monitor query performance via slow query log and PMM dashboards
• Watch for optimizer plan changes causing performance regressions
• Verify all scheduled events and cron jobs execute correctly
• Test backup procedures (mysqldump, XtraBackup) on the 8.4 instance
• Validate PMM metrics collection from the 8.4 instance

Post-Upgrade Housekeeping

• Update monitoring dashboards and alerting rules for new metric names and thresholds
• Update all runbooks, SOPs, and documentation to reflect 8.4 command syntax
• Update all scripts using deprecated MASTER/SLAVE terminology
• Archive pre-upgrade backups per your retention policy
• Document the upgrade completion: date, duration, issues encountered, and resolutions
• Close the change ticket with a post-implementation review (PIR)

Part 4 Quick Checklist

• Rollback plan documented and tested
• Verify MySQL version: SELECT VERSION()
• Review error log for warnings
• Run mysqlcheck on all databases
• Verify all user accounts authenticate correctly
• Verify replication health (if applicable)
• Run ANALYZE TABLE on key tables
• Run application smoke tests
• Monitor performance for 24-48 hours
• Update monitoring, scripts, and documentation
• Archive pre-upgrade backups
• Close change ticket with PIR