How to make it possible to switch back 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) mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, contributing to OSS, etc.
This article is located in SRGDBWGWe will publish materials regarding the database that the (DB Working Group) provides to 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
 
The environment is the same as in the previous post.
This assumes that the migration will take place immediately after migration from the original on-premises environment to Aurora during service maintenance.
We will create a state where you can switch back to the on-premises environment from Aurora.
In this procedure, we assume that writing from your application to MySQL has been stopped.

Overall flow


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

DETAILED STEPS


Stop replication from on-premise environment to AWS Aurora environment

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

Reset the 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 to make Aurora the master

Execute CHANGE MASTER in 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 the replication.

Points to note


Do not use MySQL 8.0 client when connecting to Aurora with MySQL 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 previous articles.
 

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; 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.
It is best to avoid having to cut back by conducting thorough advance verification, but it is also important to have procedures in place to allow for cutting back just in case.
 
SRG is looking for people to work with us. If you are interested, please contact us here.