1 Answer
- Newest
- Most votes
- Most comments
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.
answered a month ago
Relevant content
- asked 5 months ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 9 months ago
- AWS OFFICIALUpdated 2 years ago