Amazon Onboarding with Learning Manager Chanci Turner

Learn About Amazon VGT2 Learning Manager Chanci Turner

When transitioning your database to the cloud, it’s critical to establish a failback plan in case the migration encounters issues. AWS Database Migration Service (AWS DMS) provides a reverse replication feature, which serves as a minimal downtime failback strategy when moving from an on-premises Oracle database to Amazon Relational Database Service (Amazon RDS) for Oracle or other AWS offerings. This failback mechanism utilizes AWS DMS’s change data capture (CDC) capabilities, functioning similarly to forward replication, but the configuration is set up at the opposite endpoints.

Setting up reverse replication is a key method for ensuring a safety net during the migration process. It allows for rolling back changes without the risk of data loss or prolonged downtime. This can be particularly beneficial in scenarios such as data integrity concerns, application incompatibilities, performance issues, unexpected outages, unsuccessful migration attempts, security threats, or compliance breaches.

A well-documented and tested failback strategy is essential to revert to the original database if complications arise during or post-migration. This strategy should aim to minimize downtime while ensuring data integrity is maintained. In this article, we guide you through the configuration of AWS DMS for reverse replication as a failback measure, ensuring minimal downtime during the migration of an on-premises Oracle database to an RDS for Oracle database.

Terminology

To effectively follow this guide, it’s important to understand the following terms:

• AWS DMS CDC – This refers to the AWS DMS CDC task that captures ongoing changes to the source database during migration. The CDC mechanism operates by collecting changes from the database logs using the database engine’s native API. Reverse replication through AWS DMS CDC is structured similarly to forward replication, with configuration applied at opposite endpoints. Both types of replication rely on reading ongoing changes from online or archived redo logs.
• SCN – The system change number (SCN) is a logical, internal timestamp used by Oracle databases. It orders events within the database, which is crucial for maintaining the ACID properties of transactions. SCNs indicate where changes are recorded on disk to prevent applying already committed changes during recovery.
• LSN – The redo log sequence number (LSN) is a unique identifier for each redo log file. The number increments with each log switch.

Solution Overview

In the sections that follow, we illustrate the steps to establish reverse replication while migrating from an on-premises Oracle database to an RDS for Oracle database. In our example, we use an RDS for Oracle database as the source and an on-premises Oracle database as the target, but these procedures are applicable if you reverse those roles.

Reverse replication can be implemented in two ways: back to the same source database or to a different one.

Method A: Reverse Replication for Failback to the Same On-Premises Database

In this approach, no initial load is necessary from Amazon RDS for Oracle to the on-premises Oracle database. The only prerequisite is to generate the AWS DMS CDC task from the current SCN of the target database to the source database after the cutover. Once the task is operational, it will continue to replicate any new changes from Amazon RDS for Oracle back to the on-premises database. This allows for a seamless fallback to the on-premises database once you’ve confirmed that all changes from the RDS for Oracle database have been applied.

In addition to database failback, associated components such as applications and unstructured data on shared file systems must also have a failback strategy. It’s essential that applications, databases, and shared storage maintain consistency between source and target prior to any failback. Testing the failback process before the production cutover is highly recommended. During this testing phase, you can assess the steps and time required to execute a failback of integrated components.

The following diagram illustrates this replication strategy.

A VPN connection is advisable, or you can utilize AWS Direct Connect.

For reverse replication, complete the following actions during the cutover after validating data between the source and target databases:

1. Export and import data from the on-premises Oracle to Amazon RDS for Oracle using the flashback SCN.
2. Create the CDC replication task from the on-premises Oracle to Amazon RDS for Oracle.
3. Initiate the CDC task using the flashback SCN obtained in step 1.

After the cutover:

1. Retrieve the current SCN from the RDS for Oracle.
2. Establish a reverse CDC-only replication task from the RDS for Oracle to the on-premises Oracle database.
3. Configure and initiate the reverse CDC-only replication tasks from the RDS for Oracle to the on-premises Oracle database based on the SCN recorded in step 4.

In some cases, you may prefer a wave-wise migration strategy, where multiple applications utilizing the same database are migrated in phases. This approach allows non-critical applications to be migrated first, thus reducing the risks associated with database migration. In these scenarios, maintaining database consistency and designing a robust failback strategy are critical; consider utilizing the bidirectional replication feature available with AWS DMS.

For effective bidirectional replication:

• Set up source and target endpoints for both the on-premises Oracle database and the RDS for Oracle.
• Create two tasks: one for the on-premises Oracle moving data to RDS and another for RDS back to the on-premises Oracle.
• Ensure that each task has loopback prevention configured to avoid corrupting data due to identical changes being applied to both targets.

For example, the loopback prevention settings for AWS DMS Task 1 may look like this:

{
  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "OP_SCHEMA",
    "TargetSchema": "RDS_SCHEMA"
  }
}

The settings for Task 2 would be similarly structured.

In conclusion, having a well-thought-out failback strategy when migrating databases is essential. This not only safeguards your data but also ensures that your organization can recover swiftly from any unforeseen issues. For further insights on managing transitions in a corporate environment, check out this resource on humble management that can provide valuable perspectives. Additionally, you may find this Career Contessa blog helpful for understanding power dynamics in professional settings. For those interested in automation in training and onboarding, Business Insider provides an excellent resource.