WAL, redo/undo и crash recovery¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: PostgreSQL 17, MySQL 8.4, Oracle 19c, Cassandra 5.0, Redis 7.4 и ClickHouse 25.8 либо явно названный сервис.

Механизм¶

Write-ahead означает: нужные log records устойчиво записываются до соответствующих data pages. Redo повторяет изменения после crash; undo поддерживает откат/старые версии там, где реализация его использует. PostgreSQL не имеет такой же undo segment модели, как Oracle/InnoDB.

flowchart LR
  Mutation --> Log[Append log record]
  Log --> Flush[Durable log flush]
  Flush --> Ack[Commit acknowledgement]
  Flush --> Pages[Data pages later]
  Log --> Replay[Crash redo and visibility recovery]

Операция чтения или записи по шагам¶

Transaction меняет buffer page и создаёт log records → WAL/redo flush по commit policy → ACK → dirty page flush позже. Crash между ACK и data flush восстанавливается redo при корректной durability. PG незакоммиченные tuples не видимы по transaction status; Oracle/InnoDB используют свои undo/recovery процедуры.

Консистентность, отказ и восстановление¶

Checkpoint ограничивает объём recovery, но не отменяет backup/WAL retention для PITR. Torn pages требуют конкретной защиты: PostgreSQL full-page writes/checksums и InnoDB doublewrite имеют разные роли. Checksums обнаруживают часть повреждений, не восстанавливают потерянные данные сами.

Выбор, эксплуатация и ограничения¶

Group commit амортизирует fsync; asynchronous commit снижает ожидание ценой возможной потери acknowledged transactions. Отключение fsync может угрожать целостности шире последней операции. Логи должны помещаться на disk с headroom; CDC slot retention способен остановить primary.

Типичные ошибки проектирования¶

Называть binlog, redo, Kafka log и event store взаимозаменяемыми. Вопрос: почему durable ACK не равен external exactly-once? У внешней системы свой commit boundary, а потерянный ACK допускает retry.

Вопросы на собеседовании¶

Как доказать применимость механизма? Назвать invariant, scope, isolation/acknowledgement boundary, версию, допустимые interleavings и процедуру восстановления. Один успешный запрос или статическая диаграмма этого не доказывают.

Практические упражнения¶

Для каждого момента crash укажите, какие data/log pages могли сохраниться и какой outcome увидит client. Затем спроектируйте restore с одной отсутствующей WAL segment.

Дополнительные источники¶

Политика версий и проверки. Статическая проверка статьи не является runtime/fault verification механизма.