Migrate MySQL to Amazon Aurora: From Simple Snapshots to Zero‑Downtime Strategies

Author Han Sijie, an AWS Solutions Architect, presents a practical guide for moving MySQL databases to Amazon Aurora across several typical scenarios.

Scenario 1 – Migrate Amazon MySQL RDS to Aurora with downtime

Stop writes to the source database.

Create an RDS snapshot via the console (Actions → Take snapshot).

Restore the snapshot as an Aurora cluster (Actions → Migrate snapshot) and configure the new instance.

After Aurora is ready, update the application connection string to point to the new Aurora endpoint.

Scenario 2 – Migrate Amazon MySQL RDS to Aurora with minimal downtime

Create an Aurora read replica from the MySQL RDS (Actions → Create Aurora read replica).

Allow the replica to sync while the source remains online.

When ready, stop the application, verify replication is caught up with show slave status \G and ensure Seconds_Behind_Master is 0.

Promote the read replica to a primary (Actions → Promote).

Update the application connection string to the new Aurora endpoint and restart the application.

Scenario 3 – Migrate self‑hosted MySQL to Aurora with sufficient downtime

Download Percona XtraBackup 4.1 from

https://www.percona.com/downloads/Percona-XtraBackup-2.4/LATEST/

and extract it.

Run XtraBackup to create a streamed backup, e.g.:

innobackupex --user=root --password=<your password> --database=myaurora --stream=tar ~/s3-restore/backup2 | split -d --bytes=51200000 - ~/s3-restore/backup.tar

Upload the resulting tar files to Amazon S3 (or use AWS Snowball for very large datasets).

In the RDS console, choose “Restore from S3”, select the Aurora engine, and provide the backup location and instance details.

After restoration completes, switch the application to the Aurora endpoint.

Scenario 4 – Migrate self‑hosted MySQL to Aurora with minimal downtime

Method 1: MySQL‑Aurora replication

Create an Aurora read replica and configure binlog replication from the MySQL master.

Allow continuous sync; keep Aurora read‑only during this phase.

During a low‑traffic window, stop writes on MySQL, wait for full sync, then promote the Aurora replica to primary (set read_only=0).

Optionally, use XtraBackup with --slave-info to capture binlog coordinates, upload the backup to S3, and restore it as an Aurora instance.

Execute the following stored procedures on Aurora to configure it as a replica of MySQL:

CALL mysql.rds_stop_replication;

CALL mysql.rds_set_external_master('172.31.20.125','3306','repadmin','<password>','mysql-bin.000001','1024',0);

CALL mysql.rds_start_replication;

After replication catches up, stop the MySQL source and point the application to Aurora.

Method 2: AWS Database Migration Service (DMS)

Create a DMS replication instance sized for the workload.

Define a source endpoint for the MySQL database and a target endpoint for an empty Aurora cluster.

Create a migration task with “Migrate existing data and replicate ongoing changes” and enable CloudWatch logs.

Configure selection rules to copy the desired schemas/tables.

Start the task; DMS will continuously replicate changes from MySQL to Aurora.

When synchronization is complete, stop the application writes, pause the DMS task, and switch the application connection string to Aurora.

Overall, the guide walks through increasingly complex migration paths, allowing readers to choose the approach that best matches their downtime constraints and infrastructure.