Inplace upgrade from Aurora MySQL 5.7 to 8.0 fails during downtime phase
1
Hello folks. I made a clone of our Aurora mysql 5.7 production DB to test the in place upgrade to 8.0. The first attempt failed with some easy to fix precheck errors. After fixing those, the actual upgrade could proceed. However the whole procedure ends with
Database cluster is in a state that cannot be upgraded: Engine bootstrap failed with no mysqld process running
Looking in the mysql-error-running.log
file I could find this:
2022-09-27T09:55:08.981013Z 2 [ERROR] [MY-012064] [InnoDB] Column datatype mismatch for col: collection_end (dict0upgrade.cc:249)
2022-09-27T09:55:08.981174Z 2 [ERROR] [MY-012066] [InnoDB] Column precision type mismatch(i.e NULLs, SIGNED/UNSIGNED etc) for col: collection_end (dict0upgrade.cc:303)
2022-09-27T09:55:08.981288Z 2 [ERROR] [MY-012070] [InnoDB] Column collection_end for table: `mysql`.`rds_global_status_history_old` mismatches with InnoDB Dictionary (dict0upgrade.cc:403)
2022-09-27T09:55:08.981412Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for mysql.rds_global_status_history_old (table.cc:1820)
2022-09-27T09:55:08.987904Z 2 [ERROR] [MY-012064] [InnoDB] Column datatype mismatch for col: collection_end (dict0upgrade.cc:249)
2022-09-27T09:55:08.988062Z 2 [ERROR] [MY-012066] [InnoDB] Column precision type mismatch(i.e NULLs, SIGNED/UNSIGNED etc) for col: collection_end (dict0upgrade.cc:303)
2022-09-27T09:55:08.988183Z 2 [ERROR] [MY-012070] [InnoDB] Column collection_end for table: `mysql`.`rds_global_status_history` mismatches with InnoDB Dictionary (dict0upgrade.cc:403)
2022-09-27T09:55:08.988315Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for mysql.rds_global_status_history (table.cc:1820)
2022-09-27T09:55:09.006829Z 2 [ERROR] [MY-012064] [InnoDB] Column datatype mismatch for col: Timestamp (dict0upgrade.cc:249)
2022-09-27T09:55:09.007004Z 2 [ERROR] [MY-012066] [InnoDB] Column precision type mismatch(i.e NULLs, SIGNED/UNSIGNED etc) for col: Timestamp (dict0upgrade.cc:303)
2022-09-27T09:55:09.007137Z 2 [ERROR] [MY-012070] [InnoDB] Column Timestamp for table: `mysql`.`proxies_priv` mismatches with InnoDB Dictionary (dict0upgrade.cc:403)
2022-09-27T09:55:09.007277Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for mysql.proxies_priv (table.cc:1820)
2022-09-27T09:55:12.756364Z 2 [Warning] [MY-010778] [Server] Parsing 'mysql.rds_collect_global_status_history' routine body failed. Creating routine without parsing routine body (routine.cc:425)
2022-09-27T09:55:12.765899Z 2 [Warning] [MY-010778] [Server] Parsing 'mysql.rds_set_gsh_collector' routine body failed. Creating routine without parsing routine body (routine.cc:425)
2022-09-27T09:55:12.766429Z 2 [Warning] [MY-010778] [Server] Parsing 'mysql.rds_set_gsh_rotation' routine body failed. Creating routine without parsing routine body (routine.cc:425)
2022-09-27T09:55:13.177268Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables. (mysqld.cc:7130)
2022-09-27T09:55:13.177566Z 0 [ERROR] [MY-010119] [Server] Aborting (mysqld.cc:3031)
None of the mentioned error causing tables / columns are under our control. How can this be fixed? Thanks!
已提問 2 年前檢視次數 1002 次lg...
1 個回答
- 最新
- 最多得票
- 最多評論
這些答案是否有幫助?支持正確答案,以幫助社區從您的知識中受益。
相關內容
- 已提問 9 個月前lg...
- 已提問 3 個月前lg...
- 已提問 8 個月前lg...
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 2 年前
- AWS 官方已更新 1 年前