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?

已提問 2 個月前檢視次數 407 次
1 個回答
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
已回答 16 天前

您尚未登入。 登入 去張貼答案。

一個好的回答可以清楚地回答問題並提供建設性的意見回饋,同時有助於提問者的專業成長。

回答問題指南