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?