Database replication: acknowledgement, visibility, failover, and fencing

Replication is several contracts, not one checkbox: where a write is durable when success returns, when a standby has replayed it, which replica may serve a session read, how a leader is elected, and how the old writer is fenced. Each contract has a different threshold and failure path.

PostgreSQL synchronous replication can wait for a priority (FIRST) or quorum (ANY) number of named synchronous standbys. There is no built-in synchronous_commit_timeout that automatically and safely downgrades a blocked commit to asynchronous success. An operator may explicitly change configuration or cancel work, but that is a policy transition with changed durability.

Модель и предпосылки

• Client success means only the configured acknowledgement condition was met; timeout is an unknown outcome until reconciled.
• Receipt, durable flush, and replay/apply are different positions. Read-your-writes needs writer routing or an LSN/session barrier.
• Election chooses an eligible log; fencing removes old write authority before the endpoint moves.

Проверяемые утверждения

• C1. PostgreSQL FIRST n waits for priority standbys and ANY n waits for a quorum count; neither universally means every listed standby.
• C2. remote_write, on, and remote_apply represent different acknowledgement/visibility stages.
• C3. If required synchronous standbys disappear, commits can wait indefinitely; PostgreSQL does not automatically downgrade through a synchronous_commit_timeout parameter.
• C4. A majority-based leader protocol protects log safety only under its assumptions; external write authority still needs fencing.
• C5. Leaderless quorum intersection such as R + W > RF is a different model from PostgreSQL streaming standby acknowledgement.

Исполняемые сценарии

Quorum synchronous acknowledgement. ANY 1 of two candidates is an explicit example; success means that threshold, not replay everywhere.

Required synchronous standby loss. A commit can block until a standby returns or an explicit operator policy changes; there is no automatic timeout downgrade.

Asynchronous RPO window. Local success can precede DR receipt, so an acknowledged write can be absent after a primary-site loss.

Read-after-write replay barrier. Standby receipt is insufficient; routing waits for apply position or returns to the writer.

Fenced failover. An eligible candidate is promoted only after the old writer loses write authority; then the endpoint moves.

Ошибки проектирования

• Не отвечайте success после timeout как будто commit точно откатился; сначала reconcile по operation id или transaction status.
• Не отправляйте read-after-write на случайную standby без replay barrier.
• Не переключайте sync на async автоматически и молча: durability contract и RPO изменились.
• Не переносите endpoint до fencing старого writer; health check не отнимает право писать.

Границы гарантии

• Synchronous acknowledgement не заменяет backup, restore testing и protection от logical corruption.
• RPO/RTO — измеренные свойства конкретного failover и recovery procedure, не фиксированные числа из диаграммы.
• Cross-region latency, storage flush behavior and network topology are part of the commit path.

Связанные материалы

Официальные и первичные источники

1. PostgreSQL: Log-Shipping Standby Servers
2. PostgreSQL: Replication Configuration
3. PostgreSQL: WAL Configuration
4. Ongaro and Ousterhout, Raft
5. Apache Cassandra: Dynamo architecture and tunable consistency