Database Replication: Synchronous, Asynchronous, and Multi-Master Models

Database replication is the mechanism by which data written to one database node is propagated to one or more additional nodes, maintaining consistency across distributed systems. This page maps the three dominant replication models — synchronous, asynchronous, and multi-master — covering their internal mechanics, causal drivers, classification boundaries, and the engineering tradeoffs that determine which model applies under which conditions. The distinctions carry direct consequences for data durability, write latency, conflict resolution, and recovery point objectives in production environments. Engineers, architects, and database administrators navigating replication decisions will find this a structured reference grounded in named standards and verifiable classification criteria.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix
• References

Definition and scope

Database replication is the controlled duplication of data across two or more nodes in a distributed system, with the goal of improving availability, fault tolerance, read scalability, or geographic distribution of data access. The National Institute of Standards and Technology (NIST) acknowledges replication as a core component of data availability architecture within its Special Publication 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems), which designates data replication as a Category 1 recovery strategy alongside backup and redundant site provisioning.

The scope of replication spans three principal deployment contexts:

1. High-availability clustering — where replication ensures a standby node can assume the primary role within a defined recovery time objective (RTO), typically measured in seconds to minutes.
2. Read scaling — where replica nodes serve read queries, distributing load away from the primary write node.
3. Geographic distribution — where replicas are placed in geographically distinct data centers to reduce latency for regional users or satisfy data residency requirements under frameworks such as the California Consumer Privacy Act (CCPA) or sector-specific federal regulations.

The Database Systems Authority treats replication as a foundational infrastructure discipline, distinct from backup (which captures point-in-time snapshots) and distinct from caching (which stores derived or computed results rather than authoritative data).

Core mechanics or structure

All replication systems share a common structural sequence: a change event occurs at a source node, that event is captured in a change log (variously called a write-ahead log, binary log, or redo log depending on the database engine), and the log record is transmitted to one or more destination nodes where it is applied.

Synchronous replication requires that the primary node receive acknowledgment from every designated replica before confirming the write as committed to the originating client. The transaction is held open until all replicas respond. This guarantees zero data loss on failover — a Recovery Point Objective (RPO) of zero — because no committed transaction exists only on the primary. The PostgreSQL documentation for synchronous replication, maintained under the PostgreSQL Global Development Group, defines this as requiring synchronous_commit = on combined with a named synchronous_standby_names list before the COMMIT acknowledgment returns to the client.

Asynchronous replication allows the primary to acknowledge the write immediately after the transaction is committed locally, without waiting for any replica to confirm receipt. The change log is transmitted to replicas on a best-effort or scheduled basis. This produces a replication lag — the interval between a write occurring on the primary and appearing on replicas — that can range from milliseconds to seconds under normal conditions, and extend to minutes or longer during network partitions or replica overload.

Multi-master replication (also called active-active replication) permits writes to be accepted at two or more nodes simultaneously. Each node acts as both a source and a destination. Changes originating at one master are replicated to all other masters. Because concurrent writes to the same rows at different nodes can produce conflicts, multi-master systems require a conflict detection and resolution layer — either deterministic (last-write-wins based on a vector clock or timestamp) or application-directed (conflict surfaced to application logic).

The IEEE Computer Society's Software Engineering Body of Knowledge (SWEBOK v4) classifies distributed data management, including replication topology design, within the data management knowledge area of software engineering professional practice (IEEE SWEBOK v4).

Causal relationships or drivers

The choice of replication model is causally determined by four primary system requirements:

RPO requirements. Regulatory frameworks and service-level agreements that mandate zero data loss — common in financial services under the Federal Financial Institutions Examination Council (FFIEC) IT Examination Handbook — drive adoption of synchronous replication despite its latency cost. The FFIEC IT Examination Handbook, Business Continuity Management booklet specifies that institutions should define RPO as a contractual commitment, not merely an engineering target.

