Zero-Downtime Database Migration: AWS RDS to Alibaba Cloud PolarDB

This technical blog post provides a production-ready, step-by-step guide to migrating mission-critical database workloads from AWS RDS MySQL to Alibaba Cloud’s PolarDB with zero service disruption. Readers will learn how to design and execute a seamless transition strategy utilizing Alibaba Cloud Data Transmission Service (DTS) for real-time, bi-directional, and incremental data replication. The article also breaks down how Alibaba Cloud PolarDB's cloud-native storage-compute decoupled architecture absorbs massive, sudden traffic spikes during cutover, and delivers a rigorous DNS switchover runbook. Ultimately, this serves as an indispensable blueprint for DevOps engineers and cloud architects looking to execute risk-free, cross-cloud database migrations.

What We Will Achieve from This Blog

By following this architectural blueprint and migration runbook, you will achieve:

1. Near-Zero RTO and RPO: Learn how to keep services fully online and database records completely synchronized across cloud providers up to the exact second of cutover.

2. Infrastructure Resilience: Understand how PolarDB's separate scaling of compute and storage prevents performance bottlenecks during traffic redirections.

3. Risk Mitigation: Execute migrations with a fallback "rollback" mechanism in place using real-time reverse synchronization.

4. Repeatable Migration Blueprint: Obtain a production-validated migration runbook that can be customized for enterprise workloads of any scale.

Architectural Topology & Replication Flow

A successful database migration requires a clear visual understanding of how traffic flows during both the Active Replication Phase and the DNS Cutover Phase.

Phase 1: Real-Time Active Replication (Both Clouds Online)

During this phase, the production application continues to read and write to AWS RDS. DTS continuously pulls data (schemas, historical data, and ongoing incremental binlogs) and applies it to PolarDB.

Phase 2: Post-Cutover State (Alibaba Cloud Active)

During the cutover, DNS records are updated to point to Alibaba Cloud's App Instances. All read/write traffic is redirected to PolarDB, and DTS reverse-replication can be enabled to allow rollback if issues arise.

How PolarDB Solves the Cutover Spike Problem

A major point of failure during migrations is the Cutover Spike. When traffic suddenly shifts from AWS to Alibaba Cloud, the database must instantly handle cache warm-up overhead, connection pooling spikes, and sudden write operations.

Traditional architectures require over-provisioning huge, expensive database instances weeks in advance because scaling out database nodes requires slow, physical copying of data.

PolarDB’s Cloud-Native Decoupled Architecture solves this through several features:

• Compute-Storage Decoupling: PolarDB separates the compute nodes (which run the database engine) from the storage nodes (PolarStore).

• Instant Scale-Out: Because compute nodes share a single distributed storage pool, you can add up to 16 read-only nodes in under 5 minutes. No data replication is needed.

• Serverless Scaling: You can configure PolarDB to automatically scale CPU and memory resources up or down dynamically based on actual load metrics, protecting you from cutover spikes while keeping post-migration costs low.

Step-by-Step Implementation Guide

Step 1: Preparing the Source AWS RDS MySQL Instance

Before DTS can replicate data, the source database must be configured to expose its write logs (binlogs).

1. Enable Binlog in AWS Parameter Groups

Ensure your AWS RDS parameter group has the following configurations:

Note: If you make these changes to a default parameter group, you must create a custom database parameter group, apply it, and reboot the RDS instance.

2. Create a Dedicated Migration User in AWS RDS

Log in to your RDS MySQL instance and run the following commands to create a user with appropriate replication privileges:

3. Update AWS Security Groups

Configure the AWS Security Group assigned to your RDS instance to allow inbound TCP traffic on port 3306 from the Alibaba Cloud DTS CIDR blocks for your target region (refer to the Alibaba Cloud DTS IP Address Ranges).

Step 2: Creating and Configuring the PolarDB Target

1. Navigate to the Alibaba Cloud PolarDB Console.

2. Click Create Cluster and select your engine type (e.g., PolarDB for MySQL 8.0).

3. Choose your network environment (ensure it resides in the VPC you intend to deploy your application in).

