Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save pangkalizer/86f158f0b13520854e920a4a5be669b1 to your computer and use it in GitHub Desktop.
Save pangkalizer/86f158f0b13520854e920a4a5be669b1 to your computer and use it in GitHub Desktop.
MySQL to Aurora migration (minimal downtime)
MySQL Database to Aurora Migration
Preparation Check-list
Update the production Security Group so that Inbound accepts connection from same VPC group as source (requires for replication).
On the production server, set bin log retention hours, this is duration in hours before binary logs are automatically deleted. This also acts a window time to copy and migrate the production server into a Aurora replica. Currently the production server is set to NULL which means AWS delete the logs as soon as it doesn't need it any more.
CALL mysql.rds_set_configuration('binlog retention hours', 48);
Convert all tables using MEMORY engine to InnoDB, AWS converts all tables to InnoDB during migration, however keeping MEMORY engine tables on production causes issues on replication.
Replicate Production Server (MySQL) into new Aurora instance
Create a Read Replica of Production instance. The replica will be used to record the starting point (log position) of replication to Aurora. This will also be used as the based copy of production that will be migrated.
Once the replica has been created, connect to the replica instance and stop the replication.
CALL mysql.rds_stop_replication;
While the Read Replica is stopped, run the SHOW SLAVE STATUS command. Retrieve the current binary log file name from the Master_Log_File field and the log file position from the Exec_Master_Log_Pos field. Save these values for when you start replication.
SHOW SLAVE STATUS\G
Create a snapshot from currently running replica, once snapshot is complete, you can now delete the replica instance (or hold on to it, until aurora replication has been tested).
Migrate the newly created snapshot into Aurora, this will take a while or so to finish. Once finished, make sure the the security group is the same as the the production server.
Connect to the new Aurora instance and set the replication master pointing to production server.
CALL mysql.rds_set_external_master('PRODUCTION_DB_HOST',3306,'DB_USER','DB_PASSWORD','mysql-bin-changelog.284215',77527,0);
Start replication, Aurora instance should now be replicating from the production database (master).
CALL mysql.rds_start_replication
To check replication status run SHOW SLAVE STATUS on Aurora instance, check the Master_Log_File and Exec_Master_Log_Pos. Then connect to production database and run SHOW MASTER STATUS. See File and Position values should be the same in Aurora instance which means the replica is up to date with the master.
SHOW MASTER STATUS\G
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment