Распределенная СУБД - Восстановление базы данных

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

Типичные стратегии восстановления базы данных:

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

Восстановление после сбоя питания

Сбой питания вызывает потерю информации в непостоянной памяти. После восстановления питания операционная система и система управления базами данных перезапускаются. Менеджер восстановления инициирует восстановление из журналов транзакций.

В случае режима немедленного обновления диспетчер восстановления выполняет следующие действия:

Транзакции, которые находятся в активном списке и списке сбоев, отменяются и записываются в список отмены.
Транзакции, которые находятся в списке до фиксации, повторяются.
Никаких действий для транзакций в списках фиксации или прерывания не предпринимается.

В случае режима отложенного обновления диспетчер восстановления выполняет следующие действия:

Транзакции, которые находятся в активном списке и списке неудач, записываются в список отмены. Никаких операций отмены не требуется, поскольку изменения еще не записаны на диск.
Транзакции, которые находятся в списке до фиксации, повторяются.
Никаких действий для транзакций в списках фиксации или прерывания не предпринимается.

Восстановление после сбоя диска

Сбой диска или аппаратный сбой приводят к полной потере базы данных. Для восстановления после этого жесткого сбоя подготавливается новый диск, затем восстанавливается операционная система и, наконец, база данных восстанавливается с использованием резервной копии базы данных и журнала транзакций. Метод восстановления одинаков как для режима немедленного, так и для отложенного обновления.

Менеджер восстановления выполняет следующие действия -

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

Контрольные точки

Checkpointэто момент времени, когда запись записывается в базу данных из буферов. Как следствие, в случае сбоя системы диспетчеру восстановления не нужно повторять транзакции, которые были зафиксированы до контрольной точки. Периодическая установка контрольных точек сокращает процесс восстановления.

Есть два типа контрольных точек:

Последовательные контрольные точки
Нечеткие контрольные точки

Последовательная контрольная точка

Согласованная контрольная точка создает непротиворечивый образ базы данных в контрольной точке. Во время восстановления отменяются или повторяются только те транзакции, которые находятся справа от последней контрольной точки. Транзакции слева от последней согласованной контрольной точки уже зафиксированы и не нуждаются в повторной обработке. Действия, предпринятые для установки контрольных точек:

Активные транзакции временно приостановлены.
Все изменения в буферах основной памяти записываются на диск.
Запись «контрольной точки» записывается в журнал транзакций.
Журнал транзакций записывается на диск.
Приостановленные транзакции возобновляются.

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

Нечеткая контрольная точка

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

Пример контрольной точки

Будем считать, что в системе время контрольной точки - tcheck, а время сбоя - tfail. Пусть существует четыре транзакции T _a , T _b , T _c и T _d такие, что -

T _a фиксируется перед контрольной точкой.
T _b запускается до контрольной точки и фиксируется до сбоя системы.
T _c запускается после контрольной точки и фиксируется до сбоя системы.
T _d запускается после контрольной точки и был активен во время сбоя системы.

Ситуация изображена на следующей диаграмме -

Действия, которые предпринимает менеджер восстановления:

С Т _а ничего не делается .
Повтор транзакции выполняется для T _b и T _c .
Отмена транзакции выполняется для T _d .

Восстановление транзакции с использованием UNDO / REDO

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

Восстановление транзакции в этих случаях представляет собой двухэтапный процесс:

ОТМЕНИТЬ все ошибочные транзакции и транзакции, на которые могут повлиять ошибочные транзакции.
ПОВТОРИТЕ все транзакции, которые не являются ошибочными, но были отменены из-за ошибочных транзакций.

Шаги для операции UNDO:

Если ошибочная транзакция выполнила INSERT, менеджер восстановления удаляет вставленные элементы данных.
Если ошибочная транзакция выполнила УДАЛИТЬ, диспетчер восстановления вставляет удаленные элементы данных из журнала.
Если ошибочная транзакция выполнила ОБНОВЛЕНИЕ, диспетчер восстановления удаляет значение, записывая значение перед обновлением из журнала.

Шаги для операции REDO:

Если транзакция выполнила INSERT, менеджер восстановления создает вставку из журнала.
Если транзакция выполнила DELETE, диспетчер восстановления создает удаление из журнала.
Если транзакция выполнила UPDATE, менеджер восстановления генерирует обновление из журнала.