Журнал транзакций¶

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

¶Назначение и функции

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

• Восстановление после сбоя (crash recovery): при запуске СУБД после аварийной остановки журнал используется для отката (rollback) транзакций, которые не были завершены (commit), и повторного применения (redo) изменений от транзакций, которые были зафиксированы, но не успели быть записаны на диск.
• Откат транзакций (rollback): если пользователь или приложение отменяет транзакцию, СУБД использует записи журнала для отмены всех изменений, внесённых этой транзакцией.
• Точечное восстановление (point-in-time recovery): возможность восстановить базу данных на конкретный момент времени (например, на момент до ошибки оператора или внедрения вредоносного кода).
• Репликация и зеркалирование: журнал транзакций часто передаётся на резервные серверы для поддержания актуальной копии базы данных в реальном времени.
• Аудит и мониторинг: записи журнала могут использоваться для анализа действий пользователей и изменений данных.

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

Журнал транзакций представляет собой последовательный файл (или набор файлов), в который СУБД записывает записи (log records) в хронологическом порядке. Каждая запись содержит:

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

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

¶LSN (Log Sequence Number)

Каждая запись в журнале транзакций имеет уникальный номер LSN, который монотонно возрастает. LSN используется для:

• Определения порядка записей.
• Связывания страниц данных с соответствующими записями журнала (на каждой странице данных хранится LSN последней изменившей её транзакции).
• Управления процессом восстановления (определение точки, с которой нужно начать повторное применение или откат).

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

В зависимости от архитектуры СУБД и режима работы, журналы транзакций могут различаться по способу записи и управления:

• Физический журнал (physical log): хранит образы страниц данных целиком (или их частей) до и после изменения. Используется в большинстве реляционных СУБД (например, Microsoft SQL Server, PostgreSQL, MySQL с InnoDB).
• Логический журнал (logical log): хранит описание операций на уровне SQL-команд (например, INSERT, UPDATE, DELETE). Может использоваться в системах репликации или в СУБД с упрощённой моделью восстановления (например, MySQL с MyISAM не имеет полноценного журнала транзакций, но использует бинарный лог для репликации).
• Журнал с предзаписью (WAL) — стандартный механизм, реализованный в большинстве современных СУБД (PostgreSQL, SQLite, Oracle, DB2). Обеспечивает атомарность и долговечность транзакций.
• Журнал с отложенной записью (deferred log) — изменения сначала накапливаются в оперативной памяти, а затем сбрасываются в журнал. Менее надёжен, но может быть быстрее в некоторых сценариях.

¶Управление журналом транзакций

¶Размер и управление файлами

Журнал транзакций обычно имеет фиксированный или динамически расширяемый размер. В СУБД предусмотрены механизмы управления его объёмом:

• Автоматическое расширение: журнал увеличивается по мере необходимости, пока не достигнет максимального размера или не закончится место на диске.
• Резервное копирование и усечение (truncation): после успешного резервного копирования журнала (или базы данных) неактивные части журнала могут быть удалены для освобождения места. В некоторых СУБД (например, Microsoft SQL Server) журнал может бесконечно расти, если не настроено регулярное резервное копирование.
• Циклическое использование (circular logging): журнал записывается в кольцевой буфер, где старые записи перезаписываются новыми. Используется в системах, где восстановление до произвольной точки не требуется (например, в некоторых встраиваемых СУБД).

¶Режимы работы журнала

В различных СУБД существуют режимы, определяющие степень детализации журнала и возможность восстановления:

• Полный режим (full recovery): журналируются все изменения, включая массовые операции. Позволяет восстановить базу данных на любой момент времени.
• Режим с простым восстановлением (simple recovery): журнал автоматически усекается после каждой контрольной точки. Восстановление возможно только до последней резервной копии.
• Режим с неполным журналированием (bulk-logged recovery): массовые операции (например, загрузка больших объёмов данных) журналируются минимально, что ускоряет их выполнение, но ограничивает возможности точечного восстановления.

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

¶PostgreSQL

В PostgreSQL журнал транзакций называется Write-Ahead Log (WAL). Файлы WAL хранятся в каталоге pg_wal. Размер каждого файла WAL по умолчанию составляет 16 МБ. PostgreSQL поддерживает архивирование WAL для создания непрерывных резервных копий и репликации. Механизм восстановления основан на чтении WAL с момента последней контрольной точки.

¶Microsoft SQL Server

Журнал транзакций в SQL Server физически представлен файлом с расширением .ldf. Он работает в одном из трёх режимов восстановления. Для управления размером журнала используются команды BACKUP LOG и DBCC SHRINKFILE. SQL Server поддерживает автоматическое расширение файла журнала.

¶MySQL (InnoDB)

В MySQL с движком InnoDB журнал транзакций реализован через файлы ib_logfile0 и ib_logfile1 (по умолчанию). Размер журнала задаётся параметром innodb_log_file_size. InnoDB использует механизм WAL и циклическую запись. Для обеспечения надёжности используется двойная запись (doublewrite buffer).

¶Oracle Database

В Oracle журнал транзакций называется redo log. Он состоит из групп файлов redo log, которые циклически перезаписываются. Oracle также использует undo-сегменты для отката транзакций, которые работают совместно с redo log.

¶Проблемы и риски

• Переполнение дискового пространства: если журнал не обслуживается (не выполняется резервное копирование и усечение), он может занять всё свободное место на диске, что приведёт к остановке базы данных.
• Производительность: интенсивная запись в журнал может стать узким местом, особенно на медленных дисках. Для повышения производительности журнал часто размещают на быстрых SSD-накопителях или отдельном дисковом массиве.
• Повреждение журнала: если файл журнала повреждён, восстановление базы данных может стать невозможным. Для минимизации рисков используется зеркалирование журнала (например, в Oracle — multiplexed redo log).
• Конфликты при репликации: в распределённых системах задержки передачи журнала могут приводить к рассинхронизации реплик.

¶Законодательные аспекты

В Российской Федерации требования к ведению журналов транзакций могут быть связаны с законодательством о персональных данных (Федеральный закон № 152-ФЗ) и об оперативно-розыскной деятельности. Согласно приказу Минкомсвязи России № 365 от 27 ноября 2018 года, операторы связи обязаны хранить журналы транзакций и предоставлять их уполномоченным органам. Также требования к журналированию изменений данных содержатся в стандартах банковской системы (ЦБ РФ) и в системах сертификации средств защиты информации (ФСТЭК России).

¶Источники

• Гарсиа-Молина, Г., Ульман, Дж., Уидом, Дж. «Системы баз данных. Полный курс». — М.: Вильямс, 2003.
• К. Дж. Дейт. «Введение в системы баз данных». — М.: Вильямс, 2005.
• Документация PostgreSQL. Глава 30. «Надёжность и журнал предзаписи» (WAL).
• Документация Microsoft SQL Server. «Журнал транзакций SQL Server».
• Документация MySQL. «InnoDB Redo Log».
• Федеральный закон «О персональных данных» от 27.07.2006 № 152-ФЗ.
• Приказ Минкомсвязи России от 27.11.2018 № 365 «Об утверждении Правил хранения...».