Что происходит, когда происходит сбой СУБД на этапе восстановления алгоритмов ARIES?

Из того, что я понял об алгоритмах ARIES, для поддержки транзакций ACID необходимо использовать WAL (Write Ahead Logging): все записи регистрируются.

Говорят, что это дает базе данных возможность откатывать изменения, сделанные незафиксированной транзакцией до сбоя.

Для каждой записи мы регистрируем информацию о фактической записи (как ПОВТОРИТЬ, как ОТМЕНИТЬ).

На этапе восстановления мы анализируем журнал для выполнения операций REDO:

  • мы читаем запись в журнале
  • мы применяем изменение к базе данных
  • мы устанавливаем запись в журнале как выполненную

А затем, чтобы выполнить UNDO, записывается новая запись в журнал (потому что это все-таки запись), затем изменение применяется к базе данных во время контрольной точки.

Думаю, во время контрольной точки мы просто выполняем REDO для всех зафиксированных записей.

Я не нашел никакой информации о том, что произойдет, если:

  • авария на контрольно-пропускном пункте
  • происходит сбой на этапе REDO, после того, как изменение было применено к базе данных, и до/во время обновления журнала, чтобы установить его как выполненное

В этих случаях к базе данных были применены некоторые изменения, которые не отражаются в журнале, оставляя базу данных в несогласованном состоянии.

NB: Вот некоторые из ссылок, которые я использовал, чтобы узнать больше о транзакциях ACID и алгоритме ARIES:

В настоящее время я читаю исходный код SQLite, чтобы понять, как все это реализовано.

Заранее спасибо за любые разъяснения по этой теме.


transactions algorithm acid aries
person linkdd    schedule 01.07.2017    source источник
comment
Релевантно: stackoverflow.com/questions/10289170/   -  person Jedi    schedule 01.07.2017

Ответы (1)


arrow_upward
1
arrow_downward

Во время REDO журнал читается и данные изменяются при необходимости. Если во время REDO произойдет сбой, то при следующем восстановлении REDO снова запустится. Некоторые записи журнала, в которых были изменены данные при первой попытке восстановления, будут недействительными, поскольку изменение данных было сохранено. Другие не будут сохранены и будут «переделаны» снова.

Контрольная точка по-прежнему является транзакционной операцией. В памяти сохраняются данные, затем в самый последний момент в лог записывается запись чекпойнта. Если сбой происходит во время контрольной точки, он может произойти только до того, как запись контрольной точки была записана. После краха восстановление запускается снова и начинается с REDO (поскольку нет записи о новой контрольной точке). Пункт выше применим, REDO можно запускать повторно. Некоторые записи журнала будут неактивными, поскольку изменения данных уже были сохранены, некоторые будут «переделаны» снова.

UNDO работает, создавая и записывая компенсирующую запись журнала. Если во время UNDO происходит сбой, то при следующем восстановлении остается еще одна запись для анализа и REDO (компенсирующая запись). Это восстановление после сбоя UNDO затем запустит фазу UNDO, начиная после сохранения последней успешной записи журнала UNDO. То есть, если исходный журнал содержит две операции в незафиксированной транзакции, скажем, OP1 и OP2, а затем запускает UNDO, он записывает компенсирующий UNDO-OP1 и аварийно завершает работу. Тогда восстановление ОТМЕНИТ, начиная с OP2, поскольку для OP1 уже есть компенсирующая запись в журнале (UNDO-OP1).

В правильно реализованном ОВНЕ никогда не бывает окна несоответствия.

person Remus Rusanu    schedule 01.07.2017
comment
это означает, что для правильной реализации алгоритма запись журнала должна отслеживать старое состояние и новое состояние? - person linkdd; 01.07.2017
comment
Запись журнала должна быть идемпотентной. Детали реализации различаются. - person Remus Rusanu; 01.07.2017
comment
Зачем вообще использовать компенсирующие записи журнала? Я читал, что CLR существуют, чтобы гарантировать идемпотентность UNDO. Но как была бы нарушена идемпотентность, если бы мы их не использовали? - person Florian Wicher; 05.07.2021