WAL (Write-Ahead Log)

Зачем

WAL (Write-Ahead Log) — фундамент durability у всех серьёзных СУБД, очередей и распределённых движков. Идея простая до банальности: прежде чем менять данные на диске, запиши намерение в append-only журнал и сделай fsync — только потом отвечай клиенту OK. Из этой одной инвариантности вырастает почти всё, что мы считаем "взрослой" базой данных:

• Crash recovery — после kernel panic / power loss БД проигрывает WAL с последнего checkpoint и восстанавливает состояние, как будто ничего не было.
• ACID-D — гарантия, что коммитнутая транзакция переживёт любой crash (если fsync честный).
• Физическая репликация — стримим WAL на standby, тот реплеит — получаем горячую копию.
• Логическая репликация / CDC — Debezium, Maxwell, pgoutput читают WAL и эмитят events ("row changed: before/after").
• PITR (Point-In-Time Recovery) — реплей WAL до конкретного timestamp / LSN.
• 2PC / distributed tx — prepared records в WAL переживают рестарт координатора.

Без WAL нет ничего из этого. С WAL — есть Postgres, MySQL InnoDB, RocksDB, Kafka log, etcd, Spanner, ext4 journal, NTFS USN journal. Одна и та же идея.

Mental model

"Сначала пиши то, что собираешься сделать, в журнал. fsync. Только потом делай. При crash — догоняй журнал с последней безопасной точки."

Три ключевых инварианта:

1. WAL-before-data: log record с LSN=X должен быть на диске (fsync) раньше, чем dirty data page с pageLSN=X уйдёт на диск. Это правило (Write-Ahead Logging rule из ARIES) — основа корректности recovery.
2. Append-only sequential I/O: WAL пишется в один файл подряд. Это превращает random writes в data files (медленные на HDD, неприятные даже на NVMe) в sequential writes в журнал (близко к bandwidth диска).
3. Checkpoint = граница recovery: точка, после которой все ранее dirty pages flushнуты. WAL до checkpoint можно архивировать / удалять — он больше не нужен для crash recovery.

Что на диаграмме

Канвас показывает анатомию одного DBMS-процесса (Postgres-style) и его взаимодействие с диском:

• Backend (tx executor) — процесс, обслуживающий клиентскую транзакцию. Модифицирует страницы в shared buffers и пишет WAL-записи в WAL buffer.
• WAL buffer — небольшой кольцевой буфер в RAM (по умолчанию wal_buffers=16MB в Postgres), куда падают новые WAL-записи перед flush.
• Shared buffers — страницы данных в RAM (8KB-блоки). Тут происходят все модификации; "dirty" страницы помечаются и остаются в RAM долго — на диск их пишет checkpointer.
• WAL writer / group commit — отдельный процесс/тред, который flushит WAL buffer на диск. Умеет батчить fsync для нескольких параллельных коммитов (group commit).
• Checkpointer — периодически (раз в checkpoint_timeout, по умолчанию 5 мин) проходит по dirty pages в shared buffers и flushит их в data files, затем обновляет redo LSN.
• pg_wal/... — собственно WAL-файл на диске, 16MB сегменты, append-only.
• base/.../relfilenode — data files (heap + indexes). Random writes, но редкие — только из checkpointer.

Edges показывают физические потоки I/O: клиент -> backend (SQL), backend -> shared_buf (modify), backend -> wal_buf (append), wal_writer -> wal_file (write + fsync), checkpointer -> data_file (flush pages). Обратный edge wal-file -> backend нужен для recovery-сценария (replay при старте).

Сценарии

Write path: классический WAL-протокол. Клиент шлёт UPDATE, backend модифицирует страницу в shared buffers (но НЕ на диске!), параллельно пишет WAL-запись {LSN, xid, page, before, after} в WAL buffer. На COMMIT добавляется commit-record, WAL writer делает write() + fsync() — это блокирующий вызов на ~100µs (NVMe с PLP) до ~5ms (consumer SSD). Только после успешного fsync backend возвращает клиенту ACK. Data page всё ещё dirty в RAM — на диск она попадёт позже, при следующем checkpoint. Это контр-интуитивно: WAL-запись на диске, а изменённая страница — нет. Но именно так и нужно: при crash мы реплеем WAL и восстановим страницу.

Crash + recovery. Power loss посреди работы — dirty pages в RAM исчезли, data files не обновлены. На рестарте postmaster читает pg_control, видит флаг "in production" => нужна recovery. Analysis phase: находит redo LSN последнего checkpoint. Redo phase: стримит WAL от redo LSN до конца, для каждой записи загружает page из data file и применяет изменение, если page.LSN < record.LSN (idempotent replay). Undo phase: в Postgres no-op (aborted txns остаются в heap, MVCC + vacuum уберут позже); в системах с in-place update (MySQL InnoDB) — настоящий undo через undo log. После recovery commit, который клиент видел до crash, на месте — durability honored.

Group commit: 1 fsync на 100 коммитов. Три бэкенда коммитят почти одновременно. Каждый пишет commit-record в WAL buffer и засыпает на fsync barrier. WAL writer ждёт commit_delay (100µs) или собирает commit_siblings (3+ ждущих) и делает один write() + fsync() для всех трёх. Один syscall = ~100µs на NVMe, амортизированная стоимость fsync — ~33µs/tx вместо 100µs/tx. На write-heavy workload (1000 параллельных коммитов в группе) можно выжать 100k tx/sec на одном NVMe без потери durability. Тот же приём в MySQL (binlog group commit + 2PC prepare/commit), в RocksDB (WriteBatch + JoinBatchGroup), в Kafka producer (linger.ms).

synchronous_commit=off: 5× throughput, окно потери до 200ms. WAL пишется в WAL buffer, ack возвращается клиенту немедленно без ожидания fsync. WAL writer раз в wal_writer_delay (200ms) batch-флашит накопленное. Latency коммита падает с ~500µs до ~10µs, throughput — в 2-5×. Цена: power loss до следующего background flush => последние ~200ms коммитов потеряны, хотя клиенты видели ACK. Это сценарий нарушения durability — он допустим только когда данные восстановимы (analytics, audit, staging), и категорически не подходит для payments / orders / inventory. Альтернатива противоположного полюса — synchronous_commit=remote_apply: ждём fsync на standby тоже (+1ms RTT), переживёт даже одновременный crash master + disk failure.

Trade-offs (ADR)

ADR-001 на ноде backend разбирает главный практический выбор: synchronous_commit=on (group commit) vs synchronous_commit=off. Открой её на канвасе — там полный контекст про fsync-стоимость (NVMe PLP ~50µs, consumer SSD без PLP 1-5ms, HDD 5-10ms), про group commit как способ амортизировать fsync до 100k tx/sec без потери durability, и про когда осознанно нарушать ACID-D.

Дополнительные trade-offs, которые не оформлены отдельным ADR, но критичны:

• full_page_writes=on/off — защита от torn page (page разорван между блоками 4KB на NVMe). С on — первая модификация страницы после checkpoint логирует всю страницу (8KB) в WAL вместо delta. WAL пухнет 2-5×, но переживает torn page. Off безопасно только если у тебя ZFS/btrfs (CoW), либо ты уверен в atomicity 8KB write на железе. Дефолт — on, не трогай без понимания.
• wal_compression — pglz/zstd компрессия full-page images. Снижает WAL volume на 50-70%, стоит 5-10% CPU. На write-heavy включай.
• max_wal_size / checkpoint_timeout — чем реже checkpoint, тем меньше I/O spikes, но дольше recovery после crash. Дефолт 5 мин — компромисс; на high-write OLTP можно 15-30 мин (терпишь долгий recovery ради smooth I/O).
• archive_mode + archive_command — обязательно для PITR. WAL-сегменты копируются в S3/GCS, потом можно проиграть до любой точки.

Реальные системы

