|
БАЗИ ДАНИХ. МОВИ ЗАПИТІВ, УПРАВЛІННЯ ТРАНЗАКЦІЯМИ, РОЗПОДІЛЕНА ОБРОБКА ДАНИХ |
|
3.4 Відновлення розподілених баз даних
3.4.1 Особливості відновлення розподілених баз
даних
3.4.1 Особливості відновлення розподілених баз даних
Для розподілених СКБД характерні чотири типи відмов, а саме: - втрата повідомлення; - відмова лінії зв’язку; - аварійна зупинка одного з вузлів; - поділ мережі на окремі підмережі. Втрата повідомлень або порушення порядку слідування повідомлень можна усунути з використанням відповідного мережевого протоколу. Для досягнення нерозривності глобальної транзакції розподілена СКБД повинна забезпечувати або повну фіксацію всіх субтранзакцій глобальної транзакції, або аварійне завершення всіх субтранзакцій. Якщо в розподіленій СКБД буде виявлено, що деякий вузол відмовив або став недоступний, в ній необхідно виконати такі дії: 1. Аварійно завершити всі транзакції, які мають відношення до даної відмови. 2. Відзначити вузол як відмовив, щоб запобігти будь-яким спробам його використання іншими вузлами. 3. Періодично перевіряти стан вузла, що відмовив, для відновлення його функціонування або чекати надходження від цього вузла повідомлення із зазначенням про відновлення його нормальної роботи. 4. При перезапуску вузла після відмови на ньому повинна виконуватися процедура відновлення, призначена для відкату будь-яких транзакцій, виконаних на момент відмови лише частково. 5. Після завершення процедури локального відновлення вузол, що відмовив,повинен оновити свою копію бази даних, щоб привести її у відповідність з іншою частиною системи. Якщо має місце поділ мережі розподілена СКБД повинна гарантувати, що якщо агенти деякої глобальної транзакції виявилися активними в різних фрагментах, то вузол S1 та інші вузли одного фрагмента повинні бути позбавлені можливості зафіксувати результати цієї глобальної транзакції, оскільки вузол S2 та інші вузли іншого фрагмента можуть прийняти рішення виконати її відкат. Процеси відновлення в розподілених СКБД ускладнюються тим, що дотримуватись властивості нерозривність потрібно і до локальних субтранзакцій, і до всієї глобальної транзакції в цілому. З цієї причини в процедури фіксації і відкату транзакцій необхідно внести такі зміни, які не дозволять глобальній транзакції зафіксувати або відмінити результати її виконання, поки всі її субтранзакції не будуть успішно зафіксовані або відмінені. Крім того, модифіковані протоколи повинні реагувати на ситуації відмови вузла або лінії зв'язку таким чином, щоб можна було гарантувати, що відмова одного з вузлів не вплине на обробку даних на іншому вузлі. Протоколи, що забезпечують виконання останньої вимоги, називаються неблокуючими, найбільш поширеними з яких є протокол двофазної фіксації транзакцій (2РС) і неблокуючий протокол трифазної фіксації транзакцій (ЗРС). Тут передбачається, що кожна глобальна транзакція пов'язана з деяким вузлом, що функціонує як координатор (або диспетчер) виконання цієї транзакції. Зазвичай координатором є той вузол, на якому транзакція була ініційована. Вузли, на яких глобальна транзакція створила агенти, називаються учасниками (або диспетчерами ресурсів). Передбачається, що координатор транзакції має інформацію про ідентифікатори всіх учасників, а кожен учасник знає ідентифікатор координатора, але не зобов'язаний знати ідентифікатори інших учасників.
3.4.2 Протокол двофазної фіксації транзакцій (2РС)
Як випливає з назви даного протоколу, фіксація результатів транзакцій виконується в два етапи: голосування (фаза голосування) і прийняття рішення (фаза прийняття рішення). Основна ідея полягає в тому, що координатор повинен опитати всіх учасників, чи готові вони до фіксації транзакції. Якщо хоча б один з учасників зажадає відкату або не відповість на запит протягом встановленого тайм ауту, координатор вкаже всім учасникам на необхідність виконати відкат даної транзакції. Глобальне рішення повинно бути прийнято усіма учасниками. Якщо деякий учасник вимагає відкату транзакції, то він має право виконати його негайно. Фактично будь-який вузол має право виконати відкат своєї субтранзакціі в будь-який час, аж до того моменту, поки він не відправить згоду на її фіксацію. Подібний тип відкату називається одностороннім відкатом. Якщо учасник проголосував за фіксацію транзакції, то він повинен очікувати до тих пір, поки координатор не розішле повідомлення або про глобальну фіксацію, або про глобальний відкат цієї транзакції. Даний протокол передбачає, що кожен вузол має свій власний локальний журнал і з його допомогою може надійно виконати відкат або фіксацію транзакції. Двофазний протокол фіксації транзакцій включає етап очікування повідомлення від інших вузлів. Щоб уникнути небажаних блокувань процесів система використовує механізм контролю тайм-ауту. Для фіксації глобальної транзакції координатор виконує таку послідовність дій: Етап1 1. Занести запис begin_commit в системний журнал і забезпечити його примусовий запис з буфера у вторинну пам'ять. Надіслати всім учасникам команду PREPARE. Очікувати надходження відповідей від усіх учасників протягом встановленого тайм-ауту. Етап 2 2. Якщо учасник повертає повідомлення ABORT, помістити в системний журнал запис аварійного припинення та забезпечити його примусовий запис з буфера у вторинну пам'ять. Надіслати всім учасникам команду GLOBAL_ABORT. Очікувати відповіді від всіх учасників протягом встановленого тайм-ауту. 3. Якщо один з учасників повертає повідомлення READY_COMMIT, оновити список учасників, що надіслали свої відповіді. Якщо повідомлення про готовність фіксації надіслали всі учасники, помістити в системному журналі запис commit і забезпечити його примусовий запис з буфера у вторинну пам'ять. Надіслати всім учасникам команду GLOBAL_COMMIT. Очікувати відповіді від всіх учасників протягом встановленого тайм-ауту. 4. Після надходження всіх підтверджень про фіксацію транзакції помістити в системному журналі запис end_transaction. Якщо деякі вузли не надіслали підтвердження про фіксацію, знову направити на ці вузли повідомлення про прийняте глобальне рішення і діяти за цією схемою до отримання всіх необхідних підтверджень. При фіксації транзакції учасник виконує наступну процедуру. 1. При отриманні учасником команди PREPARE він виконує одну з таких дії: а) поміщає запис ready_commit в файл журналу і переносить з буфера у вторинну пам'ять всі записи, що відноситься до даної транзакції. Надсилає координатору повідомлення READY_COMMIT; б) поміщає запис abort в файл журналу і переносить його з буфера у вторинну пам'ять. Відправляє координатору повідомлення ABORT. Виконує односторонній відкат транзакції. 2. Очікування відповіді координатора триває протягом встановленого тайм-аут. 3. Якщо учасник отримує команду GLOBAL_ABORT, то він поміщає запис abort у файл журналу і переносить його з буфера у вторинну пам'яті. Виконує відкат транзакції і по його завершенні надсилає координатору відповідне підтвердження. Якщо учасник отримує команду GLOBAL_COMMIT, то він поміщає запис commit у файл журналу і переносить її з буфера у вторинну пам'ять. Потім виконується фіксація транзакції, звільнення всіх встановлених блокувань, після чого координатору надсилається відповідне підтвердження. Якщо учаснику не вдалось отримати від координатора команди про проведення голосування, то по закінченню встановленого тайм-ауту він просто виконує відкат даної транзакції. Тому ще до надходження команди про проведення голосування будь-який учасник може прийняти рішення про відкат субтранзакціі і виконати його локально. Учасник повинен очікувати надходження від координатора команди GLOBAL_COMMIT або GLOBAL_ABORT. Якщо протягом встановленого тайм-аут він не отримає ніякої команди або координатор не отримає відповідь від учасника, то передбачається, що на відповідному вузлі відбулася відмова і в роботі запускається протокол аварійного завершення (протокол завершення). Протокол аварійного завершення виконують тільки функціонуючі вузли, а вузли, що відмовили, після перезапуску виконують протокол відновлення.
3.4.3 Неблокуючий протокол трифазної фіксації транзакцій (ЗРС)
Протокол двофазного блокування не може усунути можливість блокування, оскільки при його використанні виникають ситуації, коли деякий вузол залишається заблокованим. Наприклад, процес, який виявив закінчення тайм-ауту після відправки своєї згоди на фіксацію транзакції, але так і не отримав глобального підтвердження від координатора, залишається заблокованим, якщо може взаємодіяти тільки з вузлами, які також не мають відомостей про прийняте глобальне рішення. На практиці ймовірність блокування процесу досить мала, тому в більшості існуючих розподілених СКБД використовується саме протокол двофазної фіксації транзакцій. Проте був запропонований альтернативний неблокуючий протокол трифазної фіксації транзакцій. Трифазна фіксація є неблокуючою в умовах відмови вузлів, за винятком випадку одночасної відмови всіх вузлів. Однак відмови ліній зв'язку можуть призвести до того, що на різних вузлах будуть прийняті різні рішення, що спричиняє спотворення нерозривності глобальної транзакції. Для використання цього протоколу, слід дотримуватись таких умов. - Поділ мережі є неприпустимим. - Принаймні один вузол завжди повинен бути доступний. - Може відмовити одночасно найбільше К вузлів мережі (тому такі системи називають К-стійкими). Основна перевага протоколу трифазної фіксації полягає в усуненні періоду очікування в стані невизначеності, в яке переходять учасники з моменту підтвердження своєї згоди на фіксацію транзакції і до моменту отримання від координатора сповіщення про глобальну фіксацію або глобальний відкат. У трифазному протоколі фіксації між етапами голосування і прийняття глобального рішення вводиться третій етап попередньої фіксації. Після отримання результатів голосування від всіх учасників координатор розсилає глобальне повідомлення PRE-COMMIT. Учасник, який отримав глобальне повідомлення про попередню фіксацію, знає, що всі інші учасники проголосували за фіксацію результатів транзакції і що з часом сам цей учасник безумовно виконає фіксацію транзакції, якщо не відбудеться відмови. Кожен учасник підтверджує отримання повідомлення про попередню фіксацію. Після того як координатор отримає всі ці підтвердження, він розсилає команду глобальної фіксації транзакції. Якщо деякий учасник зажадав відкату транзакції, то обробка цієї ситуації виконується так, як в протоколі двофазної фіксації. Як координатор, так і учасник як і раніше переходять на деякий час в стан очікування, однак головна особливість полягає в тому, що всі функціонуючі процеси отримують інформацію про глобальне рішення зафіксувати транзакцію за допомогою відправки повідомлення PRE-COMMIT ще до того, як перший процес виконає фіксацію результатів транзакції, що дозволяє учасникам діяти незалежно один від одного в разі відмови.
Дії, які виконуються при перезапуску системи після відмови, залежать від того, на якому етапі обробки глобальної транзакції знаходились координатор або учасник до моменту відмови. Відмова координатора Розглянемо три різні варіанти відмови вузла-координатора. 1. Відмова в стані INITIAL. Координатор ще не почав процедуру фіксації транзакції. В даному випадку відновлення полягає в запуску цієї процедури фіксації. 2. Відмова в стані WAITING. Координатор вже направив команди PREPARE вузлам учасникам, і, хоча отримані ще не всі відповіді, жодної пропозиції про відкат отримано не було. У цьому випадку відновлення полягає у повторному запуску процедури фіксації транзакції. 3. Відмова в стані DECIDED. Координатор вже направив учасникам транзакції вказівки про її глобальну фіксацію або глобальний відкат. Якщо після перезапуску координатор отримає всі необхідні підтвердження, завершення транзакції можна вважати успішним. В іншому випадку потрібно вдатися до використання протоколу аварійного завершення. Відмова учасника Метою застосування протоколу відновлення на вузлі-учаснику є отримання гарантій, що після перезапуску системи учасник виконає у відношенні транзакції ті ж дії, що і всі інші учасники її виконання, і ці дії можуть бути виконані незалежно (тобто без необхідності проведення консультацій з координатором або іншими учасниками). Розглянемо три різні варіанти відмови вузла-учасника. 1. Відмова в стані INITIAL. Учасник ще не встиг проголосувати за спосіб завершення транзакції. Тому в процесі відновлення він може виконати відкат транзакції в односторонньому порядку, оскільки без отримання відомостей від даного вузла-учасника координатор не може прийняти рішення про глобальну фіксацію цієї транзакції. 2. Відмова в стані PREPARED. Учасник вже направив відомості про своє рішення на адресу координатора. У цьому випадку відновлення полягає в застосуванні протоколу аварійного завершення. 3. Відмова в стані ABORTED / COMMITTED. Учасник вже завершив обробку транзакції. Тому після перезапуску подальших дій не потрібно.
3.4.5 Протоколи аварійного завершення
Протокол аварійного завершення виконується кожен раз, коли координатор або учасник не отримує очікуваного повідомлення до закінчення тайм-ауту. Дії залежать від того, хто не отримав повідомлення, координатор або учасник, і яке саме повідомлення не було отримано. Координатор В процесі виконання фіксації транзакції координатор може перебувати в одному з чотирьох станів: INITIAL, WAITING, DECIDED і COMPLETED. У подібних випадках робляться такі дії. - Тайм-аут в стані WAITING. Координатор очікує надходження від усіх учасники повідомлень про рішення, яке вони прийняли щодо фіксації або відкату даної транзакції. У подібній ситуації координатор не може зафіксувати транзакцію, оскільки він не отримав усі необхідні підтвердження, тому він організовує дії по глобальному відкату даної транзакції. - Тайм-аут в стані DECIDED. Координатор очікує надходження від усіх учасники повідомлень про успішний відкат або фіксацію даної транзакції. У подібній ситуації координатор просто повторно розсилає відомості про прийняте глобальне рішення на всі вузли, які не надіслали очікуваного підтвердження. Учасник Найпростіший протокол аварійного завершення для учасника полягає у збереженні процесу на стороні учасника заблокованим до тих пір, поки з'єднання з координатором не буде поновлено. Після цього учасник зможе отримати інформацію про прийняте глобальне рішення і відновити обробку транзакції відопвідним чином. Однак з міркувань підвищення продуктивності системи на стороні учасника можуть бути вжиті й інші дії. В процесі виконання фіксації транзакції учасник може перебувати в одному з чотирьох станів: INITIAL, PREPARED, ABORTED і COMMITTED. Але учасник може завершити роботу по тайм-ауту тільки в перших двох станах, як описано нижче. - Тайм-аут в стані INITIAL. Учасник очікує від координатора надходження команди PREPARE. Її відсутність може свідчити про те, що вузол координатора відмовив, коли процес фіксації транзакції знаходився в стані INITIAL. У цьому випадку учасник може виконати відкат транзакції в односторонньому порядку. При надходженні згодом команди PREPARE він зможе або її ігнорувати (в результаті чого координатор організовує відкат глобальної транзакції по тайм-ауту), або відправити координатору повідомлення ABORT. - Тайм-аут в стані PREPARED. Учасник очікує надходження від координатора вказівок про глобальну фіксації або глобальний відкат даних транзакції. Учасник вже сповістив координатора про своє рішення зафіксувати транзакцію, тому не має права змінити своє рішення і виконати її відкат. Але він також не може продовжити роботу і зафіксувати транзакцію, оскільки глобальне рішення може виявитися вимогою її відкату. До отримання додаткової інформації учасник виявляється заблокованим. Але учасник може звернутися до кожного з решти учасників транзакції, щоб отримати від одного з них відомості про прийняте глобальне рішення. Цей варіант відомий як кооперативний протокол аварійного завершення. Найпростіший спосіб повідомити учасникам про те, хто ще бере участь у виконанні транзакції, полягає в приєднанні до команди про проведення голосування список вузли-учасники. Хоча кооперативний протокол аварійного завершення знижує ймовірність виникнення блокування, ця ситуація як і раніше залишається можливою, і для заблокованого процесу не залишається іншого виходу, крім повторних спроб зняти блокування до отримання інформації про усунення відмови. Якщо відмова сталася тільки на вузлі координатора (всі інші учасники можуть встановити це в результаті виконання протоколу аварійного завершення), вони зможуть вибрати нового координатора і таким чином зняти блокування.
|
|
Пєтух А.М., Романюк О.В., Романюк О.Н. ВНТУ 2016 |