Write latency tolerance. Synchronous replication adds a round-trip network latency penalty to every write operation. A round-trip latency of 2 milliseconds between two data centers in the same metropolitan area imposes a minimum 2-millisecond overhead on every committed write. Cross-continental deployments with 70–100 millisecond round-trip latencies render synchronous replication operationally impractical for high-throughput workloads.

Read scalability demand. Workloads with read-to-write ratios exceeding 10:1 — common in analytics, content delivery, and reporting systems — benefit from asynchronous read replicas that absorb query volume without affecting write throughput on the primary.

Write distribution requirements. Applications serving users across geographically separated regions where write latency to a single primary would be unacceptable (exceeding 150–200 milliseconds in interactive applications) create demand for multi-master topologies, accepting the complexity of conflict resolution in exchange for local write acknowledgment.

Classification boundaries

Replication models are classified along two orthogonal axes: acknowledgment timing (synchronous vs. asynchronous) and write topology (single-master vs. multi-master). These axes produce four logical cells, though one — synchronous multi-master across a wide-area network — is rare in production due to the compounding latency of requiring acknowledgment from geographically distributed write-capable nodes before every commit.

Semi-synchronous replication occupies a defined intermediate classification. MySQL's implementation, documented in the MySQL 8.0 Reference Manual, requires acknowledgment from at least 1 replica (not all replicas) before the primary confirms the commit. This limits data loss to a bounded window — no more than the transactions committed since the last acknowledgment — rather than eliminating loss entirely or allowing unbounded lag.

Cascading replication describes a topology where a replica replicates to downstream replicas, rather than all replicas sourcing directly from the primary. This reduces primary load but introduces additional lag at each replication tier. It is classified as an asynchronous topology variant, not a distinct replication model.

Logical vs. physical replication is a separate classification dimension that cuts across all three timing models. Physical replication transmits byte-level block changes; logical replication transmits row-level change events decoded from the write-ahead log. PostgreSQL's logical replication documentation distinguishes these as affecting which workloads can subscribe (logical replication permits cross-version and cross-schema subscriptions; physical replication requires identical major versions).

Tradeoffs and tensions

The fundamental tension in replication is between consistency and availability, formalized in the CAP theorem (Consistency, Availability, Partition tolerance) published by Eric Brewer in 2000 and later refined in the PACELC model by Daniel Abadi in 2012 in ACM's computing literature. No distributed system can simultaneously guarantee consistency, availability, and partition tolerance; replication model selection is the mechanism by which system architects express where they accept compromise.

Synchronous replication trades write latency for consistency guarantees. The tradeoff is not merely performance: a synchronous replica that becomes unavailable (network partition, node failure) either blocks all writes (preserving consistency) or must be removed from the synchronous acknowledgment list (degrading durability guarantees). PostgreSQL's synchronous_commit = remote_apply mode represents the strictest form, requiring that the replica not only receive but apply the transaction before acknowledgment, adding apply time on top of network round-trip.

Asynchronous replication trades consistency for availability and performance. The risk is replication lag amplification under load: as write throughput on the primary increases, replicas applying changes serially fall progressively further behind. A replica running 30 seconds behind during normal operation may fall 10–15 minutes behind during a traffic spike, producing stale reads that may violate application correctness requirements.

Multi-master replication introduces conflict probability proportional to the overlap between concurrent write sets across masters. Systems with low inter-master write overlap (e.g., geographically sharded user data where each master owns a distinct user partition) experience near-zero conflicts. Systems with unsharded shared data written from multiple masters experience conflict rates that scale with concurrent write volume, placing operational burden on conflict resolution logic that is difficult to test comprehensively.

Common misconceptions

Misconception: Asynchronous replication means data is at risk. The accuracy of this claim depends entirely on the workload. For read replicas where the replica is not in the failover path, asynchronous lag has no durability consequence — the primary retains all committed data. Risk materializes only when an asynchronous replica is promoted to primary before its lag has been flushed, which is an operational procedure failure, not an inherent property of the replication model.