• PostgreSQL — pg_wal/ directory, 16MB сегменты, formats описаны в xlogrecord.h. Logical decoding (pgoutput, wal2json) — основа Debezium / Supabase Realtime / встроенной logical replication.
• MySQL InnoDB — двойной журнал: redo log (ib_logfile*, физический, для recovery) + binlog (логический, для replication). innodb_flush_log_at_trx_commit=1 ≈ Postgres synchronous_commit=on. 2PC между InnoDB и binlog — источник сложности и багов (см. известные кейсы потери транзакций при некорректном sync_binlog).
• RocksDB / LevelDB — WAL (*.log файлы) + memtable + SSTables. На startup WAL реплеется в memtable. Cassandra использует RocksDB-style commitlog.
• Kafka — broker log сам по себе WAL: append-only сегменты, fsync через flush.messages / flush.ms. Consumers читают WAL "наоборот" — это и есть весь продукт.
• etcd / ZooKeeper — WAL для Raft/ZAB log. Каждая Raft-запись fsyncнута до того, как лидер вернёт OK клиенту.
• Spanner / CockroachDB — Raft log на уровне range; physical replication через Raft вместо стриминга WAL.
• Файловые системы — ext4 journal (метаданные), XFS log, NTFS USN journal, ZFS ZIL. Та же идея, тот же fsync.

Anti-patterns

• fsync через app-level wrapper, который "иногда" вызывается — половина "своих БД" на коленке пишут в файл и надеются, что OS сама всё сольёт. Не сольёт. Без явного fsync() (или O_DSYNC) page cache потеряется при power loss.
• Доверять fsync на consumer SSD без power-loss protection (PLP) — дешёвые SSD врут о completion fsync (DRAM cache не имеет supercap). Reality check: pg_test_fsync или diskchecker.pl от Postgres community. На bare-metal с критичными данными — только enterprise SSD с PLP или RAID-контроллер с battery.
• WAL на той же физической оси/девайсе, что и data files — sequential writes WAL начинают конкурировать с random writes checkpoint-а, latency tail взрывается. Отдельный диск под WAL (pg_wal на отдельном tablespace) — классическое tuning-решение для high-write OLTP.
• Игнорировать archive_command failures — если archive ломается, WAL накапливается, диск переполняется, БД встаёт. Алерт на archive lag — must-have.
• Чрезмерно агрессивный checkpoint (checkpoint_timeout=30s) — каждый checkpoint — большая I/O волна. На write-heavy получишь постоянные стоны latency. Лучше реже + tune checkpoint_completion_target=0.9 (размазать flush во времени).
• fsync=off "для скорости" в production — это synchronous_commit=off × 1000. Полный отказ от durability. Используется только в эпhemeral test setups / build serverах.

Когда НЕ использовать

WAL — это всегда правильно для stateful durable хранилищ. Вопрос скорее "когда можно без него" или "когда WAL не нужен в твоём слое":

• Кеши (Redis без AOF, Memcached) — данные эфемерны, теряются при рестарте by design. AOF (Redis) — это и есть WAL, включается опционально.
• Stateless серверы / API — нечего журналить, состояние в БД (у БД свой WAL).
• Pure compute pipelines (Spark, Flink в batch-mode) — input восстанавливается из upstream, intermediate state не критичен. Streaming Flink использует чекпоинты + WAL только для state backends.
• Read-only replicas из snapshot — данные приходят извне через replication, свой WAL не нужен (хотя физически у Postgres standby всё равно есть WAL).
• Embedded analytics на immutable data (DuckDB на parquet) — нет mutability, нет recovery, нет WAL.

И обратное: если у тебя есть mutable state, который пользователь считает сохранённым после ACK — у тебя должен быть WAL. Либо ты его написал, либо используешь систему, которая написала за тебя. Третьего не дано.

Дальше читать

• DDIA Ch.3 (Storage and Retrieval), Ch.5 (Replication) — Kleppmann, обязательное чтение по теме.
• ARIES paper — Mohan et al. 1992, "ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging". Канон. Все современные WAL — её потомки.
• PostgreSQL docs: WAL Internals, Reliability and the Write-Ahead Log, pg_test_fsync.
• "Files are Hard" — Dan Luu / Pillai et al. ("All File Systems Are Not Created Equal", OSDI'14). Почему fsync обманчив на практике.
• RocksDB Wiki: WAL Recovery Modes — практическая сторона tuning durability vs throughput.
• Postgres source: src/backend/access/transam/xlog.c, xlogrecord.h — если хочется увидеть, как это реально написано.

Связанные концепты:

• [CONCEPT]database-internals-overview
• [CONCEPT]cap-theorem

Применяется в кейсах: см. любой кейс с Postgres / MySQL / Kafka — WAL под капотом везде.