Вопрос проверяет понимание механизма журналирования и того, как базы данных обеспечивают сохранность данных при сбоях.
При записи база данных сначала фиксирует изменения в журнале WAL, а затем применяет их к таблицам. Это гарантирует, что изменения можно восстановить после сбоя. Подтверждение транзакции происходит после записи WAL. Такой подход обеспечивает надежность данных.
Журналирование через WAL — это ключевой механизм, который обеспечивает надежность и восстановление базы данных после сбоев.
Определение:
WAL (Write-Ahead Logging) — это механизм, при котором изменения сначала записываются в журнал, а уже потом применяются к основным данным.
Основная идея:
Запись в журнал выполняется последовательно, что быстро для диска.
Восстановление после сбоя проще — достаточно «проиграть» журнал.
Это дешевле и надежнее, чем сразу изменять множество страниц таблиц.
Когда выполняется INSERT или UPDATE, процесс обычно выглядит так:
Транзакция формирует изменения.
Генерируется запись WAL.
Запись WAL помещается в буфер.
При commit WAL сбрасывается на диск.
Транзакция считается подтвержденной.
Изменения в таблицах могут быть записаны позже (checkpoint или background writer).
Важно понимать, что подтверждение транзакции связано именно с WAL, а не с физической записью страниц таблицы.
Если сервер падает:
После запуска база читает WAL.
Применяет все подтвержденные изменения.
Незавершенные транзакции откатываются.
Это называется crash recovery.
Журналирование требует:
Дополнительных операций записи.
fsync для гарантии сохранности.
Управления буферами и checkpoint.
При высокой нагрузке WAL может стать узким местом.
Во многих системах:
WAL передается на реплики.
Реплики применяют те же изменения.
Это основа streaming replication.
На производительность влияют:
Частота commit.
Настройки synchronous commit.
Размер checkpoint.
Скорость диска для WAL.
Частые мелкие транзакции могут быть значительно дороже батчевых.
WAL обеспечивает надежность и восстановление базы данных: сначала изменения фиксируются в журнале, затем применяются к данным. Это увеличивает стоимость записи, но делает систему устойчивой к сбоям.
