--- aliases: tags: - maturity/🌱 date: - - 2024-05-26 zero-link: - "[[00 Базы Данных]]" parents: linked: --- Основная цель журнала — фиксировать все изменения, происходящие в базе данных, до их окончательного применения. Это позволяет выполнять [[../../../../_inbox/Транзакция БД|транзакции]] и [[../architecture/highload/Репликация БД|репликацию бд]]. Перед тем как выполнить SQL-запрос, база данных записывает в журнал все действия, которые собирается сделать. После того как журнал зафиксировался на диске, база данных изменяет сами данные в памяти. И только через какое-то время эти данные окажутся на диске в хранилище. Этот алгоритм называется [PITR](Point%20In%20Time%20Recovery%20(PITR).md) ![](Pasted%20image%2020240528081137.png) Этот процесс обеспечивает два важных аспекта: - **Надежность**: В случае сбоя системы, данные можно восстановить из журнала до последнего зафиксированного состояния. - **Консистентность**: Все транзакции, записанные в журнал, будут применены в базе данных в правильном порядке, что предотвращает потерю данных и сохраняет целостность системы. > [!INFO] > Журналы базы данных часто имеют циклическую структуру, где новые данные записываются поверх старых, когда журнал заполняется. Это позволяет эффективно использовать дисковое пространство и упрощает управление журналом. Реализации в СуБД: - [[postgresql/Write-Ahead Log|Журнал в PostgreSQL]] - [Журналы в MySQL](mysql/Журналы%20в%20MySQL.md) Главные вопросы, которые встают перед разработчиком любой БД: - Как организовать журнал? - Как его писать? - Как писать его меньше? - Как сделать так, чтобы это работало быстрее? - При чем тут репликация? Для улучшения производительности желательно под журналы выделять отдельные жесткие диски. Чтобы у журнала был эксклюзивный доступ к ресурсам диска. Менее актуально для SSD. *** ## Мета информация **Область**:: [[../../meta/zero/00 Базы Данных|00 Базы Данных]] **Родитель**:: **Источник**:: **Автор**:: **Создана**:: [[2024-05-26]] ### Дополнительные материалы - ### Дочерние заметки - [[Write-Ahead Log]]