Implementing Oracle Database API for MongoDB on Exadata Dedicated Infrastructure: Achieving Zero Data Loss and High Availability

Mission-critical applications cannot afford downtime. In this post, we demonstrate how a workload, migrated from MongoDB to Oracle Autonomous AI Database, continues operating through a complete regional outage with zero manual intervention and enterprise-grade recovery times.

This is the first in a series of articles that show how you can run MongoDB-compatible workloads on Oracle AI Database. And, in doing so, achieve higher levels of resilience, availability, and operational simplicity than traditional MongoDB deployments would allow.

For many enterprises, using standard MongoDB architectures to meet aggressive Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) is challenging. Replication lag, leader elections, and application restarts introduce unavoidable delay and risk data loss at precisely the moment reliability matters the most.

To overcome these constraints, you can implement a proven enterprise architecture using Autonomous Data Guard on Oracle Autonomous AI Database on Dedicated Exadata Infrastructure (ADB-D), alongside the Mongo API for Oracle. The result is a fully automated, cross-region failover solution designed for mission-critical workloads.

By adopting this architecture, you gain:
Always-on continuity: Applications remain available across regions without costly or risky code refactoring.
Enterprise-grade data protection: Strong consistency and data integrity, eliminating the rollback and lost-write scenarios common in Raft-based systems.
Seconds-level recovery: Automated cross-region failover measured in seconds—not minutes—with no human intervention.
In the sections that follow, we show exactly how you can achieve this:
Architecture that delivers: The design of the Primary, Local Standby, and Remote Standby databases on Exadata Dedicated Infrastructure; the MERN stack application on OKE; and the HAProxy configuration that ensures seamless application connectivity.
Proven resilience under failure: A step-by-step walkthrough of a simulated regional outage and the automatic role transition handled by Autonomous Data Guard.
Measurable results: Clear, objective analysis of recovery time, application behavior, and system stability during the event.

Architectural Design & Topology
To achieve true cross-region resilience, you will implement a multi-layered architecture that spans different regions and availability domains.
Key Technologies
MongoDB API for Oracle: Enables MongoDB workloads on Oracle Autonomous AI Database with ACID transactions.
Autonomous AI JSON Database (AJD) / ATP: Optimized for JSON and OLTP on Dedicated Exadata Infrastructure.
OCI Kubernetes Engine (OKE): Managed Kubernetes for MERN stack deployments.
Oracle MAA (Maximum Availability Architecture): The gold standard for HA/DR.
HAProxy: L4/L7 load balancing with health checks for database role detection.
The Architecture:
Database Layer: Oracle Autonomous AI Database on Dedicated Exadata Infrastructure.
Primary Region (US-East-1): Contains the Primary DB and a Local Standby.
Secondary Region (US-West-1): Contains a Remote Standby.
Application Layer: A MERN Stack (MongoDB, Express, React, Node.js) application deployed on OKE clusters in both regions.
Traffic Management: HAProxy is deployed as a sidecar to monitor database roles every 5 seconds, ensuring automatic redirection to the new primary during a switchover.

The architecture diagram shows the primary and secondary regions, OKE clusters, HAProxy, and the Autonomous Data Guard setup (primary, local standby, and remote standby).

Step-by-Step Deployment

The environment is built using a structured, automated approach:

  1. Infrastructure: Provision VCNs, private subnets, and a bastion host for secure access.
  2. Database HA: Create the Primary Autonomous Container Database and enable Autonomous Data Guard (Local & Remote) with Automatic Failover.
  3. Application: Deploy and Configure Oracle Kubernetes Clusters and OCI Load Balancing Service in Phoenix and Ashburn Regions
  4. Containerization: Package the MERN app with HAProxy and push the image to OCI Container Registry (OCIR).
  5. Orchestration: Deploy to OKE containers using YAML manifests.
  6. Load Simulation: Configure Apache JMeter to simulate real-world user traffic.

The details on how to build this architecture can be found by clicking on the link below.

Cross-Region High Availability with Dataguard for MongoDB API on OCI Setup Guide

High Availability Testing: The Switchover Scenario

When we validated this proposed architecture, the key to success was in testing how the system would react to a role change. We aimed for zero manual intervention at the application level and zero data loss.

Phase 1: Baseline Performance

First, we initiated the load test using JMeter via the command line script (jmeter_start.sh) and verified that the MERN application was connected to the primary database and functioning correctly.

J

We also checked the application logs to confirm active MongoDB API connections.

Phase 2: Initiating the Switchover

Before simulating a disaster scenario, we verified the current status of the databases via an automation script. As shown below, the database in us-phoenix-1 is the PRIMARY.

Next, we executed the switchover automation script to swap roles with the local standby.

We can observe the role change process starting immediately:

Phase 3: During the Transition

In the initial moments of the switchover, while the database roles were changing, we observed that the application briefly maintained its state without errors.

The MERN Store application is still visible during the initial switchover phase.

Phase 4: Downtime and Recovery

As the switchover was finalized (taking approximately 40-60 seconds), we observed temporary connectivity errors in both the JMeter results and the application interface.

JMeter summary logs showing error rates rising.

The MERN Store application is displaying a “Network Error” red banner.

Phase 5: Automatic Recovery

After approximately 60 seconds, the role change was complete with zero data loss. The local standby assumed the PRIMARY role.

The table showing Standby-Local-ACD-23ai is now PRIMARY.

Crucially, thanks to the HAProxy configuration, the application automatically reconnected to the new primary database without a manual restart or configuration change. The application and load tests resumed normal operations.

Conclusion: Bridging the Gap Between NoSQL Agility and Enterprise Reliability

This exercise demonstrates a pivotal finding for modern cloud architects: you do not need to sacrifice the developer agility of MongoDB to gain the resilience of an enterprise-grade database.

Our testing confirms that Oracle Autonomous AI Database on Dedicated Exadata Infrastructure, combined with Autonomous Data Guard, provides a robust safety net that is largely transparent to the application layer.

By integrating cloud-native components like OKE and HAProxy with the self-driving capabilities of Autonomous AI Database, we achieved a self-healing architecture.

In our simulated disaster scenarios, the system successfully navigated a complete regional failover with zero manual intervention and an RTO (Recovery Time Objective) of under 60 seconds.

For you, this translates to reduced operational overhead and the peace of mind that comes from knowing your NoSQL workloads are protected by the same engine that powers the world’s most critical financial systems.

What’s Next? While a 60-second recovery is impressive for disaster recovery, mission-critical applications often demand continuous availability. In Part 2 of this series, we will push the boundaries further. We will explore an Active-Active architecture using Oracle GoldenGate, demonstrating how to achieve zero downtime and global data distribution for your MongoDB workloads.

Cross-Region Active-Active Resilience for MongoDB API: Zero Downtime with Oracle GoldenGate (Part 2)

Resources

About the Authors

Burak Akkus is a member of Oracle’s Database Development team with 18+ years of experience in multi-cloud architectures, autonomous services, and NoSQL platforms. A specialist in end-to-end migrations and high-performance OCI deployments, Burak provides practical guidance on schema design and operational playbooks derived from extensive hands-on work with databases, OCI, and Azure.

Corina Todea is a product manager within the Oracle Database team with 22 years of expertise in enterprise software engineering and cloud-native architectures. Specializing in large-scale integrations, Kubernetes, and AI agents, Corina bridges the gap between product vision and real-world implementation, focusing on optimizing data-intensive systems for global scale.