RDS Best Practices — Fast and Stable Migration to RDS
In this article, I will explain how to perform fast and stable migration to RDS.
Data migration to RDS can be started once the purchase has been made. When the RDS begins providing services, users can only dump user databases as a SQL file and then source the SQL file to RDS: migrating data to RDS–MySQL by using the MySQL dump tool and migrating data to RDS–SQL Server by using the SQL Server client tool. These two methods are the simplest, but also have many limitations:
The user’s database is too big and the logical SQL import method is slow, causing significant downtime.
Too many errors occur during import, or the import process is interrupted. Therefore, the import needs be started over again.
The user’s database must still provide services during migration to RDS.
A lot of users shy away from moving their services to the cloud because of data migration, making it the only thing that stands between them and RDS. However, as Confucius once said, “a craftsman who wishes to do his work well must first sharpen his tools”. In order to help users better access the cloud, RDS has improved the existing RDS migration methods, aiming at helping users perform fast and stable migration to RDS. Improved MySQL and SQL Server migration tools are separately provided:
The MySQL migration tool supports online migration where users can migrate data to RDS without interrupting service.
The SQL Server migration tool uploads users’ physical backups to an FTP and then restores the physical backups to RDS, which improves migration speed.
These two tools have been integrated in the RDS console. Refer to the official guide for RDS in the documentation center.
When most users look at a console, they can only see a black box. It’s not uncommon to see users raising tickets through the console regarding the principles of. Here I will roughly describe the implementation process for each tool:
Principle of MySQL Online Migration:
Step 1: Pre-check, mainly used to verify whether the network is connected and check the account and environment.
Step 2: Full backup, where all user data will be dumped and then restored to RDS.
Step 3: Incremental migration, where binlog applications generated during full backup and the following steps will all be parsed to RDS.
Step 4: Switching, where the RDS data has completely overtaken the user’s database and switching can begin.
The MySQL online migration tool has some limitations, however. For example:
• MySQL 5.0 only supports full migration, and does not support incremental migration;
• Migration with MySQL 5.6 is not supported, as the storage process and trigger migration are not supported;
• During migration, incremental migration will fail if ddl occurs.
Principle of SQL Server Tool Migration:
Step 1: Physical backup is performed on local databases.
Step 2: The backups are uploaded to an FTP server provided by RDS (the FTP address supports uploading via both a private network and a public network).
Step 3: After RDS scans and verifies user’s uploaded backups, the backups are restored to the RDS.
Step 4: The user switches the application to RDS.
Because SQL Server hasn’t opened the log interface, RDS currently cannot support online migration. RDS currently does not support importing from the master database.
I hope that this article will help you in your journey with RDS.
Reference:
