Write-Ahead Log¶

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

¶Принцип работы

Основная идея WAL заключается в том, что любое изменение данных сначала фиксируется в последовательном, append-only (только добавление) журнале, расположенном на энергонезависимом носителе (например, жёстком диске или SSD). Только после успешной записи в журнал (commit) изменение может быть применено к основным файлам данных (data pages). В случае сбоя во время записи данных на диск, система при перезапуске считывает WAL и восстанавливает состояние, соответствующее последней зафиксированной транзакции.

¶Процесс записи

1. Начало транзакции: СУБД создаёт запись в WAL, указывающую на начало новой транзакции.
2. Модификация данных: Для каждого изменения (вставка, обновление, удаление) генерируется запись в WAL, содержащая:

• Идентификатор транзакции.
• Тип операции.
• Идентификатор изменяемой страницы (page ID).
• Данные до изменения (undo-информация) и после изменения (redo-информация).

1. Фиксация записи: Запись сбрасывается на диск (обычно с помощью системного вызова fsync или fdatasync). Только после этого изменение считается долговременным.
2. Применение к данным: В фоновом режиме или при необходимости (например, при нехватке места в буферном пуле) изменённые страницы записываются из оперативной памяти на диск в основные файлы данных.
3. Фиксация транзакции: Создаётся специальная запись «commit» в WAL, которая также сбрасывается на диск. После этого транзакция считается завершённой.

¶Восстановление после сбоя

При перезапуске СУБД после аварийного завершения работы выполняется процедура восстановления, которая состоит из трёх фаз:

1. Анализ (Analysis): Сканирование WAL для определения состояния всех транзакций на момент сбоя (какие были зафиксированы, какие нет).
2. Повтор (Redo): Повторное применение всех изменений, записанных в WAL, для зафиксированных транзакций, которые не были записаны в основные файлы данных. Это гарантирует, что никакие данные не будут потеряны.
3. Откат (Undo): Отмена всех изменений, внесённых незафиксированными транзакциями, чтобы вернуть базу данных в согласованное состояние.

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

• Надёжность: Гарантирует, что ни одна зафиксированная транзакция не будет потеряна из-за сбоя, а незафиксированные транзакции не приведут к повреждению данных.
• Производительность: Запись в WAL является последовательной (append-only), что значительно быстрее, чем произвольная запись в разные страницы данных. Это позволяет объединять множество мелких изменений в одну операцию записи на диск.
• Упрощение конкурентного доступа: WAL позволяет нескольким транзакциям одновременно читать и изменять данные, не блокируя друг друга, так как изменения фиксируются в журнале, а не сразу применяются к основным структурам.
• Возможность создания резервных копий: WAL может использоваться для создания «горячих» резервных копий (online backup) без остановки базы данных, путём копирования файлов данных и журнала.

¶Недостатки

• Дополнительные накладные расходы: Каждая операция записи требует дополнительной записи в WAL, что увеличивает общий объём ввода-вывода.
• Усложнение архитектуры: Реализация WAL требует тщательного проектирования и отладки, особенно в части управления буферами и процедурами восстановления.
• Потребление дискового пространства: Журнал может занимать значительный объём на диске, особенно при большом количестве изменений. Требуется механизм очистки (checkpointing) для удаления устаревших записей.

¶Применение

WAL является стандартным механизмом обеспечения целостности данных в большинстве современных реляционных СУБД и некоторых NoSQL-системах.

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

• PostgreSQL: WAL (также называемый XLOG) является центральным компонентом, обеспечивающим как восстановление после сбоев, так и репликацию (streaming replication). Журнал хранится в каталоге pg_wal.
• MySQL (с InnoDB): Движок InnoDB использует WAL (redo log) для обеспечения долговечности и восстановления. Журнал состоит из нескольких файлов фиксированного размера, которые циклически перезаписываются.
• SQLite: Начиная с версии 3.7.0, SQLite поддерживает режим WAL, который значительно повышает производительность при параллельном чтении и записи. В этом режиме создаётся отдельный файл -wal.
• Oracle Database: Использует механизм redo log, который по сути является WAL. Журналы redo (online redo log files) хранят все изменения, сделанные в базе данных.
• Microsoft SQL Server: Использует журнал транзакций (transaction log), который работает по принципу WAL.

¶NoSQL-системы

• Apache Cassandra: Использует commit log для обеспечения долговечности записей перед их применением к memtables и SSTables.
• MongoDB: Использует журнал (journal) для обеспечения долговечности операций записи. По умолчанию включён в большинстве конфигураций.
• RocksDB: Встраиваемая база данных, активно использующая WAL для обеспечения атомарности и долговечности операций.

¶Реализация в PostgreSQL

В PostgreSQL WAL (XLOG) является одним из ключевых компонентов архитектуры. Каждая запись в WAL имеет уникальный номер (Log Sequence Number, LSN), который используется для отслеживания состояния страниц данных. Процесс контрольной точки (checkpoint) периодически сбрасывает все изменённые страницы на диск и записывает в WAL специальную запись, указывающую, что все изменения до этого момента уже применены. Это позволяет удалить устаревшие записи из WAL и сократить время восстановления.

¶Реализация в SQLite

В режиме WAL SQLite создаёт дополнительный файл -wal. Читатели могут читать данные из основного файла, не дожидаясь завершения записи в журнал. Писатель добавляет изменения в конец WAL-файла. Когда WAL-файл достигает определённого размера (по умолчанию 1000 страниц), выполняется процедура checkpoint, при которой все изменения из WAL-файла переносятся в основной файл базы данных. Этот режим значительно улучшает производительность при параллельном доступе.

¶Отличия от других подходов

• Shadow paging: В отличие от WAL, где изменения сначала записываются в журнал, а затем в основное хранилище, shadow paging создаёт копию изменяемых страниц (shadow pages) и после успешной фиксации транзакции атомарно переключает указатель на новую версию. WAL, как правило, требует меньше операций ввода-вывода и обеспечивает более высокую производительность при большом количестве мелких транзакций.
• No-overwrite storage: В некоторых системах (например, в log-structured merge-tree, LSM-tree) данные никогда не перезаписываются, а только добавляются в конец. WAL в таких системах может использоваться для обеспечения атомарности операций, но основное хранилище само по себе является журналом.

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

• Концепция WAL была впервые описана в 1974 году в статье «A Recovery Algorithm for a Database System» (авторы — Чарльз Бахман и др.), хотя практические реализации появились позже.
• В PostgreSQL WAL может быть зашифрован для обеспечения безопасности данных.
• Размер WAL-файлов в PostgreSQL можно настроить с помощью параметров wal_segment_size и max_wal_size.
• В SQLite режим WAL не поддерживается в базах данных, хранящихся на сетевых файловых системах (NFS), если они не настроены на поддержку атомарных операций.

¶Источники

• Gray, J., & Reuter, A. (1992). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.
• Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill.
• Документация PostgreSQL: Chapter 30. Reliability and the Write-Ahead Log.
• Документация SQLite: Write-Ahead Logging.
• Документация MySQL: InnoDB Redo Log.
• Bachman, C. W. (1974). A Recovery Algorithm for a Database System. Proceedings of the 1974 ACM SIGFIDET Workshop on Data Description, Access and Control.