Write-Ahead Logging¶

Write-Ahead Logging (WAL, упреждающая запись журнала) — это техника обеспечения атомарности и долговечности транзакций в системах управления базами данных (СУБД) и других системах хранения данных. Основной принцип WAL заключается в том, что любые изменения данных сначала записываются в журнал (лог), и только после этого применяются к основному хранилищу. Этот подход позволяет гарантировать, что даже в случае сбоя системы (отключение питания, крах процесса) можно восстановить согласованное состояние данных, либо откатив незавершённые транзакции, либо завершив их на основе записей в журнале.

¶История и происхождение

Концепция WAL была разработана в 1970-х годах в рамках исследований в области транзакционных систем, в частности, в проекте System R компании IBM. Идея заключалась в том, чтобы отделить запись изменений от их непосредственного применения к страницам данных на диске. Это позволило решить проблему «грязной записи» (dirty write), когда частично записанная страница данных могла оказаться в неконсистентном состоянии после сбоя.

Ключевой вклад в формализацию WAL внесли работы Джима Грея (Jim Gray) и других исследователей. В 1992 году Грей опубликовал фундаментальную статью «The Transaction Concept: Virtues and Limitations», где подробно описал требования к журналированию. С тех пор WAL стал стандартом де-факто для большинства реляционных СУБД (PostgreSQL, MySQL, Oracle, SQL Server) и многих NoSQL-систем.

¶Основные принципы

¶Атомарность и долговечность

WAL обеспечивает два ключевых свойства ACID-транзакций:

• Атомарность (Atomicity): если транзакция прервана до завершения, система может откатить все её изменения, прочитав журнал и отменив записи.
• Долговечность (Durability): после фиксации (commit) транзакции все её изменения гарантированно сохраняются, даже если сразу после этого произойдёт сбой.

¶Правило WAL

Фундаментальное правило WAL гласит: запись в журнал должна быть произведена до того, как соответствующее изменение будет записано в основное хранилище данных. Это означает, что журнал всегда содержит достаточно информации для восстановления состояния на любой момент времени.

¶Структура журнала

Журнал WAL представляет собой последовательный файл (или набор файлов), в который записываются логические или физические записи об изменениях. Каждая запись обычно содержит:

• Идентификатор транзакции (XID): номер транзакции, к которой относится изменение.
• Тип операции: вставка, обновление, удаление, создание индекса и т.д.
• Данные изменения: либо полный образ изменяемой страницы (physical logging), либо логическое описание операции (logical logging), либо комбинация (physiological logging).
• Контрольная сумма: для проверки целостности записи.

¶Контрольные точки (Checkpoints)

Для предотвращения бесконечного роста журнала и ускорения восстановления системы периодически создаются контрольные точки. Во время контрольной точки все изменения, зафиксированные в журнале до определённого момента, принудительно записываются в основное хранилище. После этого журнал может быть усечён (удалены старые записи), так как для восстановления достаточно данных, начиная с последней контрольной точки.

¶Виды журналирования

¶Физическое журналирование

Каждая запись в журнале содержит полный образ изменяемой страницы данных (до и/или после операции). Этот подход прост в реализации, но генерирует большой объём данных, так как даже изменение одного байта приводит к записи целой страницы (обычно 4–16 КБ).

¶Логическое журналирование

Журнал содержит только описание операции (например, «обновить поле X в строке Y на значение Z»). Это значительно уменьшает объём журнала, но усложняет восстановление, так как требуется повторное выполнение операций, что может быть медленнее.

¶Физиологическое журналирование (Physiological Logging)

Комбинация физического и логического подходов. Изменения записываются на уровне страниц (физически), но внутри страницы операции описываются логически. Этот метод используется в большинстве современных СУБД (например, в PostgreSQL и Oracle), так как он обеспечивает баланс между объёмом журнала и скоростью восстановления.

¶Процесс восстановления

При запуске после сбоя система выполняет три фазы восстановления:

