Для розподілених СУБД виділяють наступні типи основних відмов, їх небагато:
1. Втрата повідомлення,
2. Відмова лінії зв'язку, аварійна
3. Зупинка одного з вузлів,
4. Розчленування мережі.
Для того, щоб ось якось в такому середовищі правильно відновлювати дані, є спеціальні процедури - процедури відновлення. При цьому проблема в розподіленої середовищі ускладнюється тим, що вимоги атомарности значень потрібні як щодо локальних, так і по відношенню до глобальних даних і глобальних транзакцій.
Розглянемо 2 протоколи:
1. протокол ліквідації;
2. протокол відновлення.
Почнемо з протоколу ліквідації. Отже: що таке протокол ліквідації, коли він запускається? Він запускається кожного разу, коли координатор або вузол не отримає очікуваного повідомлення - тайм-аут (тобто є якась затримка, протягом якої координатор транзакції або будь-який з вузлів не отримає відповідного повідомлення). Тайм-аут можливий в 2-х випадках з 4-х.
Багато їхні дії залежать від того, хто з них не отримав повідомлення, і яке саме повідомлення не було отримано. Розглянемо окремо координатор і окремо вузол.
І так ось для координатора транзакцій. І так при фіксації координатор в процесі виконання фіксації знаходиться в одному з 4 станів: Initial, Waiting, Decided, Completed.
Робиться команда prepare (Підготуватися), видається команда global decision, а потім підтвердження.
Значить time out в режимі (стані) Waiting: Координатор очікує підтвердження від всіх вузлів повідомлення про рішення про відкат або фіксації своїх подтранзакцій. Оскільки вузлів багато, координатор координатор розсилає всім команду зафіксувати транзакцію. І кожен з вузлів в залежності від того там в якому стані він знаходиться фіксує або не фіксує свою подтранзакцію. Якщо він в обумовлений час не отримає підтвердження на фіксацію транзакцій від всіх, він повинен запустити протокол ліквідації.
time out стані Decided: time out в цьому випадку фактично означає очікування надходження від всіх вузлів повідомлення про підтвердження фіксації. Тут вони йому кажуть «будемо ми фіксувати чи ні?», А далі він їм посилає, якщо від всіх отримав підтвердження, він їм каже «фіксуйте!», Тому що кожен з окремих вузлів не знає чи буде транзакція зафіксована чи ні. Кожен з них голосує спочатку за себе, що «Я готовий!». Тобто на цьому рівні кожен з них надсилає повідомлення, що «Я готовий!». Якщо координатор отримав таке повідомлення від усіх, то далі йде команда «фіксувати транзакцію», в іншому випадку, як я сказав, протокол ліквідації. Так ось далі йде час на те щоб вони підтвердили транзакцію, при цьому суть полягає в тому, що якщо будь-яким чином з вузлів в народних обранців зафіксує транзакцію, то, формально кажучи, проблема залишається в ньому і його там треба відповідним чином або перезапускати , або зупиняти і так далі і так далі ... але все решта вже так чи інакше зафіксовані.
вузол
У вузла теж еcть режим ініціалізації (Initial). Наступне стан в якому він може перебувати PREPARED. Далі або підтвердження COMMITED, або ABORTED.
У нього є time out в стані Initial. У цьому стані вузол чекає від координатора надходження команди PREPARE (приготуватися). Якщо ця команда не надходить від координатора, то вузол має право виконати односторонній відкат транзакції.
time out в стані PREPARED. Вузол вже послав координатору своє повідомлення, що він готовий підтвердити транзакцію, ну принаймні, свою локальну частину і чекає, коли координатор збере з усіх такі повідомлення і прийме загальне для всіх рішення підтвердити або скасувати транзакцію. Значить ось тут він чекає. Насправді в цьому випадку якщо можливий відкат транзакції, то є можливість звернутися до сусіднього вузла і запитати «а як у нас там?», «Яке рішення у нас там прийнято. ». Тобто ось такого роду дії вузлів між собою називається корпоративний протокол ліквідації.
протокол відновлення
Протокол відновлення запускається кожного разу, коли необхідно відновити роботу вузла після його відмови. Дії, що залежать від того хто відмовив: вузол або координатор. Трошки по порядку підемо.
Відмова координатора в стані Initial. Тобто він ще не ініціалізувати глобальну фіксацію транзакцій, тобто він відмовив. Відновлення полягає в запуску цієї процедури заново.
Друге. Відмова координатора в стані Waiting. Координатор направив команду опитування вузлів. «Чи готові зафіксувати транзакцію або не готові (свою локальну)?» Але нічого не отримав з вузлів з якихось причин. У цьому випадку відмова. Відновлення полягає в повторному запуску процедури фіксації транзакції.
Відмова координатора в стані Decided. Координатор вже направив повідомлення про глобальну фіксації або відмову. Тому тут треба просто перезапустити координатор. Якщо після перезапуску він отримає всі необхідні підтвердження, то можна вважати що транзакція завершилася успішно, якщо не отримає після перезапуску, то треба переступити до протоколу ліквідації. Що стосується вузла.
Відмова вузла в стані Initial. В цьому випадку вузол ще не проголосував.
відмова вузла
Оскільки вузол ще не проголосував з приводу завершення транзакції, він має право прийняти односторонню відмову, і якщо все добре - проголосувати за підтвердження транзакції. Відмова вузла в стані PREPARED, фактично це означає, що вузол вже відправив координатору повідомлення про те, що він готовий підтвердити транзакцію. Якщо він це відіслав, і після цього стався відмову, виникає проблема відновлення даних на цьому конкретному вузлі. Природно, що відмова може відбутися в будь-який момент, і після голосування, і потім що то у нього могло збитися, після цього все будуть підтверджувати транзакцію, і він теж, по ідеї повинен, підтверджувати, але якщо він її підтвердити не може, значить тут треба запускати протокол ліквідації окремого вузла, відновлення даних, все ж решта дані вже підтвердять, і скасувати тут нічого не можна.
Відмова вузла в стані ABORTED або COMMITED.
Це означає:
У COMMITED: вузол вже підтвердив транзакцію свою, а потім її фактично скасував, якщо після цього що щось сталося, то формально кажучи, ніяких дій загальних приймати не треба, тому що дані збережені, і якщо зламалося щось в компі, то в на мережу це не вплине. На практиці, в добре працюючих системах ймовірність блокування одних вузлів іншими, не така висока, то був запропонований протокол трьох фазної фіксації, який в даному випадку називається не блокуючим, який призводить до блокування транзакції тільки в одному випадку, всіх вузлів, що мало ймовірно. Для нормальної роботи такої розподіленої середовища, фактично досить, щоб хоча б один вузол був доступний. Основна ідея такої трифазної фіксації полягає в усуненні невизначеного періоду очікування, коли він блокує роботу. Вводиться третя фаза, яка називається предфіксація, яка знаходиться між фазами голосування і прийняття глобального рішення.
Вводиться додаткове повідомлення, глобальне - прекомі. Воно означає, що кожен вузол тепер знає, що все проголосували за фіксацію транзакції, і якщо що то станеться на окремому вузлі, то це проблеми того вузла, і вони будуть вирішуватися локально.