MySQL Migration Approaches for RDS Takeout to Tessell
Introduction
Migrating a database from Amazon RDS MySQL to Tessell-managed MySQL instances requires careful planning, execution, and validation to ensure minimal downtime, data integrity, and application continuity. This document outlines both online and offline migration approaches for RDS MySQL Takeout, detailing the prerequisites, preparation steps, migration execution, post-migration validation and application cutover.
Assessment
Before initiating migration from RDS MySQL to Tessell, it is critical to perform a comprehensive assessment of the source environment. The following key details should be captured and validated:
MySQL Engine Version
Capture the current MySQL engine version and edition.
Verify compatibility with the target Tessell MySQL version.
Instance & Storage Details
Capture current DB instance class (vCPU, memory), storage type (gp2, gp3, io1, etc.), allocated size, and provisioned IOPS.
Estimate current and projected storage growth.
Database Configuration
Collect applied DB parameter group, DB cluster parameter group, and option group configurations.
Identify custom parameters that may require replication on Tessell.
Database Objects
Check for database schema compatibility issue such as tables without primary key, use of non-innodb tables, etc.
Identify tables with large objects (LOB), partitioned tables, etc.
Review usage of foreign key constraints, triggers, events and stored procedures.
High Availability and Topology
Capture HA deployment model:
Single-AZ / Multi-AZ instance
Multi-AZ Cluster
Number of read replicas
Any custom cluster endpoints in use
Assess failover behavior and application connection dependencies.
Backup & Retention Policies
Record current automated backup schedules and retention policies.
Assess compliance requirements for long-term data retention.
Validate whether Tessell configurations can meet or improve these objectives.
Application downtime tolerance
Identify acceptable downtime windows for application cutover.
Migration Methods Overview
There are two ways to migrate RDS to Tessell MySQL.
Offline Migration
Requires complete application downtime during migration.
Best suited for smaller datasets or when downtime is acceptable.
Typically faster to set up but results in longer application unavailability during the cutover.
Online Migration
Keeps the source database live during migration by using replication or CDC.
Downtime is limited to the final cutover phase (seconds to minutes).
Recommended for large databases or production workloads requiring high availability.
Offline Migration Approach
Process Steps
Stop the application service writing to RDS.
Take a logical backup from RDS MySQL using mysqldump or mydumper.
Transfer backup files to Tessell MySQL instance.
Restore backup to Tessell MySQL using mysql or myloader client.
Perform post-migration validation before making the database live.
Start the application service pointing to Tessell endpoint.
Perform application sanity checks.
Considerations
Requires extended downtime.
Not ideal for large datasets.
Online Migration Approach
Online migration reduces downtime by synchronizing data between source and target until final cutover.
Migration Using AWS DMS (Database Migration Service)
AWS DMS can replicate data from RDS to Tessell MySQL with minimal downtime.
Perform full load and set up ongoing replication(CDC) to sync changes.
During cutover, stop application writes to RDS, wait for replication to catch up, and start application pointing to Tessell MySQL endpoint.
Considerations
Configure RDS MySQL to retain binary logs for atleast 24 hours.
Validate DMS prerequisites for source and target database.
Online Migration Phases
Preparing Source database
Configure binlog settings for online migrations.
Ensure sufficient binlog retention time.
Create a dedicated replication user with required privileges as per DMS documentation.
Ensure DMS replication instance and Tessell MySQL instance IP addresses are allowed in the RDS security group.
Preparing Target database
Provision instance with matching or higher version than RDS.
Adjust parameter groups to match required configurations.
Ensure sufficient disk space for data and logs.
Ensure DMS replication instance IP address is allowed in the firewall rule of Tessell MySQL database.
User Migration
Export the user accounts from RDS using mysqlpump.
Remove system related mysql db users from the dump.
Import the user dump to Tessell MySQL instance.
Schema Migration
Use
mysqldump
utility to backup source database schema (without data, routines, triggers, events) and ensure you have excluded all system databases while exporting.Import the schema dump to the target database.
Data Migration
Create a DMS replication instance.
Create DMS source and target endpoints.
Setup a DMS task to migrate the existing data and configure ongoing replication.

Post-Migration Checks
Verify database objects such as table counts, row counts, user counts, etc.
Validate application connectivity.
Application Cutover to Tessell
Schedule a cutover window.
Stop all writes to RDS MySQL.
Allow replication/DMS to catch up.
Update application connection strings to point to Tessell MySQL.
Start the application
Perform application sanity checks.
Monitor closely for errors or performance issues.
Setup DMS CDC replication from Tessell MySQL to RDS

Detach RDS after Cutover
This phase is to delete the RDS MySQL after applications are running smoothly with Tessell MySQL HA service after 24 hours.
Stop the CDC replication on RDS
Optionally, delete the RDS MySQL instance.

Conclusion
Choosing the right migration approach depends on downtime tolerance, data volume, and operational constraints. Offline migration is simpler but requires extended downtime, while online migration ensures minimal downtime at the cost of added complexity. With proper pre-migration assessment and execution, RDS MySQL Takeout to Tessell can be performed smoothly and reliably.
Last updated
Was this helpful?