Cannot get passed precheck to upgrade mySQL 5.7 to 8.0.36 ?

Hello,

Please check the logs and events section of the green instance to find the recent events that would share the reason for the upgrade not succeeding on it.
[+] Viewing logs, events, and streams in the Amazon RDS console - https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/logs-events-streams-console.html

Kindly note that that MySQL 8.0 includes a number of incompatibilities with MySQL 5.7. Thus, to detect these incompatibilities, Amazon RDS runs pre-checks automatically when you start an upgrade from MySQL 5.7 to 8.0 on an instance.

If incompatibilities are found during the pre-checks, Amazon RDS prevents the upgrade and provides a log file (PrePatchCompatibility.log) to check them.

[+] Prechecks for upgrades from MySQL 5.7 to 8.0 - https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html#USER_UpgradeDBInstance.MySQL.57to80Prechecks

PrePatchCompatibility.log

The PrePatchCompatibility.log file contains errors, warnings and notices :

• ERROR : Correct these issues before upgrading to avoid compatibility issues.
• WARNING : No fatal errors were found that would prevent an upgrade, but some potential issues were detected.
• NOTICE : No known compatibility errors or issues were found. But you can check the NOTICE Level error logs.

Thus, as per the information mentioned in the following article : How do I resolve a preupgrade check failure in Amazon RDS for MySQL? - https://repost.aws/knowledge-center/rds-mysql-preupgrade-failure, please find the categorizing for the issues in the PrePatchCompatibility.log file shared by you :

• Usage of utf8mb3 charset : NOTICE
• Creating indexes larger than 767 bytes on tables with redundant row format might cause the tables to be inaccessible. : WARNING
• The tables with redundant row format can't have an index larger than 767 bytes. : ERROR

Please be informed that it is the ERROR that prevents the upgrade from occurring on an instance.

Please find the information below with respect to the issues that you shared which were present in the PrePatchCompatibility.log file for your instance :

Usage of utf8mb3 charset The following objects use the utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support.
More Information: https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html.
......

This message indicates about the usage of utf8mb3 charset. You may choose to convert all the tables which are utilizing the same charset before upgrading. Please note that utf8mb4 is a superset of utf8mb3 (alias UTF-8), and utf8mb4 provides special characters such as emoji Characters.

The general procedure to overcome these inconsistencies is as follows, you may use the same at your end :
"""
SET FOREIGN_KEY_CHECKS = 0;
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE mydb.mytable CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
SET FOREIGN_KEY_CHECKS = 1;
"""

Creating indexes larger than 767 bytes on tables with redundant row format might cause the tables to be inaccessible.
You have one or more tables with redundant row format. Creating an index larger than 767 bytes might cause the table to be inaccessible (only 50 tables are shown).
......

The tables with redundant row format can't have an index larger than 767 bytes.
The tables with redundant row format can't have an index larger than 767 bytes (only 50 indexes are shown).
More Information: https://bugs.mysql.com/bug.php?id=99791
[table_schema, table_name, index_name, index_length] mydb,some_table,some_column,65535 - Consider changing the row_format of the tables to dynamic and restart the upgrade
......

As suggested in the above messages, to fix the issue here, please alter tables to dynamic row format.

You may set the parameter ‘innodb_default_row_format’ to value ‘DYNAMIC’ and it will be used during table creations.

For existing tables that are running at a different row_format, you may alter it by using the command below :
"""
ALTER TABLE XXXX ROW_FORMAT=DYNAMIC;
"""
[+] https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html

To check the tables that are not running with dynamic row_format, you may run the below command :
"""
select GROUP_CONCAT(CONCAT( "ALTER TABLE ", table_schema, ".", table_name, " ROW_FORMAT=DYNAMIC;" ) SEPARATOR " ") as cmd
FROM information_schema.TABLES
WHERE table_schema = 'database_name_here' AND ROW_FORMAT <> 'Dynamic';
"""

The output will be the command to alter the table to row_format=dynamic.
Output:
ALTER TABLE database_name.table_name ROW_FORMAT=DYNAMIC;

It is highly recommended to take a full backup prior to performing these actions and test them before implementing in a Production environment.
Before making any changes to your production database instance, consider making them first in a test environment. This will allow you to safely test any of the potential fixes for these failed checks before implementing into production.

Please refer to the documentations below for information about major version upgrade and pre-upgrade checks for RDS for MySQL database instances :
[+] Overview of MySQL major version upgrades - https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html#USER_UpgradeDBInstance.MySQL.Major.Overview
[+] How do I resolve a preupgrade check failure in Amazon RDS for MySQL? - https://repost.aws/knowledge-center/rds-mysql-preupgrade-failure

Thank you!