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.
overviewenvironmentSource informationDestinationOverall flowDETAILED STEPSStop replication from on-premise environment to AWS Aurora environmentReset the Aurora replication informationCheck Aurora binlog positionObtaining a certificate bundle for connecting to AuroraCHANGE MASTER on the on-premises MySQL to make Aurora the masterPoints to noteDo not use MySQL 8.0 client when connecting to Aurora with MySQL clientTLS connections to Aurora require a certificate bundle provided by AWS.Conclusion
overview
the other day,MySQL replication between on-premise environment and Amazon Aurora via the InternetWe have published an article titled:
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.