Aurora MySQL 2 -> 3 Upgrade Precheck Failed With schemaInconsistencyCheck Due to an Obsolete Table

0

We can't upgrade to Aurora MySQL 3 because our pre-upgrade checks fail with "schemaInconsistencyCheck":

    {
        "id": "schemaInconsistencyCheck",
        "title": "Schema inconsistencies resulting from file removal or corruption",
        "status": "OK",
        "description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
        "detectedProblems": [
            {
                "level": "Error",
                "dbObject": "cwk.LevelRank4Concept",
                "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
            }
        ]
    }

The error refers to an old table removed from our database long time ago. It looks like the underlying frm file is corrupted but there is no way in RDS to access the filesystem. Does anybody know how to get rid of the INNODB_SYS_TABLES record for the obsolete table or how to overcome this for the Aurora MySQL upgrade?

1 Answer
0

Based on the below precheck error, this looks to be due to data dictionary inconsistency on the object cwk.LevelRank4Concept.

    {
        "id": "schemaInconsistencyCheck",
        "title": "Schema inconsistencies resulting from file removal or corruption",
        "status": "OK",
        "description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
        "detectedProblems": [
            {
                "level": "Error",
                "dbObject": "cwk.LevelRank4Concept",
                "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
            }
        ]
    }

As explained in this blog for Aurora MySQL version 2 to 3 checklist. When you see this issue during an upgrade, if one of following options work for you, we recommend you to try them first:

- Perform a logical dump and then restore to a new cluster, then upgrade the new cluster to Aurora MySQL v3. This strategy assume that you don’t need the problematic tables anymore since they will not be moved to the new cluster. You can use mysqldump or mydumper and myloader for multiple parallel threads.

- If there are binlog replica clusters, double check the same issues do not exist there then promote them to standalone clusters when there is no replica lag.
  • If you know the time when the DDL/DCL that causes the issue ran, perform point in time recovery (PiTR) to a time before the original DCL or DDL began. Migrate the delta to the restored cluster to minimize data loss.

If none of these options work for you, contact AWS Support.

Kedar
answered 4 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions