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.

2 Answers

Thank you for the note. May I ask - Why didn't you move to a Graviton2 instance by upgrading the primary or the reader instance? The downtime with this approach is just 60-120 seconds. We always suggest using native tools rather than AWS DMS for homogeneous migrations.

answered 2 months ago
  • At the cluster level, there is no option to change the instance type. At the instance level, the only options are to move to another db.r5.* type. db.r6g is not offered. I am contemplating upgrading first from Aurora 1.22.2 (MySQL 5.6) to Aurora 2.10.2 (MySQL 5.7) - will there be an option to switch to Graviton2 after that?

    A native tool is going to cost me far more time than 60-120 seconds.

  • Yes, that will work.


A key gap here is that the UI does not indicate that the instance types have been filtered based on the Aurora version. I would lose 10 inserts per second during any downtime. So the only option I could see was to use DMS. I spent about 6 hours battling DMS because the DMS info omitted to mention the requirement to restart the cluster after changing the parameter group to allow replication. I only found this detail by chance on a parameter group doc page.

answered 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions