Кэш журнала повторного выполнения

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

Назначение и принцип работы

Основная функция кэша журнала повторного выполнения — минимизировать задержки, связанные с записью на диск, которая является одной из самых медленных операций в компьютерной системе. Вместо того чтобы выполнять физическую запись на диск при каждом изменении строки в таблице, СУБД сначала фиксирует это изменение в быстром кэше в оперативной памяти. Это позволяет приложению-клиенту быстро получить подтверждение о завершении транзакции, не дожидаясь завершения дисковых операций.

Принцип работы кэша основан на механизме буферизации. Когда транзакция изменяет данные (вставляет, обновляет или удаляет строки), СУБД генерирует запись о выполнении операции (redo-запись). Эта запись помещается в кэш журнала повторного выполнения. Запись в кэш происходит последовательно, что обеспечивает высокую скорость. После того как транзакция фиксируется (команда COMMIT), содержимое кэша, относящееся к этой транзакции, должно быть гарантированно записано на диск в файл журнала повторного выполнения (redo log). Только после этого транзакция считается окончательно зафиксированной, и клиент получает уведомление об успехе.

Устройство и характеристики

Кэш журнала повторного выполнения представляет собой непрерывный блок оперативной памяти, размер которого задаётся администратором базы данных. В разных СУБД этот параметр называется по-разному. Например, в Oracle Database он определяется параметром инициализации LOG_BUFFER, а в PostgreSQL — параметром wal_buffers (для журнала предзаписи WAL, который выполняет аналогичную функцию).

Ключевые характеристики кэша:

• Размер: Обычно устанавливается от нескольких мегабайт до десятков мегабайт. Слишком маленький размер может привести к частым сбросам на диск и снижению производительности. Слишком большой — к неоправданному расходу оперативной памяти и увеличению времени восстановления после сбоя.
• Структура: Кэш организован как циклический буфер. Новые записи добавляются в его конец, а после сброса на диск пространство, занимаемое записанными данными, может быть переиспользовано.
• Синхронизация: Доступ к кэшу осуществляется в многопоточной среде, поэтому для обеспечения целостности данных используются механизмы синхронизации (например, блокировки или атомарные операции).

Процесс записи и сброса на диск

Процесс управления кэшем журнала повторного выполнения включает несколько этапов:

1. Генерация записи: При изменении блока данных в буферном кэше СУБД создаёт redo-запись, содержащую информацию о том, какие именно изменения были внесены (например, старые и новые значения полей).
2. Помещение в кэш: Запись копируется в кэш журнала повторного выполнения. Обычно это делается в рамках той же транзакции, которая изменяет данные.
3. Фиксация транзакции: При выполнении COMMIT СУБД инициирует сброс содержимого кэша на диск. Этот процесс называется «запись журнала» (log write). Важно, что на диск записываются не только записи текущей транзакции, но и все накопившиеся в кэше записи, которые ещё не были сброшены.
4. Подтверждение: После успешной записи на диск СУБД отправляет клиенту подтверждение о фиксации транзакции.

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

Взаимосвязь с другими компонентами СУБД

Кэш журнала повторного выполнения тесно связан с другими компонентами СУБД, обеспечивающими надёжность и производительность:

• Буферный кэш (buffer cache): Хранит изменённые блоки данных в памяти. Изменения в буферном кэше не сразу записываются в файлы данных. Журнал повторного выполнения гарантирует, что даже если данные не были записаны на диск, их можно восстановить из журнала.
• Журнал повторного выполнения (redo log): Физический файл (или группа файлов) на диске, в который сбрасывается содержимое кэша. В Oracle Database журнал состоит из нескольких групп, которые используются циклически.
• Процесс записи журнала (LGWR — Log Writer): Фоновый процесс в Oracle Database, отвечающий за сброс содержимого кэша журнала повторного выполнения в файлы журнала.
• Контрольная точка (checkpoint): Момент, когда все изменённые блоки из буферного кэша записываются в файлы данных. После контрольной точки журнал повторного выполнения может быть переиспользован.

Значение для восстановления после сбоев

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

1. Прокрутка вперёд (roll forward): СУБД считывает записи из журнала повторного выполнения и повторно применяет их к данным, восстанавливая состояние базы данных на момент сбоя.
2. Откат незавершённых транзакций (rollback): Транзакции, которые не были зафиксированы на момент сбоя, отменяются.

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

Особенности в различных СУБД

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

• Oracle Database: Использует термин redo log buffer. Размер задаётся параметром LOG_BUFFER. Процесс LGWR сбрасывает буфер на диск при фиксации транзакции, каждые три секунды, при заполнении буфера на треть или при достижении одного мегабайта записей.
• PostgreSQL: Использует журнал предзаписи (WAL, Write-Ahead Log). Параметр wal_buffers определяет размер буфера WAL в памяти. Сброс на диск выполняется процессом WAL writer.
• MySQL (InnoDB): Использует буфер журнала (log buffer). Размер задаётся параметром innodb_log_buffer_size. Сброс на диск происходит при фиксации транзакции, каждую секунду или при заполнении буфера.

Производительность и настройка

Размер кэша журнала повторного выполнения является важным параметром настройки производительности. Слишком маленький кэш может привести к частым сбросам на диск, что увеличивает количество операций ввода-вывода и снижает пропускную способность системы. Слишком большой кэш может привести к задержкам при сбросе и увеличению времени восстановления после сбоя.

Рекомендуется устанавливать размер кэша таким образом, чтобы он мог вместить записи от нескольких транзакций, выполняющихся одновременно. В системах с высокой транзакционной нагрузкой (OLTP — Online Transaction Processing) размер кэша часто устанавливают в диапазоне от 8 до 64 мегабайт. Для систем с преобладанием операций чтения (DSS — Decision Support Systems) размер может быть меньше.

Источники

• Oracle Database Concepts, 19c — Redo Log Buffer
• PostgreSQL Documentation, 15 — WAL Configuration
• MySQL 8.0 Reference Manual — InnoDB Redo Log
• Электронные ресурсы: документация к СУБД Oracle, PostgreSQL, MySQL