Full Stack Disaster Recovery Now Supports MySQL HeatWave: Step-by-Step Guide

Date: August 26, 2025

Oracle has enhanced Full Stack Disaster Recovery (Full Stack DR) by adding support for MySQL HeatWave DB Systems. You can now integrate MySQL DB Systems into DR protection groups, run prechecks, apply DR policies, and orchestrate failovers or switchovers just like with other supported services.

This guide explains the update in simple words while also providing exact steps you can follow.


1. Preparing MySQL HeatWave DB System for Disaster Recovery

Before adding MySQL to a DR Protection Group, you must prepare both the primary and standby DB Systems.

Steps:

  1. Create a primary MySQL HeatWave DB System in Region A.

  2. Take a manual backup of the primary DB system.

  3. In the OCI Console, go to Backups → Copy Backup, and copy this backup to Region B.

  4. In Region B, create a new MySQL HeatWave DB System using the copied backup.

    • Ensure the new DB System’s mode is Read Only.

  5. On the primary system (Region A), create a replication channel targeting the standby in Region B.

  6. Configure SSL/TLS certificates (optional but recommended for secure replication).

  7. Store the admin user credentials and replication user credentials as secrets in OCI Vault in both regions.

2. Adding MySQL DB System to a Disaster Recovery Protection Group

Now that both systems are ready, add them into a DR Protection Group (DRPG).

Steps:

  1. In Region A (primary):

    • Open the OCI Console → Disaster Recovery → Protection Groups.

    • Create a new DR Protection Group (Primary) or use an existing one.

    • Click Add Members → MySQL DB System.

    • Select the primary DB System (Read/Write).

    • Specify its standby target DB System OCID.

  2. In Region B (standby):

    • Create a DR Protection Group (Standby).

    • Add the standby MySQL DB System (Read Only).

    • Link it back to the primary DB System in Region A.

  3. Verify both groups are synchronized.

3. Policies for MySQL HeatWave DB System in DR

Oracle enforces policies to ensure correctness.

Policies include: 

  • Primary Mode: Must be Read/Write.

  • Standby Mode: Must be Read Only.

  • Vault Policies: Admin and replication secrets must exist and be active in Vault.

  • Replication Policies:

    • Replication channel must be Active.

    • GTID execution must be enabled on standby.

  • Lifecycle Policies: Both DB Systems must be in Active state.

4. Prechecks by Full Stack Disaster Recovery

Before executing a DR plan, Full Stack DR automatically runs prechecks.

Switchover Prechecks: 

  • Primary DB: Active, Read/Write.

  • Standby DB: Active, Read Only.

  • Admin/Replication secrets in Vault and available.

  • Replication channel active with GTID execution.

  • Connectivity from container instances to DB nodes.

Failover Prechecks:

  • Standby DB System: Active and in DRPG.

  • Target DB System mapping is correct.

  • Vault secrets are available.

If a precheck fails, Full Stack DR either blocks execution or raises warnings.

5. Default Order of DR Plan Groups

Full Stack DR executes plan groups in a default order to ensure dependencies are respected. 

Default Order Includes:

  1. Networking resources.

  2. Storage (Block Volumes, File Storage).

  3. Compute instances.

  4. Databases (MySQL HeatWave, Oracle DB, etc.).

  5. Application tiers.

MySQL DB Systems are now part of this default sequence.

6. Built-in Plan Groups for MySQL DB System

When you add MySQL to a DRPG, built-in plan groups are auto-generated. 

Examples of built-in plan group steps for MySQL:

  • Switch role of DB System (primary ↔ standby).

  • Validate replication channel and GTID state.

  • Update lifecycle state (e.g., start standby in Read/Write after failover).

You can also add custom steps like DNS updates or app restarts.

7. Managing Members of a DR Protection Group

After adding, you may need to update or remove members.

Steps:

  1. Go to the DRPG in the OCI Console.

  2. Select Members → Manage Members.

  3. Add, edit, or remove MySQL DB Systems.

  4. Save changes and rerun prechecks to ensure readiness.

8. Other Updates in This Release

  • OKE Cluster Namespaces: When adding OKE clusters to DRPGs, you can now specify which namespaces are included in backups.

  • Improved Plan Group Management: Better control over default vs. custom groups.

  • Enhanced Member Management: Easier to update resource properties without recreating groups.

9. Example End-to-End Workflow

Here’s what a full DR setup looks like for MySQL HeatWave:

  1. Deploy primary MySQL HeatWave DB in Region A.

  2. Backup → copy → restore in Region B (standby DB).

  3. Configure replication channel + Vault secrets.

  4. Create DRPGs in Region A (primary) and Region B (standby).

  5. Add DB Systems into DRPGs with correct role mappings.

  6. Run prechecks.

  7. Test with a DR Drill (Switchover).

  8. In an outage, run Failover Plan → standby becomes primary.

  9. Once Region A is restored, perform Switchover back (failback).

Summary

With this release, Oracle has brought first-class DR support to MySQL HeatWave DB Systems in Full Stack Disaster Recovery. You now get automation, built-in policies, prechecks, and ordered recovery plans—removing manual complexity and reducing risks.

This makes DR for MySQL as seamless and reliable as it is for Oracle Database and Autonomous Database, giving enterprises a unified way to protect critical workloads across OCI. 

Author: Narasimharao Karanam

Comments

Post a Comment