MySQL Forums
Forum List  »  Data Recovery

Re: Table Problems on legacy databases
Posted by: Simon raphael
Date: October 08, 2025 01:08AM

This appears to be a classic InnoDB dictionary mismatch from a 5.7 to 8.4 upgrade. MySQL 8 has a new data dictionary; copying .frm/.ibd folders over won’t work and gives a “table doesn’t exist” error, even when the files are present.

Recovery path (works reliably):

Spin up a separate MySQL 5.7 VM (same build if possible). Copy the entire datadir (including ibdata1, ib_logfile*, and not just the database folders).

Start with innodb_force_recovery=1 and raise to 4–6 only if needed (read-only).

Dump everything with mysqldump --single-transaction --routines --triggers --events --skip-lock-tables.

For tables still failing (1146), but you have .frm + .ibd:

Recreate structure from the .frm (use mysqlfrm or Percona’s tools),

ALTER TABLE … DISCARD TABLESPACE; copy the .ibd,

ALTER TABLE … IMPORT TABLESPACE;

Restore the dumps into a clean MySQL 8.4 instance.

Also check:

Lower-case table names must match between the old and new servers.

Don’t REPAIR on InnoDB.

If you only have a .frm file (without a .ibd file and the table is not in ibdata1), the data is likely lost.

This approach usually gets the “bad half” back long enough to dump cleanly before upgrading.

Options: ReplyQuote


Subject
Views
Written By
Posted
214
September 12, 2025 03:20PM
Re: Table Problems on legacy databases
46
October 08, 2025 01:08AM


Sorry, only registered users may post in this forum.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.