Misconception: Multi-master replication eliminates single points of failure. Multi-master topology removes the single-primary write bottleneck but does not eliminate all failure modes. Split-brain scenarios — where network partition causes two masters to diverge without detection — represent a failure mode specific to multi-master systems and absent from single-master topologies. The NIST SP 800-34 Rev. 1 contingency planning framework specifically identifies split-brain as a recovery scenario requiring documented resolution procedures.

Misconception: Synchronous replication guarantees zero data loss across all failure scenarios. Synchronous replication guarantees that no committed transaction exists only on the primary — it does not protect against data corruption events that propagate synchronously to all replicas before detection, nor against logical errors (accidental DELETE statements) that replicate immediately and accurately to all synchronous standbys.

Misconception: Replication substitutes for backup. Replication propagates all changes, including destructive ones, in near-real-time. A point-in-time backup retains a recoverable state prior to a destructive event. These are complementary, not interchangeable, strategies — a distinction NIST SP 800-34 addresses by classifying them in separate recovery capability tiers.

Checklist or steps

The following sequence describes the phases of a replication architecture assessment, structured as discrete evaluation steps rather than prescriptive recommendations.

Phase 1: Requirements capture
- Document the Recovery Point Objective (RPO) as a time value (e.g., 0 seconds, 30 seconds, 5 minutes) established by the owning business unit or regulatory obligation.
- Document the Recovery Time Objective (RTO) separately from RPO.
- Identify whether replicas are required for read scaling, failover, or both.
- Determine whether write distribution across geographic regions is a functional requirement.

Phase 2: Topology scoping
- Measure the round-trip network latency between proposed primary and replica locations.
- Measure the sustained write transaction rate (transactions per second) on the primary workload.
- Calculate the minimum synchronous replication overhead: (round-trip latency) × (peak write TPS) = minimum latency budget required per transaction under synchronous mode.
- Determine whether the write TPS and latency budget are compatible with synchronous acknowledgment requirements.

Phase 3: Conflict surface analysis (multi-master only)
- Identify all tables or row sets subject to concurrent writes from multiple application entry points.
- Classify each write pattern as partition-safe (no cross-master overlap possible) or conflict-eligible (concurrent cross-master writes possible).
- Document the conflict resolution strategy for each conflict-eligible write pattern: last-write-wins, application-level arbitration, or operation-specific merge logic.

Phase 4: Monitoring specification
- Define the replication lag threshold that triggers an operational alert (e.g., lag exceeding 10 seconds).
- Define the replication lag threshold that triggers a read-replica exclusion from the application connection pool.
- Specify the procedure for verifying replica data integrity, including checksum-based consistency verification intervals.

Phase 5: Failover procedure documentation
- Document the promotion sequence for each replica type, including pre-promotion lag verification steps.
- Specify the minimum RPO verification check before promoting an asynchronous replica to primary.
- Define the post-failover replication rebuild procedure for demoted or recovered nodes.

Reference table or matrix

Professionals assessing replication cost implications alongside architecture decisions may reference the cloud hosting cost estimator to model the infrastructure footprint of multi-node replication topologies across cloud providers.

The website performance impact calculator provides a complementary lens for quantifying how replication lag in read-replica topologies translates into application-layer read staleness and latency distribution.

Database providers and managed service operators offering replication infrastructure can find structured listing criteria at for providers.

References

• NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems
• NIST Computer Security Resource Center (CSRC)
• IEEE SWEBOK v4 — Software Engineering Body of Knowledge
• FFIEC IT Examination Handbook — Business Continuity Management Booklet
• PostgreSQL Global Development Group — Warm Standby and Synchronous Replication
• PostgreSQL Global Development Group — Logical Replication
• MySQL 8.0 Reference Manual — Semi-Synchronous Replication