How to enable reversion after migrating MySQL from on-premise to AWS environment

This is Oniumi (@fat47) from the Service Reliability Group (SRG) of the Technology Headquarters.
#SRG(Service Reliability Group) is a group that mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, and contributing to OSS.
This article is located in SRGDBWGWe will publish materials regarding the database provided by the DB Working Group for the entire company.
I hope this helps in some way.
 

overview


The content was about replicating between the on-premise environment and Amazon Aurora and migrating to AWS.
During the actual migration, you need to consider being able to switch back to the on-premises environment if any problems arise.
In this article, we will look at how to quickly switch back by making the Amazon Aurora environment the master and the on-premises environment the slave.
 

environment


Source information

Server OS: CentOS7
Database: MySQL5.7.41

Destination

AWS Aurora
 
It's the same environment as the previous post.
This scenario assumes that the migration has just taken place after migrating from the source on-premises environment to Aurora while service maintenance is being performed.
We will create a state where you can switch back to the on-premises environment from this Aurora.
In this procedure, we assume that writing from the application to MySQL has been stopped.

Overall flow


  • Stop replication from on-premise environment to AWS Aurora environment
  • Reset Aurora replication information
  • Check Aurora binlog position
  • Obtaining a certificate bundle for connecting to Aurora
  • Change master on the on-premises MySQL server to make Aurora the master.
 
 

DETAILED STEPS


Stop replication from on-premise environment to AWS Aurora environment

Switching to the AWS environment stops replication between the on-premises environment and the Aurora environment.
Aurora replication stopped
 
Check to see if it really has stopped.

Reset Aurora replication information

The replication information remaining in Aurora is no longer needed, so we will reset it.
 
Now it's clean.

Check Aurora binlog position

To set up Aurora → on-premises replication, make a note of the Aurora binlog position.
 
Checking binlog position in Aurora

Obtaining a certificate bundle for connecting to Aurora

A TLS connection to Aurora requires an AWS certificate.
 
アジアパシフィック (東京)ap-northeast-1-bundle.pe

Change master on the on-premises MySQL server to make Aurora the master.

Execute CHANGE MASTER on the on-premise MySQL. Specify the LOG_FILE and Position you noted down earlier.
Please note that if a failover occurs on the Aurora side, replication with on-premises will stop.
 
Start and verify replication.

Points to note


When connecting to Aurora with the MySQL client, do not use the MySQL 8.0 client.

Aurora v2 (MySQL 5.7) incorporates some MySQL 8.0 features through its own implementation.
When this is replicated to MySQL 5.7 in an on-premises environment, an error occurs and the replication stops.
More details are provided in a previous article.
 

TLS connections to Aurora require a certificate bundle provided by AWS.

When I set up replication with on-premise as the master, I used a self-signed certificate.
If Aurora is the master, you cannot use a self-signed certificate, so you must use the certificate bundle provided by AWS.
 

Conclusion


This time, we introduced a method to revert if something happens when migrating MySQL to AWS.
The best thing to do is to carry out thorough pre-tests and other procedures to prevent cutting back, but it is important to have procedures in place to ensure that cutting back is possible just in case.
 
SRG is looking for people to work with us. If you're interested, please contact us here.