A fintech client running MySQL 8.0.36 scheduled their 8.4 LTS upgrade for Q2 — and discovered during our pre-upgrade audit that three variables in their my.cnf were completely removed in 8.4. The upgrade would have prevented MySQL from starting on their 12-replica cluster.
MySQL 8.4 is the first Long Term Support release in the 8.x series. It removes features deprecated since 8.0.0, enforces stricter replication defaults, and ships new InnoDB parameters that replace old ones. This checklist covers every production-critical item to verify before upgrading.
- MySQL 8.4 removes
innodb_log_file_size, allslave_*variables, andquery_cache_*— these prevent startup. - Run
mysqlsh checkForServerUpgradeon every node before touching packages. - Upgrade replicas first, monitor 24 hours, then upgrade the primary.
- Replace
innodb_log_file_size × innodb_log_files_in_groupwith a singleinnodb_redo_log_capacity.
What Was Removed in MySQL 8.4
Any of these variables in your my.cnf will cause MySQL 8.4 to refuse to start:
expire_logs_days # replaced by binlog_expire_logs_seconds
slave_* # all slave_* replaced by replica_*
query_cache_size # query cache fully removed
innodb_log_file_size # replaced by innodb_redo_log_capacity
innodb_log_files_in_group # replaced by innodb_redo_log_capacityKey InnoDB Default Changes
| Variable | 8.0 Default | 8.4 Default |
|---|---|---|
| innodb_flush_method | fsync | O_DIRECT |
| binlog_format | ROW | ROW (enforced) |
| innodb_redo_log_capacity | N/A | 104857600 (100MB) |
Replace innodb_log_file_size=2G + innodb_log_files_in_group=2 with innodb_redo_log_capacity=4294967296 (4GB).
Pre-Upgrade Checklist
Step 1: Run the MySQL Shell Upgrade Checker
mysqlsh -- util checkForServerUpgrade root@localhost:3306 --target-version=8.4.0 --output-format=JSON > upgrade_check_$(hostname).jsonStep 2: Scan my.cnf for Removed Variables
grep -E "expire_logs_days|slave_|query_cache|innodb_log_file_size|innodb_log_files" /etc/mysql/my.cnfStep 3: Validate Replication
SHOW REPLICA STATUS\G
SELECT @@GLOBAL.gtid_mode, @@GLOBAL.enforce_gtid_consistency, @@GLOBAL.binlog_format;
SELECT TIMESTAMPDIFF(SECOND, MIN(last_applied_transaction_end_apply_timestamp), NOW()) AS lag_seconds
FROM performance_schema.replication_applier_status_by_worker;Step 4: Fix Deprecated SQL in Stored Routines
SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.ROUTINES
WHERE ROUTINE_DEFINITION LIKE '%START SLAVE%'
OR ROUTINE_DEFINITION LIKE '%STOP SLAVE%';Step 5: Backup Then Upgrade Replica First
xtrabackup --backup --user=backup_user --target-dir=/backup/pre-84-$(date +%Y%m%d)
systemctl stop mysql
apt-get install -y mysql-server-8.4
mysqld --upgrade=FORCE && systemctl start mysql
mysql -e "SELECT VERSION(); SHOW REPLICA STATUS\G"MySQL supports replication between an 8.0 primary and an 8.4 replica. Run your 8.4 replica in production for 24 hours before upgrading the primary.
Post-Upgrade Validation
SELECT @@innodb_redo_log_capacity, @@innodb_flush_method;
SELECT * FROM performance_schema.replication_connection_status\G
SHOW ENGINE INNODB STATUS\G- Run
mysqlsh checkForServerUpgradeon every node — it catches most blockers before you touch a package. - Replace
innodb_log_file_sizewithinnodb_redo_log_capacityequal to the product of the old values. - Rename all
slave_*variables toreplica_*in config files, scripts, and stored routines. - Upgrade replicas first, monitor 24 hours, then promote the primary — never upgrade both simultaneously.
Working with JusDB on MySQL Upgrades
JusDB manages MySQL major version upgrades with a full pre-flight audit, replica-first upgrade, automated validation, and 48-hour post-upgrade monitoring.