TL;DR: Active-active replication lets every node in a cluster accept writes and sync changes to its peers, which keeps writes available during regional outages but adds conflict resolution, replication lag, higher costs, and no protection against corruption or ransomware. It justifies that complexity mainly for five-nines, multi-region, or edge workloads, while read replicas, sharding, or active-passive setups suit most other needs. OpenShift VMs require block-level replication with orchestrated failover instead.
Active-Active Replication: When It's Worth the Complexity
Every node is live and accepts writes. When a region goes dark, there’s no failover window to sit through. That’s the promise, and it’s a strong one. But plenty of teams move to an active-active database expecting faster writes and get something else: conflict resolution headaches, replication lag, and a bigger infrastructure bill. The architecture solves real problems but not all of them.
This guide answers the question “what is active-active replication?” in practical terms. You’ll see how synchronous and asynchronous modes change your RPO and which scenarios actually justify a multi-writer setup. You’ll also learn where simpler options win, how different databases and platforms handle concurrent writes, and why virtualized workloads on OpenShift need a separate disaster recovery model.
What Is Active-Active Replication?
How Active-Active Replication Works
Active-active replication is a multi-primary (also called multi-master) configuration. Every node is live, accepts both reads and writes, and propagates each change to every other node in the cluster. This differs from single-primary streaming replication, the default pattern in PostgreSQL and MySQL, where one node handles all writes and replicas simply follow its log.
Since any node can accept traffic, a load balancer sits in front of the cluster and distributes requests across healthy members. The most common distribution methods are listed below:
- Round-robin: Requests rotate evenly through each available node in sequence.
- Weighted distribution: Nodes with more capacity receive a proportionally larger share of traffic.
- Least-connections: Each new request goes to the node currently handling the fewest active sessions.
Health checks matter as much as the algorithm itself. When a node stops responding, the balancer removes it from rotation, and the remaining nodes continue accepting writes with no promotion step required.
Active-passive designs work differently, keeping a standby node that takes over only after a failover event. For a full architectural comparison, see our guide on active-active vs. active-passive. Keep in mind that either approach improves availability, but neither replaces point-in-time recovery, a distinction covered in our article on high availability vs. disaster recovery.
An active-active database lets every node commit writes locally, then replicates those changes to its peers. More writers means more opportunities for the same record to change in two places at the same time.
Synchronous vs. Asynchronous Replication
With synchronous replication, a node confirms a write only after at least one replica acknowledges it. This guarantees zero data loss, but every commit waits on the network. The greater the distance between nodes, the longer that wait becomes, and a cross-continent round trip adds measurable latency to every transaction.
Asynchronous replication confirms the write locally and sends it to peers afterward. Local performance improves, but you accept replication lag in exchange. If a node fails before its changes spread, those writes are lost, and users connected to another node may read stale data in the meantime.
The right choice depends on your recovery point objective (RPO). If the business cannot tolerate losing a single transaction, synchronous replication is the only option, which typically restricts you to nodes within the same metro area. In practice, most cross-region active-active deployments run asynchronously. Apache Cassandra is a well-known example: each data center accepts writes locally, and the cluster converges on a consistent state over time through eventual replication.
Protect Your Openshift Virtualization Workloads With Confidence
Protect workloads with storage-agnostic disaster recovery built for OpenShift Virtualization
Achieve near-zero RPO with automated failover and policy driven recovery
Perform non-disruptive DR testing across hybrid and multi-cloud environments
Do You Actually Need Active-Active Replication?
Active-active replication is an architectural commitment, and it deserves the same scrutiny as any other. It solves a narrow set of problems very well. Adopted without one of those problems, it becomes a permanent cost to your team’s time, your budget, and your on-call rotation.
When Active-Active Replication Is Worth It
Start with the requirement, then choose the architecture. If you can’t name the specific failure scenario a multi-writer design protects against, you probably don’t need one. Availability targets are a useful reality check. Each additional “nine” sharply reduces the downtime you’re allowed: 99.9% uptime allows about 44 minutes of downtime per month, but at 99.999%, that budget drops to roughly 26 seconds.
Less than half a minute leaves no room for a manual failover, and that is where multi-writer designs justify their cost. The following scenarios are the legitimate reasons to run an active-active database:
- Five-nines targets across regions: Even an automated promotion of a standby takes longer than the monthly downtime budget allows.
- Regional or cloud-provider outages: Transactions must keep committing while an entire region is unreachable.
- Globally distributed users: Customers on every continent need to write data even if one region goes down.
- Edge or intermittently connected sites: Retail stores, factories, and ships must accept writes locally and reconcile once connectivity returns.
- Migration from legacy multi-master systems: Applications built on Oracle RAC or Oracle GoldenGate already assume multiple writable nodes.
When Active-Active Replication Is Not the Right Fit
Teams often assume that a multi-writer setup makes writes faster, but under strong consistency, it does not. A write accepted in Frankfurt still needs confirmation from Virginia before it commits, and the speed of light sets a hard floor on that round trip. The benefit is write availability during failure. Lower write latency is only possible if you accept eventual consistency and the conflicts that come with it.
The ongoing costs are significant. Operational complexity grows quickly: conflict resolution rules, replication lag monitoring, schema changes coordinated across every writer, and failure modes that appear only under concurrent load. Memory overhead increases because each node tracks replication state, change logs, and conflict metadata. Licensing and infrastructure spend rise as well since every node must be sized for full production traffic instead of sitting as an idle standby.
Replication also does not replace backups. An accidental deletion, corrupted record, or ransomware-encrypted table replicates to every writer within seconds. Point-in-time recovery still depends on independent copies.
For many teams, simpler patterns meet the actual requirement. Regional read replicas reduce read latency for distributed users without introducing write conflicts. Geographic sharding keeps each user’s writes local to a single primary. Active-passive with automated failover provides reliable recovery at a fraction of the operational burden when your downtime budget is measured in minutes rather than seconds.
Finally, confirm that your engine supports multi-writer replication at all. Some do not. Certain search and analytics stacks, for example, replicate indices only in a leader-follower model, so index-level active-active is not an option without building custom dual-write logic into the application.
Active-Active Replication Across Databases and Platforms
The success of active-active replication depends largely on the engine underneath it. Some systems were built for multiple writers from the start. Others gained that capability later, and their origins still shape how they handle conflicts, recover from failures, and behave in daily operations.
Active-Active in Databases
Relational engines were designed around a single writer, so multi-primary support typically comes through extensions or add-on products. PostgreSQL illustrates this well. According to AWS’s announcement of open-source pgactive, the extension provides asynchronous active-active replication between instances, including writers in different regions, and builds on PostgreSQL’s ongoing logical replication work, such as bidirectional replication between tables starting in version 16. Oracle environments generally rely on GoldenGate bidirectional replication with configured conflict detection and resolution rules. MySQL offers a multi-primary mode in Group Replication, although many teams still run it in single-primary mode to avoid write conflicts. For a broader comparison of tooling options, see this overview of database replication software.
Distributed systems such as Cassandra, CockroachDB, and Aerospike follow a different model. Multi-node writes are central to their architecture, so an active-active database of this type handles conflicts directly in the storage layer.
That storage layer generally uses one of three strategies. Last-writer-wins compares timestamps and keeps the most recent value, which is simple but can silently discard a concurrent update. CRDTs (conflict-free replicated data types) merge concurrent changes mathematically, allowing counters and sets to converge without losing writes. Quorum or consensus protocols such as Raft, which CockroachDB uses, require a majority of replicas to agree before a write commits, accepting added latency in exchange for correctness.
Beyond Databases: Streaming, Caching, and Stateful Workloads
Streaming platforms face the same challenge. Apache Kafka and Amazon MSK can run active-active across regions, but bidirectional mirroring without safeguards creates replication loops where each event cycles between clusters indefinitely. MirrorMaker 2 prevents this through topic prefixes. The following steps outline how teams typically configure it:
- Deploy regional clusters: Run an independent Kafka or MSK cluster in each region, and assign each one a unique alias such as “us-east” or “eu-west.”
- Configure bidirectional flows: Set up MirrorMaker 2 replication in both directions between the clusters.
- Retain the default replication policy: This policy prefixes mirrored topics with the source alias (for example, “us-east.orders”), so events are never mirrored back to their origin.
- Route producers and consumers: Point producers at local topics, and subscribe consumers to both local and prefixed remote topics using a regex pattern.
- Monitor lag and offsets: Track replication lag and checkpoint-based offset translation so consumers can resume in the other region after a failure.
This sequence gives every region full write access while keeping event flows predictable and straightforward to audit.
Caching layers require their own coordination. When a record changes in one region, stale entries in other regions must be invalidated, usually through change-data-capture events or pub/sub messages. Without that step, users can see outdated data even when the database itself is accurate.
Stateful workloads on Kubernetes, OpenShift, and OpenStack raise the stakes further. Replicating storage blocks on their own will not produce a recoverable workload. Recovery also depends on persistent volume claims, secrets, config maps, custom resources, and network definitions. VM-level workloads extend that list with disk images, boot order, and network identity. None of these components fit a row-level conflict resolution model, which is why virtualized workloads call for a dedicated replication and failover approach rather than database-style active-active.
Replication-Based Disaster Recovery for Kubernetes and Virtualized Workloads
Active-active designs work well when the database or application can reconcile concurrent writes on its own. Virtual machines running on Kubernetes lack that capability, so protecting them calls for a different recovery model built around a single active copy and a ready standby.
Why VM and OpenShift Workloads Need a Different Approach
If you’re asking what active-active replication is, the short answer is that it’s a pattern that lives at the database and application layer. An active-active database depends on software that detects conflicts, merges changes, and routes writes between nodes. A typical VM has none of that logic. It runs a legacy app, a file server, or a vendor appliance that expects to be the only writer to its disk, and two live copies of that VM would corrupt data. The platform also has a gap: KubeVirt VMs running in OpenShift Virtualization ship with no built-in disaster recovery.
For VM-level workloads, the practical answer is block-level replication to a standby site paired with automated failover orchestration. This is an active-passive DR design. When the primary site goes down, the orchestration layer handles three jobs: it starts VMs in dependency order, reassigns networks, and cuts DNS over to the recovery site.
Replication on its own won’t restore service. Failover only delivers value when detection and promotion are automated and tested on a regular schedule. Our guide to automatic failover explains how to set that up, and it helps to plan the return trip as well, since failover and failback each carry their own requirements.
The table below compares the two models across the factors that matter most when choosing a protection strategy for a given workload.
Learn why A leading player in the telecommunications industry chose Trilio for their Backup
| Factor | Active-Active Replication | VM-Level Replication DR |
|---|---|---|
| Layer | Database or application | Block storage and VM state |
| Writers | Multiple, concurrent | One active site, one standby |
| Conflict handling | Required | Not needed |
| Recovery trigger | Load balancer removes failed node | Orchestrated failover with ordering, network, and DNS changes |
| Best fit | Conflict-aware distributed data | KubeVirt VMs and legacy applications |
Disaster Recovery for OpenShift VMs with Trilio Site Recovery
Trilio Site Recovery is built for this VM-level DR model. It is a Red Hat certified operator, installed through OperatorHub, that runs across a management cluster, a primary site, and a DR site. Protection policies are defined as Kubernetes CRDs, and each workload tier can carry its own RPO target. Since policies live in Git, teams can apply them through ArgoCD, Flux, or Red Hat ACM, with the commit history serving as the audit trail.
Synchronous block-level replication keeps standby VMs current with near-zero RPO, while asynchronous replication covers tiers with looser recovery targets. Replication runs at the kernel level with no agent inside the VM. It works with any storage backend and writes data in non-proprietary formats, which keeps you free of vendor lock-in.
A standby copy is only useful if it comes back consistent. Crash-consistent disks can bring back a database that refuses to start.
You can trigger a failover through an API, a webhook, or a monitoring integration. Trilio then sequences VM startup, reassigns networks, and switches DNS, with RTO under five minutes. Each run follows pre-validated runbooks and supports rollback. Pre- and post-failover hooks pause database writes and flush them to disk, producing application-consistent recovery. Isolated test environments built from replicated snapshots let you confirm DR readiness and generate compliance reports without touching production. A single control plane provides multi-tenant views, RBAC, and per-tenant reporting across all of your OpenShift clusters. Explore Trilio Site Recovery to see how this works in practice.
Conclusion
Teams often jump straight to the most complex option when the better starting point is the failure scenarios you actually need to survive. Active-active replication justifies its cost when a workload must keep accepting writes during a regional outage, and the data layer can resolve conflicts without manual intervention. An active-active database makes sense in that narrow case. For most other workloads, read replicas, sharding, or a carefully tested active-passive setup will hit the same availability target with much less operational burden. Virtual machines need separate treatment because they depend on a single writer, consistent block-level copies, and an orchestrated failover process.
Start with a workload inventory. List every application, record its true RPO and RTO, and note whether it can handle concurrent writers. Then assign each one the simplest pattern that satisfies those requirements. After that, put a failover test for your most critical tier on the calendar this quarter. Until you run it, your recovery plan remains unverified.
FAQs
How many nodes do you need for an active-active replication setup?
Two nodes are the technical minimum, but consensus-based systems typically need at least three so a majority can still agree on writes if one node fails. Cross-region deployments often place three or more nodes per region to survive both local and regional failures.
What causes write conflicts in a multi-master database?
Conflicts occur when two nodes modify the same record before either change has replicated to the other, which is most common under asynchronous replication with high lag. Designing schemas so each region owns distinct records or using unique ID ranges per node greatly reduces how often they happen.
Is active-active replication more expensive than active-passive?
Usually, yes, because every node must be provisioned for full production load, and licensing, network transfer, and engineering time for conflict handling add further cost. Active-passive standbys can often run on smaller or reserved capacity until a failover occurs.
How do you test an active-active database before going to production?
Simulate concurrent writes to the same records from different regions, inject network partitions, and kill nodes under load to confirm that conflict resolution and health checks behave as expected. Chaos engineering tools and replication lag dashboards help reveal failure modes that only appear under real traffic patterns.
Can active-active replication protect against ransomware?
Active-active replication spreads encrypted or deleted data to every node almost immediately, so it offers no protection against ransomware. Recovery requires immutable, isolated backups that let you restore to a point before the attack occurred.
