openskills.info
Course catalog
Course Preview

Database Replication Strategies

Database replication keeps copies of database changes on more than one system. A replication strategy decides where writes happen, how changes travel, when a commit is acknowledged, and what readers may see when a replica lags or a node fails.

itDatabases and data storage

Database Replication Strategies

Database replication copies database changes from one server or region to another. The copies can improve availability, place reads near users, isolate reporting work, support migrations, or feed another system. A useful strategy specifies more than the number of copies. It defines who may accept writes, what is replicated, how changes are ordered, when a write is considered durable, how readers select a copy, and how a failed member returns.

Replication is not the same as backup. A replica normally receives valid changes and mistakes from its source. A dropped table, damaging update, or application bug can therefore reach every live copy. Independent backups and archived logs preserve earlier recovery points; replicas preserve a current or nearly current service path.

The replication path

A common primary-replica path has five stages:

  1. A client sends a transaction to the primary.
  2. The primary orders the transaction and records it in a durable change log.
  3. A transport sends log records or logical changes to one or more replicas.
  4. Each replica writes and applies the change to its local state.
  5. Acknowledgment and read-routing rules determine when the client receives success and which copy may answer later reads.

The change log gives replicas an ordered stream to follow. PostgreSQL physical streaming replication sends write-ahead log records. MongoDB secondaries copy and apply operations from the oplog. MySQL source-to-replica replication uses the binary log. The implementation differs, but the design questions are similar: how a replica starts, how it identifies its position, how long retained history remains available, and what happens when it falls behind that history.

Initial synchronization establishes the first complete copy. A replica then consumes incremental changes from a known position. If the source discards required log history before a disconnected replica returns, the replica usually needs a fresh snapshot or base backup. Retention protects recoverability, but retained logs also consume storage.

Continue the course

This section is part of the paid course.

See pricing to subscribe, or log in if you already have access.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources