Question

Difficulty: HardDatabase Migration and Schema Conversion using DMS and SCT

A solutions architect is designing a migration strategy to move an on-premises self-managed MySQL 8.0 database to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The database contains critical transactional tables with high write throughput. The migration must minimize downtime and ensure that schema incompatibilities, such as custom stored functions, are handled correctly before replication begins. Which two actions must the solutions architect take to prepare the database and execute the migration? (Select two.)

  1. Enable MySQL binary logging on the source database, set the binary log format to ROW, and ensure the logs are retained for a duration sufficient to support the replication task.Answer
  2. Run the AWS Schema Conversion Tool (SCT) to convert the MySQL schema to PostgreSQL, generate an assessment report, and manually rewrite the unsupported custom functions into PostgreSQL PL/pgSQL functions before applying the schema to the target.Answer
  3. C
    Keep the MySQL database in its default logging configuration and configure the AWS DMS task to read directly from the InnoDB transaction redo log files to capture modifications.
  4. D
    Perform a Replatform migration by taking a physical backup of the MySQL database using Percona XtraBackup, restoring it to an EC2 instance running MySQL, and using that instance to automatically sync schemas and write workloads directly to the target Aurora PostgreSQL cluster.
  5. E
    Deploy an Amazon ElastiCache for Memcached replication group as a target cache endpoint in AWS DMS to buffer the converted write queries before applying them to the Aurora PostgreSQL DB cluster to mitigate replication lag.

Answer

Enable MySQL binary logging on the source database in ROW format and use AWS Schema Conversion Tool (SCT) to convert the schema, manually refactoring the unconverted functions.
To migrate heterogeneously from MySQL to Aurora PostgreSQL with minimal downtime, the database schema must be converted using the AWS Schema Conversion Tool (SCT). Any custom database functions that cannot be automatically converted must be manually refactored into the target database's language (PL/pgSQL). To replicate changes continuously (CDC) using AWS Database Migration Service (DMS), MySQL binary logging must be enabled and configured to ROW format, which records the actual row changes so DMS can capture and apply them to the target.

Step-by-Step Solution

1
Analyze source schema compatibility
Identify that custom stored functions cannot be automatically converted by AWS SCT and need manual refactoring.
Ensures that schema elements are rewritten into target-compatible PL/pgSQL code.
2
Configure source database logging
Enable binary logging with the format set to ROW on the source MySQL instance.
Allows AWS DMS to capture and replicate ongoing transactions (CDC) from the source database.
3
Convert and apply schema
Use AWS SCT to convert the schema, manually update the custom functions, and apply the schema to the Amazon Aurora PostgreSQL database.
Prepares the target database structure before data replication starts.
4
Run DMS task
Initiate an AWS DMS full-load and continuous replication task to migrate data.
Performs initial copy and keeps target database in sync with minimal downtime.

Key Concept

Heterogeneous database migration using AWS Schema Conversion Tool (SCT) for schema conversion and AWS Database Migration Service (DMS) with Change Data Capture (CDC) requiring row-based binary logging.
Rate this question