WAL и репликация на собеседовании Data Engineer

Зачем разбирать на собесе

Replication — основа HA / disaster recovery. На собесе DE: «как работает streaming», «отличия sync».

WAL: что это

Write-Ahead Log. Все changes сначала пишутся в log, потом в data files.

Зачем:

• Durability — после crash WAL replay restores DB.
• Replication — secondary apply WAL для sync.
• CDC через logical decoding.

Postgres: WAL files в pg_wal/. Размер segment — 16MB по дефолту.

Streaming replication

Postgres native — primary streams WAL bytes на replicas в real-time.

Setup:

1. Primary: archive_mode=on, max_wal_senders.
2. Replica: pg_basebackup initial → start streaming.
3. Replica reads WAL → applies → up-to-date.

Lag.

• В normal — millisecond.
• На high-write — seconds.
• При network issue — растёт.

Failover. Если primary падает — promote replica.

Logical replication

Replicates rows / changes (не bytes WAL).

Pros:

• Selective replication (subset tables).
• Different versions allowed.
• Cross-platform (Postgres → MySQL потенциально через tools).
• Не нужен binary compatibility.

Cons:

• DDL changes не replicated.
• Slower на huge writes.
• Не replicate sequences automatically (needed manual sync).

CDC tools (Debezium) — built на logical decoding.

Sync vs async

Async (default). Primary commits → returns OK → asynchronously replicate. Risk — на crash primary до replication, transaction lost (RPO > 0).

Synchronous. Primary waits replica acknowledge before commit. Higher latency, RPO = 0.

synchronous_commit = on
synchronous_standby_names = 'replica1'

Quorum sync. ANY 2 (replica1, replica2, replica3) — wait for 2 of 3.

Trade-off. Sync — слабее throughput, защита от data loss. Финансы — sync. Analytics — async.

Связанные темы

• Транзакции и MVCC для DE
• CDC и Debezium на собесе DE
• Greenplum на собесе DE
• Подготовка к собесу Data Engineer

FAQ

Это официальная информация?

Нет. Статья основана на документации Postgres.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.