Replication and WAL PostgreSQL Articles

One word took our nightly staging load from 40 minutes to 9: UNLOGGED. Two months later a failover emptied the table and nobody on call could explain why. The semantics are absolute — if someone tells you.

GTIDs make MySQL failover repointing almost trivial; replication slots make PostgreSQL WAL retention automatic but risky. A practitioner's comparison of the two position-tracking models.

MySQL grew failover tooling around topology repair; PostgreSQL grew it around consensus and leases. Comparing orchestrator and group replication with Patroni and repmgr, honestly.

full_page_writes protects you from torn pages but can dominate WAL volume. How checkpoints set the FPI rate, what wal_compression with lz4 or zstd buys you, and how to measure WAL with pg_stat_wal.

Both MySQL and PostgreSQL replicas serve stale data by default. What differs is the toolbox: GTID waits and group replication consistency levels versus LSN tokens and remote_apply.

A decommissioned standby left its replication slot behind, and over one quiet weekend the slot pinned 214 GB of WAL until the primary ran out of disk and PANIC'd. Here is the mechanism, the monitoring queries, and the circuit breaker that caps the damage.

MySQL replicates logical change events from the binlog; PostgreSQL streams physical WAL. That one design difference changes lag measurement, consistency guarantees, and what your replicas can be.

Debezium tailing a MySQL binlog and a PostgreSQL logical decoding pipeline look similar from Kafka. Underneath, snapshots, schema changes, and retention fail in opposite ways.

The 3 a.m. page was pg_wal at 100 percent on a healthy primary. The cause was a Debezium slot from a proof of concept eight weeks earlier, quietly pinning 380 GB of WAL nobody would ever read.

One word took our nightly staging load from 40 minutes to 9: UNLOGGED. Two months later a failover emptied the table and nobody on call could explain why. The semantics are absolute — if someone tells you.

MySQL grew failover tooling around topology repair; PostgreSQL grew it around consensus and leases. Comparing orchestrator and group replication with Patroni and repmgr, honestly.

full_page_writes protects you from torn pages but can dominate WAL volume. How checkpoints set the FPI rate, what wal_compression with lz4 or zstd buys you, and how to measure WAL with pg_stat_wal.

Both MySQL and PostgreSQL replicas serve stale data by default. What differs is the toolbox: GTID waits and group replication consistency levels versus LSN tokens and remote_apply.

Debezium tailing a MySQL binlog and a PostgreSQL logical decoding pipeline look similar from Kafka. Underneath, snapshots, schema changes, and retention fail in opposite ways.

A single unique violation on a logical replication subscriber can stall the stream and fill the publisher's disk with retained WAL. Here is how conflicts happen and how to recover.

Long analytics queries on our replica kept getting cancelled mid-run. Turning on hot_standby_feedback stopped the cancellations instantly — and then the primary started bloating. That trade is the whole story.

We scaled reads to a replica and started getting bug reports about data that 'disappeared' right after saving. The cause was replication lag, and the fix was being honest about which reads can tolerate it.

Write-heavy PostgreSQL systems usually fail through WAL pressure, checkpoint I/O, replication lag, or storage stalls. The fix starts with measuring the write path, not raising random knobs.

Logical replication is more flexible than physical and more fragile. Use it when you need partial replication, cross-version, or selective sync. Don't use it for HA.

Physical replication slots make sure replicas can catch up after a disconnect. They also make sure your primary's disk fills if a replica is gone and forgotten.

Read replicas are eventually consistent. The application's view of "after I wrote, my read should see it" is often wrong by milliseconds, sometimes by minutes.

Failover is mostly fine when you do not need it and broken when you do. Here is how to know which you have.

If your Postgres disk is growing and you cannot identify the culprit, replication slots are usually the answer. Here is the diagnostic sequence.

Replication monitoring is not one lag number. You need to know stale-read risk, slot retention, replay delay, WAL growth, and whether failover would help or hurt.

Aurora's replica lag has different mechanics than vanilla streaming replication. The dashboard metric "replica lag" can be misleading. Here is what it actually measures.

WAL problems usually look like disk problems too late. Monitor generation rate, checkpoints, archiving, replication lag, and slot retention before pg_wal owns the incident.