1. Фаза анализа (Analysis): система читает журнал, начиная с последней контрольной точки, и определяет, какие транзакции были зафиксированы (committed), а какие остались незавершёнными (in-flight).
2. Фаза REDO (Redo): для всех зафиксированных транзакций, изменения которых ещё не были записаны в основное хранилище, повторно применяются записи из журнала. Это гарантирует долговечность.
3. Фаза UNDO (Undo): для всех незавершённых транзакций отменяются их изменения на основе записей в журнале. Это гарантирует атомарность.

¶Применение

¶Реляционные СУБД

WAL является основой транзакционной системы во всех крупных реляционных СУБД:

• PostgreSQL: использует WAL для репликации (streaming replication), восстановления на момент времени (point-in-time recovery) и создания резервных копий.
• MySQL: в InnoDB WAL используется для обеспечения ACID-транзакций. Встроен также в кластерные решения (Galera, Group Replication).
• Oracle: использует Redo Logs, которые являются реализацией WAL.
• SQL Server: использует Transaction Log.

¶NoSQL-системы

Многие NoSQL-системы также применяют WAL для обеспечения долговечности:

• Apache Cassandra: использует Commit Log, который является аналогом WAL.
• MongoDB: использует журнал операций (oplog) для репликации и восстановления.
• LevelDB, RocksDB: используют WAL для обеспечения атомарности операций.

¶Файловые системы

Некоторые файловые системы, такие как ZFS и ext4 (в режиме журналирования), используют принципы WAL для обеспечения целостности метаданных. В этом случае журнал называется «журнал файловой системы» (journal).

¶Преимущества и недостатки

¶Преимущества

• Высокая надёжность: гарантирует восстановление после любых сбоев.
• Производительность: запись в журнал обычно происходит последовательно, что быстрее случайной записи в основное хранилище.
• Поддержка репликации: журнал может быть передан на реплики для синхронизации данных.
• Point-in-time recovery: возможность восстановить базу данных на любой момент времени в прошлом.

¶Недостатки

• Дополнительные затраты на ввод-вывод: каждая транзакция требует записи в журнал, что увеличивает нагрузку на диск.
• Рост журнала: при отсутствии контрольных точек журнал может занимать значительное место.
• Сложность реализации: требуется правильно управлять буферизацией, синхронизацией и контрольными точками.

¶Интересные факты

• В PostgreSQL WAL-файлы называются «сегментами» и имеют стандартный размер 16 МБ (настраивается).
• В Oracle Redo Logs могут быть организованы в группы (multiplexed redo logs) для повышения надёжности.
• В системах с очень высокой нагрузкой (например, в банковских системах) WAL может быть записан на отдельный быстрый диск (SSD) или в оперативную память с батарейным питанием (NVDIMM).
• Техника WAL лежит в основе многих распределённых систем, где журнал используется для достижения консенсуса (например, в Raft или Paxos).

¶Критика и альтернативы

Основная критика WAL связана с накладными расходами на ввод-вывод. В системах с очень высокой частотой транзакций (миллионы операций в секунду) запись каждого изменения в журнал может стать узким местом. Для решения этой проблемы используются:

• Групповая фиксация (group commit): несколько транзакций фиксируются одной записью в журнал.
• Буферизация журнала: записи накапливаются в оперативной памяти и сбрасываются на диск пачками.
• Асинхронный commit: транзакция считается зафиксированной до того, как запись в журнал попала на диск (риск потери данных при сбое).

Альтернативой WAL является журналирование на основе теневых страниц (shadow paging), которое используется, например, в SQLite в режиме WAL (но это другая реализация, не путать с классическим WAL). В shadow paging изменения вносятся в копию страницы, а затем атомарно заменяется указатель на корневую страницу. Этот подход проще в реализации, но менее эффективен для больших баз данных.

¶Источники

• Gray, J. (1992). The Transaction Concept: Virtues and Limitations.
• Gray, J., & Reuter, A. (1993). Transaction Processing: Concepts and Techniques.
• PostgreSQL Documentation: Write-Ahead Logging (WAL).
• MySQL Documentation: InnoDB Redo Log.
• Oracle Documentation: Redo Logs and Recovery.
• Технические статьи по архитектуре Apache Cassandra и MongoDB.