5 exercises on database replication — synchronous vs async, WAL shipping, logical replication, and failover.
0 / 5 completed
1 / 5
What is the key trade-off of synchronous replication?
Synchronous replication: the primary only commits after at least one standby has written the data to durable storage. This guarantees no data loss on failover but adds network round-trip latency to every write, which matters for high-throughput workloads.
2 / 5
What is WAL shipping in PostgreSQL replication?
WAL shipping: the primary archives completed WAL segments (each 16MB by default) and the standby fetches and replays them. There is inherent lag (at least one segment must fill). Streaming replication is preferred for lower lag, but WAL archiving is still used for point-in-time recovery.
3 / 5
What does logical replication offer that physical replication does not?
Logical replication: physical replication copies exact disk blocks — same major version and OS architecture required. Logical replication sends decoded row-level INSERT/UPDATE/DELETE events, allowing selective tables, filtering, and replication to different PostgreSQL major versions or other databases.
4 / 5
What is replication lag and why does it matter?
Replication lag: monitored via pg_stat_replication.write_lag / flush_lag / replay_lag in PostgreSQL. Applications routing reads to replicas must account for lag — queries requiring strong consistency should go to the primary.
5 / 5
What happens during a failover in a primary/replica setup?
Failover: tools like Patroni or repmgr automate this. They detect the primary failure, elect the most up-to-date replica, promote it, and update cluster state (DCS like etcd or Consul). The application may use a floating VIP or connection pooler to transparently redirect connections.