Транзакционный журнал

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

Назначение и роль

Основное назначение транзакционного журнала — гарантировать, что ни одна успешно завершённая транзакция не будет потеряна, а любая прерванная транзакция не оставит систему в противоречивом состоянии. Журнал действует как «запасной вариант»: если сбой происходит до того, как изменённые данные были записаны на диск (в основное хранилище), СУБД использует журнал для повторного выполнения (redo) или отмены (undo) операций.

Ключевые функции:

• Восстановление после сбоя (crash recovery). При внезапном отключении питания или сбое оборудования СУБД анализирует журнал, чтобы определить, какие транзакции были завершены, а какие — нет. Завершённые транзакции повторно применяются к базе данных, а незавершённые — откатываются.
• Откат транзакций (rollback). Если пользователь или приложение явно отменяет транзакцию (команда ROLLBACK), СУБД использует записи журнала для восстановления исходного состояния данных.
• Поддержка многоверсионности (MVCC). В системах, реализующих мультиверсионное управление параллельным доступом (например, PostgreSQL, Oracle), журнал используется для хранения старых версий строк, что позволяет читателям видеть согласованную «моментальную» копию данных, не блокируя пишущие транзакции.
• Репликация и резервное копирование. Многие СУБД используют поток журнала для синхронизации резервных копий или реплик: изменения, записанные в журнал на основном сервере, передаются на резервные серверы (standby) и применяются к ним.

Структура и принцип работы

Транзакционный журнал обычно представляет собой последовательный (append-only) файл или группу файлов на диске. Каждая запись в журнале (лог-запись) содержит информацию, достаточную для восстановления одного атомарного изменения.

Стандартная структура записи включает:

• Идентификатор транзакции (Transaction ID) — уникальный номер транзакции, к которой относится изменение.
• Тип операции (вставка, обновление, удаление, начало транзакции, фиксация, откат).
• Идентификатор объекта (номер страницы, строки или таблицы, которые были изменены).
• Старое значение (before-image) — состояние данных до изменения (используется для отката).
• Новое значение (after-image) — состояние данных после изменения (используется для повторного выполнения после сбоя).
• Временная метка или порядковый номер записи (Log Sequence Number, LSN) — для определения порядка операций.

Принцип работы основан на правиле Write-Ahead Logging (WAL): запись в журнал должна производиться до того, как изменённые данные будут записаны в основное хранилище базы данных. Это гарантирует, что в случае сбойной ситуации в журнале будет достаточно информации для восстановления, даже если основное хранилище повреждено или не обновлено.

Виды транзакционных журналов

По способу хранения и обработки различают:

• Физический журнал (physical log). Хранит изменения на уровне физических страниц или блоков диска. Например, запись может содержать «страница X, смещение Y, новое значение Z». Такой подход используется в Microsoft SQL Server и InnoDB (MySQL). Преимущество — высокая скорость восстановления, недостаток — большой объём данных.
• Логический журнал (logical log). Хранит описание операции на уровне SQL-команд. Например, «UPDATE таблица SET колонка = значение WHERE условие». Используется в некоторых системах для репликации (например, логическая репликация в PostgreSQL). Преимущество — компактность, недостаток — более сложное восстановление, так как требуется повторное выполнение запроса.
• Журнал с опережающей записью (WAL). Строгое соблюдение принципа «сначала журнал, потом данные». Реализован в большинстве современных СУБД (PostgreSQL, SQLite, Oracle, InnoDB). Обеспечивает атомарность и долговечность транзакций.
• Журнал с отложенной записью (deferred log). Данные сначала записываются в основное хранилище, а журнал обновляется позже. Используется редко, так как не гарантирует восстановление после сбоя.

Управление размером и циклическая запись

Транзакционные журналы имеют тенденцию к неограниченному росту, если не управлять их размером. Для предотвращения переполнения диска применяются механизмы ротации и архивации:

• Циклический журнал (circular log). Используется в системах, где не требуется долгосрочное хранение истории изменений (например, для восстановления после сбоя достаточно последних записей). Журнал состоит из фиксированного числа файлов; когда все файлы заполнены, старые записи перезаписываются новыми. Применяется в Microsoft SQL Server в режиме «простой» модели восстановления.
• Архивный журнал (archive log). Старые записи не удаляются, а копируются в отдельное хранилище (архив). Это позволяет восстанавливать базу данных на любой момент времени в прошлом (point-in-time recovery). Используется в Oracle, PostgreSQL (в режиме непрерывного архивирования) и других системах.

Примеры реализации в популярных СУБД

• PostgreSQL. Использует механизм WAL. Журнал хранится в каталоге pg_wal. Каждая запись WAL содержит LSN, который используется для координации между процессами. Поддерживает архивацию WAL для создания резервных копий и репликации.
• MySQL (InnoDB). Журнал называется redo log и состоит из двух файлов (ib_logfile0, ib_logfile1). Работает по принципу WAL. Для отката транзакций используется отдельный undo log, который хранит старые версии строк.
• Microsoft SQL Server. Журнал транзакций представляет собой файл с расширением .ldf. Поддерживает три модели восстановления: простая (циклический журнал), полная (архивный журнал) и с неполным протоколированием.
• Oracle Database. Использует redo log (файлы в каталоге ORADATA). Работает в режиме ARCHIVELOG (архивация) или NOARCHIVELOG (циклическая запись). Для отката — undo tablespace.

Влияние на производительность

Транзакционный журнал является узким местом в системах с высокой интенсивностью записи. Каждая операция модификации данных требует записи в журнал, что создаёт дополнительную дисковую нагрузку. Для повышения производительности применяются:

• Групповая фиксация (group commit) — несколько транзакций фиксируются одной операцией записи в журнал.
• Выделенные диски для журнала — размещение файлов журнала на быстрых SSD-накопителях или отдельных физических дисках.
• Буферизация журнала — запись в оперативную память с периодической синхронизацией на диск (например, параметр commit_delay в PostgreSQL).

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

Традиционный транзакционный журнал имеет недостатки:

• Избыточность. Дублирование данных (журнал + основное хранилище) увеличивает объём занимаемого дискового пространства.
• Задержки. Синхронная запись в журнал при каждой фиксации транзакции может снижать пропускную способность.

Альтернативные подходы:

• Журналируемые файловые системы (ZFS, Btrfs) — реализуют концепцию copy-on-write, при которой журнал не требуется, так как старые версии данных сохраняются до завершения операции.
• Системы на основе LSM-деревьев (LevelDB, RocksDB, Apache Cassandra) — используют структуру, где все записи сначала попадают в журнал (WAL), а затем асинхронно сливаются в компактные файлы. Это снижает накладные расходы на случайный доступ.
• In-memory базы данных (Redis, Memcached) — могут не использовать постоянный журнал, полагаясь на периодические снимки состояния (snapshot) и репликацию.

Источники

• Гарсиа-Молина, Г., Ульман, Дж., Уидом, Дж. «Системы баз данных. Полный курс». — М.: Вильямс, 2003.
• К. Дж. Дейт. «Введение в системы баз данных». — 8-е изд. — М.: Вильямс, 2005.
• Документация PostgreSQL 16: Chapter 30. Reliability and the Write-Ahead Log.
• Документация MySQL 8.0: InnoDB Redo Log.
• Документация Microsoft SQL Server: Transaction Log Architecture and Management Guide.