После подтверждения транзакции сервер базы данных немедленно выходит из строя. За счёт какого механизма её изменения должны сохраниться после восстановления?
Обычно это обеспечивается журналом предзаписи (WAL, Write-Ahead Logging): сведения об изменениях записываются в журнал раньше, чем изменённые страницы данных. При подтверждении транзакции СУБД гарантирует сохранение необходимой записи журнала, поэтому после сбоя может повторить зафиксированные изменения при восстановлении.
Изменение страниц данных напрямую создаёт проблему: запись может прерваться посередине, а часть данных уже окажется изменённой. Кроме того, запись всех страниц на диск при каждом подтверждении была бы слишком медленной.
Журнал предзаписи разделяет быстрый процесс фиксации и более позднюю запись основных страниц данных. Такой подход позволяет подтверждать транзакции последовательно и восстанавливать согласованное состояние после отказа.
Транзакция может изменить несколько страниц или таблиц, а сбой произойти между этими изменениями. Если часть страниц уже записана, а часть ещё находится в памяти, после перезапуска база может содержать только половину логической операции.
Неверно считать, что сам факт ответа «транзакция подтверждена» автоматически означает физическое сохранение данных. Надёжность зависит от того, что именно СУБД считает завершённой записью, настроек синхронизации, устройства хранения и корректности реализации восстановления.
При изменении данных СУБД формирует записи журнала: например, информацию о странице, изменённых значениях или операции, достаточную для повторения либо отмены изменения. Сначала журнал должен попасть в устойчивое хранилище, и только после этого соответствующая изменённая страница может быть записана в основное место хранения.
При подтверждении транзакции в журнале появляется признак её завершения. Если изменённые страницы ещё не записаны, это допустимо: после сбоя механизм восстановления прочитает журнал и выполнит повтор операций для подтверждённых транзакций.
Для транзакций, которые не были подтверждены, восстановление должно устранить их эффект. В зависимости от архитектуры СУБД это достигается явной записью обратных действий, версионностью, теневыми страницами или сочетанием методов. Поэтому WAL — распространённый принцип, но конкретный формат журнала и алгоритм recovery зависят от СУБД.
Главный компромисс — стоимость синхронной записи журнала. Ожидание устойчивого хранения повышает надёжность подтверждения, но может ограничивать пропускную способность. Асинхронное подтверждение или кэширование записи ускоряют работу, однако увеличивают окно, в котором подтверждённые данные могут быть потеряны при отказе питания или хранилища.
WAL обеспечивает прежде всего свойства долговечности и помогает сохранить атомарность при восстановлении. Он не решает автоматически проблемы конкурентного доступа: изоляция, блокировки и обнаружение конфликтов требуют отдельных механизмов.
Платёжный сервис изменяет баланс счёта и создаёт запись о платеже в одной транзакции. Сбой происходит после логической фиксации транзакции, но до записи одной из изменённых страниц таблицы на диск.
Вариант без журнала или с некорректным порядком записи может оставить баланс изменённым, а запись о платеже отсутствующей. Это нарушит согласованность и потребует сложной сверки.
При WAL подтверждение считается завершённым только после сохранения нужной записи журнала. После перезапуска СУБД восстанавливает обе операции из журнала, даже если часть страниц данных до сбоя не успела попасть на диск. Такой вариант выбран потому, что журнал обычно компактнее полного набора страниц и позволяет совместить восстановимость с приемлемой производительностью.
Если бизнес допускает потерю последних секунд данных, можно применять менее строгую синхронизацию журнала ради скорости. Но для платежей это обычно неприемлемо: подтверждённая операция должна либо восстановиться целиком, либо не считаться подтверждённой.
Нет. Память процесса и обычный буфер операционной системы могут быть потеряны при отключении питания или аварии. Для гарантии требуется передать необходимые данные на устойчивый носитель согласно гарантиям конкретной СУБД и оборудования; поэтому настройки синхронности журнала влияют на реальную долговечность.
Потому что для восстановления достаточно сначала надёжно сохранить журнал. Поздняя запись страниц называется отложенной записью или checkpoint-процессом и уменьшает число дорогих операций с основными данными. Компромисс состоит в том, что большой объём журнала увеличивает время восстановления после сбоя.
Не сам по себе. WAL защищает от сценариев, для которых журнал и данные остаются доступными после сбоя, например от аварийного завершения процесса или перезапуска сервера. Для отказа диска нужны резервные копии, репликация, архивирование журнала и проверенная процедура восстановления; иначе журнал, находящийся на том же носителе, может быть уничтожен вместе с данными.