8. Целостность данных и протоколы обеспечения надежности.

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

РСУБД различают 4 типа сбоев:

1) Сбой транзакций;

Причинами сбоев транзакций могут быть:

• Ошибки, вызванные неверными входными данными;

• Обнаружение возникшего или возможного тупика.

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

2) Сбой узла (системы);

Могут быть вызваны:

• Аппаратными отказами (процессора, ОЗУ);

• Программными ошибками (в системе или программном коде).

Следствие системных сбоев (сбоев узлов) это потеря содержимого оперативной памяти, в частности буферов оперативной памяти.

Неустойчивой БД называется часть БД, хранимая в буферах.

В тоже время данные, находящиеся во внешней памяти остаются в сохранности (эта часть БД называется стабильной БД).

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

В РСУБД проблема системных сбоев выражается еще и в том, что отказавший узел не может участвовать в транзакции.

3) Сбой носителя (диска);

Сбои носителей связаны с отказами устройств внешней памяти, на которой хранится стабильная БД. Обычно эта проблема решается путем применения дуплексных (дублирующих?) устройств и поддержания архивных копий БД.

Рассмотренные ранее типы сбоев характерны и для централизованных и для распределенных СУБД.

4) Сбой коммуникационной линии.

Коммуникационные сбои являются специфической проблемой РСУБД.

Коммуникационные сбои подразделяются на несколько разновидностей, наиболее распространенные из них:

• Ошибки в сообщениях;

• Нарушение упорядоченности сообщений;

• Потерянные или недостаточные сообщения;

• Повреждения на линиях связи.

Первые 2 разновидности находятся в компетенции сетевых протоколов. 3 и 4 разновидности в ведении СУБД и они должны учитываться в протоколах обеспечения надежности.

Если один узел ожидает сообщение от другого, а оно не поступает, может быть несколько причин этого:

• Сообщение утрачено;

• Возникло повреждение на линии связи;

• Узел, от которого ожидается сообщение, отказал.

В любом случае ожидающий узел по истечению определенного промежутка времени просто решает, что узел-партнер стал недоступен.

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

Протоколы, обеспечения надежности поддерживают 2 свойства транзакции:

• Атомарность – означает, что выполняются либо все действия транзакции, либо не выполняется ни одно. Гарантируется даже в условиях возможных отказов.

• Долговечность – означает, что результат успешно завершенной (зафиксированной) транзакции сохраняется даже при последующих сбоях.

Для обеспечения этих свойств необходимы протоколы атомарной фиксации и протоколы распределенного восстановления.

Если РБД однородна, т.е. на всех узлах данные хранятся в формате одной БД и на всех узлах функционирует одна и также СУБД, то протоколом атомарной фиксации является протокол двухфазной фиксации транзакции, состоит из двух фаз:

• Подготовка фиксации транзакции (голосование);

• Глобальные фиксации и откаты транзакций (принятие решений).

3 основных принципа:

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

• Если все узлы голосуют за фиксацию транзакции, то она фиксируется на всех участвующих в ней узлах.

• Проголосовавшая часть не может изменить свое решение.

Участникам, проголосовавшим за прерывание транзакции, сообщения об этом посылать не нужно, поскольку они сами способны принять это решение исходя из правил протокола двухфазной фиксации. Эта ситуация известна как «опция одностороннего прерывания».

Если время ожидания исчерпано, то ждущий процесс (координатор или участник) следует протоколу «терминирования».

Протокол «терминирования» это протокол, при помощи которого отдельный узел может принять решение о том, как завершить транзакцию в условиях, когда он не может взаимодействовать с другими участвующими в данной транзакции узлами.

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

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

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

• Расчленение сети не должно иметь место;

• По крайней мере 1 узел всегда должен быть доступен.

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

В этом протоколе вводится 3я фаза между первыми двумя, называемая предфиксация.

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

Обратной стороной терминирования является восстановление.

Вопрос: какие действия должен предпринять восстанавливающийся после сбоя узел-координатор, чтобы привести базу в корректное состояние? Возможны следующие случаи:

1) Сбой произошел до начала процедуры фиксации (в этом случае узел может заново начать процесс фиксации после восстановления).

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

3) Сбой произошел после того, как координатор сообщил участникам о глобальном решении и завершил транзакцию. В этом случае ничего делать не нужно.

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