Uncertain redo‑log flush status and upgrade consistency after interrupted mysql_upgrade

Bottom line

You cannot verify a fully flushed redo log from mysql_upgrade, and redo-log flush state is not proof that an upgrade finished. After an interruption, restart MySQL cleanly, let InnoDB crash recovery complete, then re-run the upgrade check for your installed version. Keep foreign_key_checks enabled; do not disable it during recovery.

Likely explanation

mysql_upgrade runs upgrade SQL as ordinary transactions. InnoDB flushes redo at commit according to innodb_flush_log_at_trx_commit and checkpoints dirty pages independently. If the server or utility is interrupted, uncommitted work is rolled back on restart and committed work is reconciled by crash recovery. Crash recovery does not re-run mysql_upgrade logic and does not validate foreign keys.

Established behavior

• mysql_upgrade has no output or status meaning “redo log fully flushed.”
• InnoDB crash recovery replays redo and rolls back uncommitted transactions; it does not validate foreign keys.
• mysql_upgrade is designed to be re-runnable and reads upgrade state from data dictionary/system metadata, not from redo-flush state.
• Foreign-key checks remain enforced during normal operation; disabling them during recovery can mask inconsistency.
• Behavior is version-sensitive: separate mysql_upgrade applies to older series, while MySQL 8.0.16+ performs upgrade tasks at startup and the standalone utility is deprecated or absent depending on release.

Steps for this case

1. Back up the data directory before restarting or re-running upgrade commands.
2. Confirm the installed MySQL version:

   mysql -u root -p -e "SELECT VERSION();"

   If the server will not start, inspect the error log first.
3. Restart MySQL cleanly and allow crash recovery. Avoid kill -9; use a normal shutdown or service restart, for example

   mysqladmin -u root -p shutdown

   then start the service.
4. Check the error log for InnoDB checkpoint messages and completion of crash recovery; there should be no pending redo replay.
5. Optionally run

   mysql -u root -p -e "SHOW ENGINE INNODB STATUS\G"

   and compare “Log sequence number” with “Log flushed up to.” Equality indicates redo durability so far; it does not prove mysql_upgrade completed.
6. Re-run the version-appropriate upgrade check: mysql_upgrade on older series, or restart and let the server perform upgrade tasks on MySQL 8.0.16+. If it reports no remaining actions, the upgrade state is consistent.
7. Leave foreign_key_checks=1 enabled. Do not set it to 0 during recovery.

Assumes InnoDB is used for the upgraded system tables and the server can restart cleanly. If innodb_flush_log_at_trx_commit is not 1, up to about one second of committed redo may be lost on crash, but recovery remains consistent; this does not change the steps. If recovery does not complete or the upgrade check still reports required actions after a clean re-run, stop and collect the error log before forcing changes.