Upgrade process can be stopped by orphan data dictionary entries with no workaround
Description
Environment
Activity
Julia Vural December 24, 2024 at 1:00 PM
Our upstream bug has been marked as duplicate of https://bugs.mysql.com/bug.php?id=110722, which is seen as fixed.
Sveta Smirnova December 6, 2024 at 11:34 AM
Upstream bug was re-classified as doc bug and closed. Please close this one properly.
Aaditya Dubey April 10, 2024 at 4:07 PM
Hi
Thank you for the report. This bug report has been verified.
Francisco Bordenave April 10, 2024 at 11:07 AM
Bug documented also here in upstream
Francisco Bordenave April 9, 2024 at 2:00 PMEdited
Reproducible case in my sandbox:
Start a 5.6 instance
Create an InnoDB table with contents (in my case it was using sysbench)
alter table using algorithm=inplace
kill instance while alter is running, this should leave few files in the datadir:
Upgrade to 5.7 make sure table name reside in internal data dictionary
Before upgrading to 8.0, please remove
'#sql-3e992a_6.frm'&'#sql-ib27-958902930.ibd'from the 8.0 data directory and now attempt to upgrade to 8.0. The upgrade will fail, even if we remove the files from the datadir:
An error log is not very verbose, and this can also be reproducible by creating a tablespace and killing the server during the creation.
Details
Details
Assignee
Reporter
Francisco BordenaveUpstream Bug URL
Needs QA
Components
Affects versions
Priority
MediumSmart Checklist
Open Smart Checklist
Smart Checklist
Upgrading MySQL to 8.0 sometimes can be impossible because there could be orphan entries into information_schema.innodb_sys_* tables that wont succeed to upgrade into the new data dictionary process.
i.e.:
These entries are part of failed old ALTER TABLE attempts where the file in disk is missing (notice the /tmp location).
Moreover this specific case happens after the util.checkForServerUpgrade tool from mysqlshell reported no errors (see )
Additionally the error log show no useful information of the failure which makes debugging really hard:
I’m wondering if we can offer an alternative to clean up orphan entries by adding some type of force flag for the upgrade process that requires manual intervention to clean up orphan entries, also printing out to the error log what is the actual inconsistency causing the upgrade to fail will be really using too.