Always-On Databases: How Active-Active Replication Works Across Clouds

It's 11 AM on your big promotion day. Your e-commerce platform is processing 50,000 orders per minute. Then your primary cloud provider reports a regional network issue. Your ops team scrambles to fail over to the standby cluster — DNS propagation, connection draining, health checks. Twelve minutes later, you're back online.

Twelve minutes. 600,000 orders lost. Customer trust damaged.

Now imagine a different scenario: both clouds were already serving traffic. When Cloud A went down, Cloud B just... kept processing orders. No failover. No DNS switch. No scramble. No lost revenue.

That's active-active replication — and it's not just for e-commerce giants with unlimited budgets. If your business runs workloads where minutes of downtime translate to real losses, understanding this architecture is worth your time.

This post breaks down the three hard problems that make cross-cloud active-active genuinely difficult — and how OceanBase Cloud solves each one.

The Three Hard Problems

Bidirectional sync between two active database clusters isn't just "primary-standby in both directions." In an active-active setup, both data centers handle read and write requests simultaneously. To ensure data consistency across both sides, real-time bidirectional synchronization is required. Three challenges make it architecturally distinct:

1. Loopback prevention. When data syncs from Cloud A to Cloud B, Cloud B's transaction logs now contain that data. Without intervention, Cloud B will sync it right back to Cloud A — creating an infinite loop.

2. Conflict detection. If both clouds accept writes, what happens when the same record is updated in both locations simultaneously? Someone has to decide which write wins.

3. Cross-cloud latency. Network distance between cloud providers affects sync performance. The architecture must minimize latency impact without sacrificing consistency.

Each of these problems has a solution — but the solutions require database-aware engineering, not just network configuration.

How Cross-Cloud Active-Active Works

OceanBase Cloud implements active-active replication through two major components: cross-cloud deployment infrastructure and bidirectional synchronization links.

OceanBase Cloud's active-active architecture: Each side runs incremental log parsing and data ingestion, connected through cross-cloud gateways with built-in loopback prevention and conflict detection.

Solving Loopback: Thread ID Filtering

OceanBase Cloud supports bidirectional synchronization between heterogeneous databases, including MySQL, Oracle, and OceanBase Database. The loopback problem requires database-specific solutions. OceanBase Cloud handles it differently depending on the source database:

For OceanBase Database: The synchronization component assigns unique thread IDs to all data writes it performs. During log parsing, the system automatically filters out any transactions marked with these thread IDs. Data that arrived via sync never gets re-synced.

For MySQL and Oracle sources: A transaction table records all synchronized data during incremental writes. Before parsing logs for sync, the system checks whether each transaction already exists in this table. If yes, it's discarded. If no, it proceeds to the target.

This isn't generic duplicate detection — it's origin-aware filtering that prevents loops without blocking legitimate writes.

Solving Conflicts: Configurable Resolution

When both clouds simultaneously update the same record (identified by unique key), a conflict occurs. OceanBase Cloud provides real-time conflict detection with three configurable resolution strategies:

All conflicts are logged regardless of strategy, allowing you to download and analyze patterns. The practical recommendation: design your application to avoid same-record writes across data centers through routing or partitioning logic.

Solving Latency: Localized Components

Cross-cloud network traffic directly affects sync performance. OceanBase Cloud addresses this through component placement:

• Log parsing components deploy on the source cloud — filtering happens locally, reducing cross-cloud data transfer
• Data writing components deploy on the target cloud — writes happen with local latency
• Cloud gateway service handles network automation between providers, supporting dedicated lines, public internet, or cloud enterprise networks

Data in transit is encrypted with AES-128-GCM. Session keys rotate periodically and transmit through secure private tunnels.

What Active-Active Enables

With bidirectional sync in place, the operational characteristics change significantly:

Zero failover delay. Both clouds are already serving traffic. When one fails, the other continues — no switchover, no DNS propagation, no pager.

Full resource utilization. Unlike primary-standby, where the standby cluster sits idle waiting for disaster, both clusters actively serve production workloads.

Geographic load balancing. Route users to their nearest cloud provider for lower latency, while maintaining data consistency across regions.

RPO approaching zero. Real-time synchronization means minimal data exposure during failures. With proper network configuration, sync latency stays in the milliseconds-to-hundreds-of-milliseconds range.

When Active-Active Is Right — And When It Isn't

Active-active isn't universally better than primary-standby. It's a different set of trade-offs.

Choose active-active when:

• Your business cannot tolerate any failover delay
• You want to fully utilize infrastructure investments in both clouds
• Your application logic can avoid same-record concurrent writes (through sharding, routing, or partitioning)

Choose primary-standby when:

• Cost optimization is a primary concern
• Minute-level RTO is acceptable for your SLAs
• You prefer simpler operational complexity

Neither architecture is wrong — they solve different problems. The wrong choice is having no multi-cloud strategy at all.

Getting Started

OceanBase Cloud supports active-active deployment across AWS, Azure, GCP, Alibaba Cloud, Huawei Cloud, Tencent Cloud, and Baidu Cloud — covering 64 regions and 240+ availability zones globally.

To set up cross-cloud active-active replication:

1. Create OceanBase instances on two cloud providers via the OceanBase Cloud console
2. Configure bidirectional sync using OMS (OceanBase Migration Service)
3. Select conflict resolution strategy per table
4. Enable monitoring across both clusters from the unified console

For detailed setup instructions, see Set up cross-cloud active-active on OceanBase Cloud.