ДОКУМЕНТАЦИЯ

Выберите версию, форк и язык для СУБД Digital Q.DataBase, чтобы прочитать или скачать всю документацию.

Новости

01.09.2026

СУБД Digital Q.DataBase можно развернуть из готового Docker-образа

25.08.2026

СУБД Digital Q.DataBase: 8 ядер бесплатно — до 1 сентября!

Документация

Диасофт
Авторские права © 2016–2025 ООО "Диасофт Экосистема"

Скачать всю документацию:

pdf (13 mБ) EPUB (13 mБ) CHM (14 МБ)

3.13.3. Журналирование с предварительной записью (WAL)

Содержание

Журналирование с предварительной записью (WAL) — это стандартный метод обеспечения целостности данных. Подробное описание можно найти в большинстве (если не во всех) книгах по обработке транзакций. Вкратце, основная концепция WAL заключается в том, что изменения в файлах данных (где находятся таблицы и индексы) должны записываться только после того, как эти изменения были зарегистрированы, то есть после того, как записи в журнале предварительной записи, описывающие изменения, были сброшены в постоянное хранилище. Если мы следуем этой процедуре, нам не нужно сбрасывать страницы данных на диск при каждой фиксации транзакции, потому что мы знаем, что в случае сбоя сможем восстановить базу данных, используя журнал: любые изменения, которые не были применены к страницам данных, могут быть выполнены повторно на основе записей в журнале предварительной записи. (Это восстановление с накатом, также известное как REDO.)

Подсказка

Поскольку WAL восстанавливает содержимое файлов базы данных после сбоя, журналируемые файловые системы не являются обязательными для надежного хранения файлов данных или файлов журнала предварительной записи. Фактически, накладные расходы на журналирование могут снизить производительность, особенно если журналирование приводит к сбросу данных файловой системы на диск. К счастью, сброс данных во время журналирования часто можно отключить с помощью опции монтирования файловой системы, например, data=writeback в файловой системе Linux ext3. Журналируемые файловые системы действительно ускоряют загрузку после сбоя.

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

WAL также позволяет поддерживать оперативное резервное копирование и восстановление на момент времени (point-in-time recovery), как описано в Раздел 3.10.3. Архивируя данные журнала предварительной записи, мы можем поддерживать возврат к любому моменту времени, охваченному доступными данными журнала: мы просто устанавливаем предыдущую физическую резервную копию базы данных и проигрываем журнал предварительной записи до нужного момента времени. Более того, физическая резервная копия не обязательно должна быть мгновенным снимком состояния базы данных — если она создавалась в течение некоторого периода времени, то повторное воспроизведение журнала предварительной записи за этот период устранит любые внутренние несоответствия.

Наверх