How can I bypass prechecks for RDS engine upgrades?

1

I am using the Aurora Blue/Green deployment process to upgrade by database from mySQL5.7 to mySQL8.0.26. This also is upgrading the Aurora engine from 2 to 3.

The upgrade fails due to a pre-check failure:

{
            "id": "engineMixupCheck",
            "title": "Tables recognized by InnoDB that belong to a different engine",
            "status": "OK",
            "description": "Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removes InnoDB table files manually from the disk and creates e.g. a MyISAM table with the same name.\n\nA possible way to solve this situation is to e.g. in case of MyISAM table:\n\n1. Rename the MyISAM table to a temporary name (RENAME TABLE).\n2. Create some dummy InnoDB table (its definition does not need to match), then copy (copy, not move) and rename the dummy .frm and .ibd files to the orphan name using OS file commands.\n3. The orphan table can be then dropped (DROP TABLE), as well as the dummy table.\n4. Finally the MyISAM table can be renamed back to its original name.",
            "detectedProblems": [
                {
                    "level": "Error",
                    "dbObject": "mysql.general_log_backup",
                    "description": "recognized by the InnoDB engine but belongs to CSV"
                }
            ]
        }

As an Aurora user, it is not possible for me to delete, move, move, alter or change any tables in the mysql tablespace, so the recommend remediation is not possible.

So my question is, how can I force the Blue/Green process to skip this check, or even better, how can I manually DROP the mysql.general_log_backup table as I do not need it?

Please note I am using "FILE" based logging the DB parameters.

Steps to reproduce:

  • Create an aurora instance with Engine version 5.7.mysql_aurora.2.10.3
  • start a blue green deployment with
  • engine version 8.0 and aurora3+
  • use custom cluster parameter group
  • use custom instance parameter group
  • Blue Green environment created
  • DB Engine Upgrade fails

Thanks!

2 Antworten
0

Hi,

Thanks for sharing the detailed information.

I have checked internally regarding to the issue, this will need to engage the internal team to apply mitigations from AWS end. Sincerely apologize for the inconvenience. But if you have support plan, I would encourage you to raise a support case for us to take a look and mitigate the problem.

Before applying mitigation from AWS end, please also make sure that this is the only pre-check errors found.

AWS
SUPPORT-TECHNIKER
Kevin_Z
beantwortet vor einem Jahr
0

I have the same issue, and I see this happened 7 month ago. So, this hasn't been resolved yet? Isn't there another workaround other than raising a Case Support? Thanks.

Daniel
beantwortet vor 6 Monaten

Du bist nicht angemeldet. Anmelden um eine Antwort zu veröffentlichen.

Eine gute Antwort beantwortet die Frage klar, gibt konstruktives Feedback und fördert die berufliche Weiterentwicklung des Fragenstellers.

Richtlinien für die Beantwortung von Fragen