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!

seeotee
已提問 1 年前檢視次數 562 次
2 個答案
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
支援工程師
Kevin_Z
已回答 1 年前
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
已回答 6 個月前

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

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

回答問題指南