LAB 01
Migrate a MySQL database from on-premises to Amazon RDS with zero downtime using Change Data Capture (CDC)
This lab involves two environments: the existing on-premises data center running a WordPress/WooCommerce application with MySQL, and the target AWS environment where the database will be migrated to Amazon RDS.
The DMS replication instance sits in the public subnet with public accessibility enabled so it can reach the on-premises source database over the internet. The target RDS instance remains in the private subnet for security — DMS communicates with it through the VPC's internal network.
Follow the six-task pipeline to migrate your MySQL database from on-premises to Amazon RDS. Click any node to see details, or hit Play to watch the full sequence.
Connect to the source MySQL server via Session Manager and verify the wordpress-db database exists with all 46 tables (WordPress core + WooCommerce).
Console: EC2 → Session Manager → mysql -u root -pExpand each task for the goal, key configuration, and important notes. Use this as a condensed reference while working through the lab.
Verify the source MySQL database is running and contains the expected wordpress-db with 46 tables.
| Setting | Value |
|---|---|
| Connection method | Session Manager (SSM) |
| MySQL user | root |
| Database | wordpress-db |
| Expected tables | 46 (WordPress + WooCommerce) |
Use the SourceDBServerSessionURL from your lab resources to connect. The password is provided in the DatabasePassword output.
Provision a managed MySQL database in a private subnet that will serve as the migration target.
| Setting | Value |
|---|---|
| Engine | MySQL 8.4.7 (Community) |
| Template | Dev/Test |
| Instance class | db.t3.micro (Burstable) |
| DB identifier | targetrdsdatabase |
| Master username | admin |
| VPC | TargetVPC |
| Subnet group | database-subnet-group |
| Public access | No |
| Security group | DB-SG |
| Deployment | Single-AZ |
Remove the default security group and select only DB-SG. Disable enhanced monitoring, automated backups, encryption, and auto minor version upgrades for this lab environment.
Deploy the DMS replication instance that orchestrates data movement between source and target databases.
| Setting | Value |
|---|---|
| Name | replication-instance |
| Instance class | dms.t3.medium |
| Storage | 50 GiB |
| Engine version | 3.5.x (latest) |
| High Availability | Single-AZ (Dev/Test) |
| VPC | TargetVPC |
| Subnet group | dms-subnet-group |
| Public accessible | Yes |
| Security group | RI-SG |
Public accessibility is required so the replication instance can reach the on-premises source database over the internet. Remove the default security group and use only RI-SG.
Grant replication privileges and verify binary logging is active so DMS can perform continuous change capture.
| Setting | Required Value |
|---|---|
| REPLICATION CLIENT | Granted to wordpress-user |
| REPLICATION SLAVE | Granted to wordpress-user |
| SUPER privilege | Granted to wordpress-user |
| log_bin | ON |
| binlog_format | ROW |
Binary logging must be in ROW format (not STATEMENT or MIXED) for DMS CDC to work correctly. After granting privileges, restart MySQL with sudo service mysql restart.
Define connection configurations for both databases and verify connectivity through the replication instance.
| Setting | Value |
|---|---|
| Identifier | source-endpoint |
| Engine | MySQL |
| Server | DBServerDNSName (from outputs) |
| Port | 3306 |
| Username | wordpress-user |
| Setting | Value |
|---|---|
| Identifier | target-endpoint |
| Engine | MySQL (auto-filled from RDS) |
| RDS instance | targetrdsdatabase |
| Username | admin |
Always run the endpoint connectivity test before creating. Select the replication instance and wait for "Successful" status. This confirms network paths and credentials are correct.
Create and start a migration task that performs full load followed by continuous replication, then validate the migrated data.
| Setting | Value |
|---|---|
| Task identifier | replication-cdc |
| Task type | Migrate and replicate |
| Duration | Indefinitely |
| Target table prep | Do nothing |
| LOB mode | Limited LOB (32 KB max) |
| Data validation | Enabled |
| Table mapping schema | wordpress-db |
| Start task | Automatically on create |
After the task reaches "Load complete, replication ongoing" status, connect to the target RDS via the Bastion Host and confirm all 46 tables are present in wordpress-db.
Essential concepts to understand before and during the database migration lab.
Source and target use the same database engine (MySQL → MySQL). No schema conversion is needed — DMS handles the data transfer directly without transformation overhead.
After the initial full load completes, DMS continuously reads the source database's binary log to capture inserts, updates, and deletes — replicating them to the target in near real-time.
An EC2-based server managed by DMS that runs your migration tasks. It connects to both source and target endpoints, pulling data from one and pushing to the other.
The recommended migration strategy: first, bulk-copy all existing data (full load), then switch to continuous replication (CDC) to keep source and target synchronized until cutover.
A MySQL feature that records every data modification in a binary log file. DMS reads this log to identify changes made after the full load started — essential for CDC to function.
Before running any migration task, always test endpoint connectivity. This validates network paths, security group rules, credentials, and database accessibility through the replication instance.
In production banking environments, CDC is essential for migrating transaction databases. The source system continues processing payments while DMS replicates changes in near real-time — enabling cutover windows measured in seconds rather than hours of downtime. For AnyCompany Bank, this means payment processing, account updates, and customer transactions never stop during the migration.
| Aspect | This Lab (Homogeneous) | Heterogeneous Alternative |
|---|---|---|
| Engine change | MySQL → MySQL (same) | Oracle → PostgreSQL (different) |
| Schema conversion | Not required | AWS SCT required |
| Complexity | Lower — direct replication | Higher — type mapping, stored proc conversion |
| CDC support | Binary log (ROW format) | Varies by source engine |
| Typical use case | Lift-and-shift to managed service | Engine modernization (cost, licensing) |