Изменения

Участвует несколько узлов. Транзакция должна быть либо зафиксирована на всех узлах, либо на всех откачена. Бывают сбои как самих участников, так и каналов коммуникаций между ними.<br> == Набор требований к распределенным базам данных, которых хотят достигнуть Задача двух генералов == === Требования по децентрализации Описание ===*Локальная независимость - узел должен функционировать даже в изоляции(имеется в виду отвечать как [[Файл:Distributed TwoGenerals.png|300px|right]] Две армии, каждая руководимая своим генералом, готовятся к штурму города. Лагеря этих армий располагаются на запросы на чтениедвух холмах, так разделённых долиной. Единственным способом связи между генералами является отправка посыльных с сообщениями через долину. Но долина занята противником и на изменениелюбой из посыльных может быть перехвачен. Проблема заключается в том, что, генералы заранее (пока была связь)приняли принципиальное решение о штурме, но не согласовали точное время штурма. Для успешного штурма генералы должны атаковать город одновременно. Штурм, предпринятый только одной армией, приведет к катастрофическим последствиям для атакующих. Требуется найти алгоритм обмена сообщениями, после которого каждый генерал был бы уверен, что они оба атакуют в указанное время.<br>* Отсутствие центрального узла=== Вероятностное решение === Послать гонца, так как при его наличии засечь время и отключении ждать подтверждения. Если по истечению времени гонец не выполнится локальная независимостьвернулся, посылаем следующего.<br>* Непрерывное функционирование;=== Доказательство отсутствия гарантированного решения ===Пусть существует конечный протокол, тогда существует минимальное по включению множество сообщений. Пусть последнее сообщение не доставлено, тогда принять решение нельзя.<br>** Надежность; == Протокол двухфазной фиксации == Протокол двухфазной фиксации (фаза подготовки и фаза фиксации) нужен для того, чтобы при завершении транзакции все изменения, произведенные над всеми ресурсами, либо полностью фиксировались, либо полностью откатывались. После завершения транзакции результат сообщается всем участникам. === Описание алгоритма === [[Файл:Двухфазная_фиксация.png|600px|right]]Один из узлов выбирается координатором, обычно узел, к которому пришел исходный запрос.<br>** ДоступностьВ реальности в системе могут исполняться параллельно несколько транзакций, у которых разные координаторы.<br>   ==== Требования по прозрачности Первая фаза ====* Независимость от расположенияКоординатор всем участникам посылает сообщение приготовиться к коммиту;<br>** Программы могут работать на любом узле (Узлы, участвующие в транзакции, присылают информацию что они готовы зафиксировать данные действительно хранятся распределенно , что нет несогласованности в отличие от репликации)данных, ничего не сломалось;<br>** Удаленный доступ к данным (должны уметь сделать любой запрос на любом узле)Когда координатор подтверждение от всех, он принимает решение;<br>Распределенная БД должна логически себя вести как одна большая БД* Если от всех узлов было положительное решение, то он примет решение выполнить.<br> ====Вторая фаза = Независимость от фрагментации ===* Программы не знают на каком узле находятся данныеКоординатор всем участникам пришлет свое положительное решение, а они ему присылают информацию в ответ, что запрос был выполнен.<br>* Унифицированный доступ к даннымПосле завершения второй фазы, когда было получен положительный ответ от всех участников, координатор говорит, что транзакцию была завершена и шлет это в ответ на исходный запрос.<br>* Географическое секционированиеУ реплики есть момент неопределенности: между моментом, как была послана информация, что данные готовы быть зафиксированы, но ответ от координатора, что делать с транзакцией, еще не пришел.<br> === Независимость от репликации Обработка сбоев координатора ===* Автоматическая поддержка репликацииДо принятия решения {{---}} транзакция должна быть откачана.<br>* Выбор узла для обновленияПри принятии решении координатор сразу же записывает его в transaction log и при восстановении он вспомнит о принятом решении и исполнит его.<br> === Распределенные транзакции Обработка сбоев участников ===* Поддержка распределенных запросов.До отправки готовности координатору {{---}} откат после восстановления;<br>** Один запрос получает данные с разных узловДо получения решения {{---}} запрашивает у координатора;<br>** Несколько узлов могут участвовать При получении решения {{---}} записывает в одной транзакцииtransaction log;<br>** Должна быть согласованность фиксаций После получения решение {{---}} выполняет решение, отправляет подверждение, записывает в transaction log.<br> Данные обработки все работает при краткосрочных сбоях, однако, так как в общем случае задача неразрешима, существуют вырожденные случаи последовательных сбоев в коммуникации, которые не позволят ни координатору, ни участнику продвинуться. === Улучшение протокола === Координатору требуется помнить решение между принятием и откатаподтверждениями исполнения.<br> ====Протокол предполагаемой фиксации====* Независимость от окруженияПри решении «фиксировать» {{---}} «забыть» транзакцию.<br>** От аппаратурыНеизвестная транзакция {{---}} фиксировать.<br> Работает, когда количество фиксированных транзакций сильно превышает количество откаченных, то есть должны быть унифицированное представление данных;экономим таким образом память.<br> Может произойти ложная фиксация.<br> Сбой на первой фазе.<br>** От ОСЕсли происходит «потеря» транзакции, а информация не была записана в лог, то есть должна быть конвертация данных и поддержка разных ОС;участникам придет ответ «фиксировать»<br> ====Протокол предполагаемого отката====*При решении «откатить» {{---}} «забыть» транзакцию.<br>* От сети, например, в дата центрах будет быстрая локальная связь;Неизвестная транзакция {{---}} откатить.<br> Не можем случайно зафиксировать транзакцию {{---}} надежнее.<br>** От типа СУБДТратим гораздо больше памяти, хотелось бы уметь делать распределенную БД, которая обслуживается разными системами управления БД (Oracle, Postgres, etc). Но в реальности все очень печальноно не всегда это критично.<br>