Database Mirroring vs. Replication: High-Availability & Disaster Recovery

Database Mirroring vs. Replication: HA vs. DR

The Context: "The 15-Minute Data Loss"

It was mid-2024. Our secondary data center in another region was supposed to be our "Safeguard". When the primary storage array in London failed, we triggered the failover. To our horror, we found that the last 15 minutes of crucial transaction data were "lost" because we were using asynchronous replication to save on network latency.

The bank was "Down", but the data was "Inconsistent". This is the cost of architectural trade-offs. This article explore the architecture of Oracle Data Guard and GoldenGate and how we optimized the balance between "High Availability" and "Zero Data Loss".

The Problem Statement

In a banking infrastructure, you must choose between "Speed" and "Safety".

• Goal: 100% Availability & Zero Recovery Point Objective (RPO=0).
• Metric: Failover time (RTO) < 60s, Data Loss (RPO) = 0.
• Challenge: The "Sync" penalty. Synchronous mirroring means every transaction must wait for a "Confirmed" signal from a remote database before it can commit.

Visual Architecture: Max Protection (Sync) vs. Max Performance (Async)

+-RESETFULLSCREEN

The Core Logic: High-Availability (HA) vs. Disaster Recovery (DR)

1. High Availability (HA) - Local Mirrored Clusters

HA is about surviving a component failure (e.g., a disk or a node). We use Oracle RAC (Real Application Clusters) to ensure the database stays up if one node crashes.

• Mechanism: Shared storage. All nodes access the same disk but coordinate in memory.
• RTO: Seconds (Instance failover).

2. Disaster Recovery (DR) - Remote Replication

DR is about surviving a site failure (e.g., an entire data center losing power). We use Oracle Data Guard to replicate the redo logs from the Primary to a Standby site.

• Active Data Guard: Allows the Standby to be open for "Read-Only" queries while it's still being updated from the primary. This is perfect for Offloading Reports.

3. GoldenGate: Logical Replication

Unlike Data Guard (which replicates physical blocks), Oracle GoldenGate replicates "Logical Changes" (SQL).

• Advantage: It allows for Active-Active (Multi-Master) configurations. You can write to London and write to Mumbai simultaneously, with GoldenGate handling the bi-directional sync.

The "Baigan" Take: Insights from the Trenches

Look, people love "Multi-Master" and "Active-Active" until they have a Conflict. Then baigan ka logic hai wo (that's nonsense) when two users update the same record at the exact same time in two different regions.

The 'Sync' Fallacy. Never put your DR site more than 50ms (RTT) away if you want Maximum Protection (Sync). If the network latency is 200ms, every single customer will feel that 200ms delay on every COMMIT.

• Rule: Use Far Sync instances. A local "Zero-weight" instance receives the redo synchronously and then ships it asynchronously to the remote site. This gives you RPO=0 without the performance penalty at the primary.
• Rule: Test your failover. A DR site that hasn't been "Flipped" in 6 months is a "Phantom Site". It will probably fail when you need it most.

Performance & Implementation Checklist

• Data Guard Broker: Use the DGMGRL tool to manage your DG configuration. It simplifies complex failover commands into a single SWITCH OVER command.
• Observer Node: Deploy a "Data Guard Observer" in a third location (e.g., a Cloud VM) to automate failover and prevent "Split-Brain" scenarios.
• Redo Compression: If your bandwidth between sites is expensive, enable REDO_TRANSPORT_COMPRESS=TRUE.
• Fast-Start Failover (FSFO): Enable FSFO to allow the database to automatically switch to the standby if the primary is unreachable for X seconds.

Conclusion

Database Mirroring and Replication aren't just "Server Tasks"; they are Insurance Policies. In a bank, availability is your most important asset. By mastering the trade-offs between Sync, Async, and Logical Replication, you build a resilient data tier that can survive everything from a single disk crash to a regional blackout. Mirror for safety, replicate for speed, and always have a "Plan B" that is tested.

Verified for Technical Nexus v1.9.0 | Part of the System Design Vault archive.