WAL

WAL (Write-Ahead Log) — журнал упреждающей записи. Прежде чем изменить данные на диске — записать в лог. Основа durability (D в ACID), crash recovery, репликации во всех современных БД.

Правило

Write to log BEFORE writing to data. Flush log BEFORE acknowledging commit.the WAL rule

Как работает

1. UPDATE users SET age=31 WHERE id=1
2. Change записан в WAL buffer (в памяти)
3. COMMIT → WAL flush(fsync) на диск
4. Клиенту "ok, closed"
5. Grid page ещё в shared_buffers (грязная)
6. Позже checkpoint — грязные страницы пишутся на диск
7. WAL можно обрезать до точки checkpoint

Что если сломался

  1. БД перезапускается
  2. Читает WAL с последнего checkpoint
  3. Redo: применяет все зафиксированные изменения
  4. Undo: откатывает незафиксированные (только для БД с undo log)
  5. Готово к работе

Реализации

БДНазвание
PostgreSQLWAL (pg_wal/)
MySQL InnoDBRedo log (ib_logfile*) + Undo log
SQLiteWAL или rollback journal
OracleRedo log
RedisAOF (append-only file) — аналог
Kafkaсам топик = commit log
MongoDBoplog + journal
ClickHouseReplicatedMergeTree WAL

Checkpoint

Периодически (каждые N MB WAL или N минут) БД сбрасывает всё грязное на диск и отмечает точку в WAL. Recovery начинается с последнего checkpoint — быстрее чем от нуля.

# PG: checkpoint_timeout=5min, max_wal_size=1GB
# InnoDB: innodb_log_file_size, innodb_max_dirty_pages_pct

Group commit

Много транзакций коммитятся одновременно → один fsync WAL на всю группу. Меньше IOPS, больше throughput.

WAL для репликации

WAL — источник истины. Streaming replication шлёт WAL-записи на реплики. Логическая репликация декодирует WAL в logical events (INSERT/UPDATE/DELETE).

# PG streaming
Мастер → walsender → сеть → walreceiver → реплика применяет

PITR — Point-in-Time Recovery

Base backup + WAL с момента backup = восстановление на любую точку. Основа PG PITR (pg_basebackup + wal-g/pgbackrest).

WAL bloat

См. также

← на главную