4. Create an administrator account and database schemas corresponding to your AWS databases.

Step 3: Setting Up Real-Time Sync with Alibaba Cloud DTS

Alibaba Cloud DTS manages schema migration, full historical transfer, and real-time incremental synchronization.

1. Purchase and Configure the DTS Task

1. Go to the DTS Console and click Create Task.

2. Select your source and target locations:

   • Source Instance: User-Created Database with Public IP (or VPN/Express Connect if connected privately). Select AWS as the provider.

   • Target Instance: PolarDB Cluster.

3. Click Configure Subscription Channel

2. Map Source to Target

Enter the connection profiles for both endpoints:

3. Select Migration Types

In the migration configurations, check the following options:

• Schema Migration: Migrates table structures, views, triggers, and stored procedures.

• Full Data Migration: Copies all existing records.

• Incremental Data Migration: Keeps databases continuously synchronized in real-time by reading the RDS binlogs.

Select the tables you want to migrate and move them to the Selected Objects list.

4. Run Pre-check and Start

Click Next to run a comprehensive pre-check. DTS will validate database compatibility, network connectivity, and user permissions. Once the pre-check passes, start the migration task. Monitor the replication lag until it falls and stabilizes at 0 seconds.

Step 4: The Step-by-Step DNS Switchover Strategy

Once replication lag is consistently at 0 seconds, you are ready to switch traffic. Do not rush this step. Follow this proven cutover sequence:

Step 4.1: Reduce DNS TTL (Days Before Cutover)

To ensure client machines do not cache the old AWS endpoints, lower your DNS Record Time-to-Live (TTL) to 60 seconds at least 48 hours prior to the migration.

Step 4.2: Enable Maintenance Mode & Block Source Writes

During your migration window:

1. Put your user-facing application into a brief "Scheduled Maintenance" state or set your API services to read-only mode to prevent new data from being written.

2. Force the source database into read-only mode to guarantee no accidental database writes occur:

Step 4.3: Verify Final Synchronization

Monitor the DTS migration task console. Wait until the Incremental Replication Lag reads 0 seconds. This indicates that the final transactions before you locked the source have been successfully written to PolarDB.

Step 4.4: Update Database Connection Strings & DNS

1. Update your application deployment configuration files to point to your new PolarDB Cluster Endpoint (which automatically routes reads and writes to correct nodes).

2. Update your DNS hosting service (e.g., Route 53 or Alibaba Cloud DNS) to route production endpoints to your Alibaba Cloud Application Load Balancer (ALB) or ECS instances.

Step 4.5: Validation and Rollout

1. Run automated integration test suites against your newly deployed application instances pointing to PolarDB.

2. Once tests pass, disable maintenance mode.

3. Monitor your application and database performance dashboards.

Real-World Use Cases & Business Applications

• High-Volume E-Commerce Platforms: Running global online shopping events where even 5 minutes of offline database downtime during migration would result in hundreds of thousands of dollars in lost revenue.

• Massive Multiplayer Online Games (MMOs): Migrating regional gaming databases from AWS to Alibaba Cloud's dominant APAC regions to reduce game-server ping times for regional users without interrupting active player logins.

• FinTech & SaaS Applications: Migrating payment or user backends under strict compliance and high SLAs where any database inconsistency or extended maintenance window would violate client SLAs.

Beyond Migration: What Else Can Be Done?

Once your database is running on PolarDB, you can leverage advanced native cloud capabilities to further optimize performance and reliability:

1. Implement Global Database Network (GDN): Easily extend your PolarDB instance to multiple international regions with cross-region replication lag under 2 seconds for localized, low-latency reads.

2. Setup Real-Time Analytics with AnalyticDB: Sync transactional data directly into AnalyticDB using DTS to run high-performance BI reporting and data visualization pipelines without impacting your live production database.

3. Database Proxy Connection Pooling: Use the native PolarDB proxy to automatically separate read/write queries and intelligently pool connections, shielding your database from application connection leaks.

The ideas and opinions shared here are entirely my own and do not reflect those of the company I work for.