MySQL 8.0 to 8.4 LTS Upgrade Guide — Part 5: Change Management, Troubleshooting, and Complete Checklist

A major version upgrade is not just a technical task. Proper change management ensures organizational readiness and reduces risk. This final part covers the operational planning, common pitfalls you'll encounter, and the complete 41-item checklist to track your progress.

Change Ticket Requirements

Your change ticket (ServiceNow, Jira, or equivalent) should include:

• Change description: MySQL major version upgrade from 8.0.37 to 8.4 LTS
• Business justification: MySQL 8.0 EOL (April 6, 2026), security patching requirement
• Risk assessment: Major version upgrade with potential for application compatibility issues
• Impact assessment: Expected downtime window, affected applications, affected users
• Rollback plan: Detailed steps with estimated rollback duration
• Go/No-Go criteria: Checklist of conditions that must be met before proceeding
• Communication plan: Who to notify before, during, and after the upgrade

Go / No-Go Criteria

Define clear criteria before entering the maintenance window. If any criterion is not met, postpone the upgrade.

Maintenance Window Monitoring

During the cutover window, monitor these metrics in real-time:

• Replication lag (Seconds_Behind_Source) on all replicas
• Active connections count (SHOW PROCESSLIST or performance_schema)
• Error log (tail -f /var/log/mysql/mysqld.log)
• Application error rates from your APM tool
• Query latency (p50, p95, p99) from slow query log or PMM
• InnoDB buffer pool hit ratio and I/O metrics

Communication Template

Send notifications at these milestones:

• Pre-upgrade (1 week before): Scheduled maintenance notification with date, time, expected duration, and affected services
• Maintenance start: "Maintenance window has begun. [Service] may experience brief connectivity interruptions."
• Cutover complete: "Database upgrade complete. Services restored. Monitoring for stability."
• All-clear (24-48 hours later): "Upgrade verified stable. Maintenance window closed."

Full Upgrade Project Timeline

Actual times vary significantly based on data size, complexity, team experience, and hardware. The estimates below are based on real-world upgrade projects.

Time Estimates by Data Size

The most variable component is backup/restore time, which is heavily dependent on data size:

Simplified Timeline (Skipping pt-upgrade)

If hardware constraints prevent a full compatibility test, the project can be reduced to 40-60 hours. This carries significantly higher risk:

Common Pitfalls and Troubleshooting

Server Refuses to Start: Removed Parameters in my.cnf

Symptom: mysqld fails to start with "unknown variable" or "unknown option" errors.

Cause: Removed parameters (default_authentication_plugin, master_info_repository, etc.) still present in my.cnf.

Solution: Remove all parameters listed in Part 1, Removed Parameters. Check the error log for the specific parameter name causing the failure.

Redo Log Incompatibility

Symptom: "This redo log was created with MySQL 8.0.x and it appears logically non empty."

Cause: MySQL was shut down with innodb_fast_shutdown = 2 or crashed before upgrade.

Prevention: Always set innodb_fast_shutdown = 0 and perform a clean shutdown before any upgrade.

Data Directory Deleted on Debian/Ubuntu

Symptom: /var/lib/mysql is empty or missing after removing MySQL 8.0 packages.

Cause: Used apt-get purge instead of apt-get remove. Purge removes data directories.

Solution: Restore from your pre-upgrade backup. Prevention: ALWAYS use apt-get remove, never apt-get purge.

Authentication Failures After Upgrade

Symptom: Applications or users cannot connect after upgrading to 8.4.

Cause: mysql_native_password plugin is removed in 8.4.

Immediate fix: Add mysql_native_password=ON to my.cnf and restart MySQL. Then migrate users per Part 1, Authentication Migration.

InnoDB Storage Engine Error for System Tables

Symptom: Error 1726 "Storage engine InnoDB Does Not Support System Tables."

Cause: my.cnf forces default_storage_engine = MyISAM. System tables require InnoDB.

Solution: Remove default_storage_engine = MyISAM from my.cnf, or set it to InnoDB.

Deprecated Plugin Errors

Symptom: Errors referencing missing shared libraries (e.g., query_response_time.so).

Cause: Percona-specific plugins from older versions registered in the data dictionary.

Solution:

DELETE FROM mysql.plugin WHERE name = 'QUERY_RESPONSE_TIME';
DELETE FROM mysql.plugin WHERE name = 'SCALABILITY_METRICS';

Query Failures from sql_mode Changes

Symptom: Queries that worked in 8.0 return errors like "Expression #N of SELECT list is not in GROUP BY clause."

Cause: ONLY_FULL_GROUP_BY is enforced in 8.4 default sql_mode.

Immediate fix: Set sql_mode explicitly in my.cnf to match your 8.0 mode. Long-term fix: Rewrite queries to comply with ONLY_FULL_GROUP_BY.

View and Routine Warnings

Symptom: "View is no more valid to use" warnings in the error log.

Cause: Views or stored routines reference deprecated syntax or changed objects.

Solution: Identify affected views with CHECK TABLE, then recreate them.

Complete Upgrade Checklist (41 Items)

Use this checklist to track progress through each phase of the upgrade.

Pre-Upgrade Preparation

Testing

Change Management

Execution

Post-Upgrade Validation

References and Resources

• MySQL 8.4 Release Notes
• MySQL 8.4 What Is New
• MySQL Shell Upgrade Checker
• Percona Toolkit (pt-upgrade)
• Percona Server for MySQL 8.4 Documentation
• ProxySQL Documentation
• Percona Support Knowledge Base: MySQL Upgrades articles