Изменения

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