By using AWS re:Post, you agree to the Terms of Use

Questions tagged with Amazon Aurora

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

DMS migration from Aurora MySQL 5.6 to Aurora MySQL 5.7 on graviton

Hi there, I am having recurring issues migrating Aurora MySQL 5.6.10 on db.r5.large to Aurora MySQL 5.7.12 on db.r6g.large. I started by trying to replicate all schemas I had created, but this failed with an unknown error. I then broke this down into one schema per replication group, this also failed with an unknown error. I then turned on CloudWatch logging for all tasks. This worked other than one table repeatedly fails to replicate. If I use the mysql cli to drop or repair the table, mysql drops the connection! When I look at the table in phpmyadmin, it says 'unknown storage engine' and/or table in use. When I try to drop the schema using phpmyadmin, it logs me out straight away! I've waited a few minutes and now can log back in, and can see the schema has been dropped successfully. This looks like a bug in DMS creating the table, or in Aurora somehow locking the table and putting it into an inconsistent state. I've now resolved the issue and moved on, but the service team might want to be aware of this. The table schema is very simple: CREATE TABLE IF NOT EXISTS `lkcities` ( `state` varchar(2) DEFAULT NULL, `city` varchar(16) DEFAULT NULL, `country_id` varchar(2) NOT NULL, UNIQUE KEY `country_id` (`country_id`,`state`,`city`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -- Dumping data for table `lkcities` -- INSERT INTO `lkcities` (`state`, `city`, `country_id`) VALUES ('AK', 'Akhiok', 'US'), ('AK', 'Akiachak', 'US'), ('AK', 'Akiak', 'US'), ('AK', 'Akutan', 'US'), ('AK', 'Alakanuk', 'US'), ('AK', 'Aleknagik', 'US'), ('AK', 'Allakaket', 'US'), ('AK', 'Ambler', 'US'), ('AK', 'Anaktuvuk Pass', 'US'), ('AK', 'Anchorage', 'US'), etc ~25,705 rows.
1
answers
0
votes
15
views
asked 2 days ago

Inplace upgrade from Aurora MySQL 5.7 to 8.0 fails during downtime phase

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!
1
answers
1
votes
21
views
asked 3 days ago