Pentru SGBD distribuite, se disting următoarele tipuri de eșecuri de bază, există puține dintre ele:
1. Pierderea mesajului,
2. Eșecul liniei de comunicație, urgență
3. Opriți unul dintre noduri,
4. Dezmembrarea rețelei.
Pentru a restabili într-un mod corect datele într-un astfel de mediu, există proceduri speciale - proceduri de recuperare. În același timp, problema într-un mediu distribuit este complicată de faptul că cerințele privind atomicitatea valorilor sunt necesare atât pentru datele locale, cât și pentru cele globale și tranzacțiile globale.
Luați în considerare două protocoale:
1. procesul verbal al lichidării;
2. protocol de recuperare.
Să începem cu protocolul de lichidare. Deci, care este protocolul de eliminare când este lansat? Se execută ori de câte ori coordonatorul sau nodul nu primește mesajul așteptat - un timeout (ex. Există o anumită întârziere în timpul căreia coordonatorul tranzacției sau oricare dintre noduri nu primește mesajul corespunzător). O expirare este posibilă în 2 din 4 cazuri.
Multe dintre acțiunile întreprinse depind de cine nu a primit mesajul și care mesaj nu a fost primit. Luați în considerare separat coordonatorul și separat nodul.
Și aici și pentru coordonatorul tranzacțiilor. Astfel, la stabilirea coordonatorului în timpul procesului de angajare se află una din cele 4 stări: inițială, în așteptare, hotărâtă, finalizată.
Se efectuează comanda de pregătire, se emite o comandă de decizie globală, urmată de o confirmare.
Deci, timp în (stare de) așteptare: așteapța coordonator pentru o confirmare de la toate nodurile de notificare a deciziei de a derula înapoi sau să comită subtransaction lor. Deoarece există mai multe noduri, coordonatorul trimite o comandă pentru a angaja tranzacția pentru toți. Și fiecare dintre noduri, în funcție de dacă există în ce stare se fixează sau nu își fixează subtransacția. Dacă nu primește confirmarea la o anumită perioadă de timp pentru a angaja tranzacții de la toată lumea, trebuie să lanseze protocolul de lichidare.
time out state Decide: termenul de expirare în acest caz înseamnă, de fapt, așteptarea primirii de la toate nodurile a confirmării comiterii. Aici, ei i spun, „vom repara sau nu?“, Apoi a le trimite, în cazul în care toate au primit o confirmare, el spune ca „repara!“, Pentru că fiecare dintre unitățile individuale știu dacă o tranzacție este angajată sau nu. Fiecare dintre ei votează inițial pentru el însuși, că "Sunt gata!". Adică, la acest nivel, fiecare dintre ei trimite un mesaj "Sunt gata!". Dacă coordonatorul a primit un astfel de mesaj de la toată lumea, atunci comanda "comiteză tranzacția" se desfășoară, altfel, așa cum am spus, protocolul de lichidare. Deci, în plus vine timp pentru ei pentru a confirma tranzacția, linia de jos este că, dacă vă place oricare dintre nodurile din acest moment nu rezolvă tranzacția, în mod formal vorbind, problema rămâne în ea și nu trebuie să fie adecvată sau repornire , sau opriți și așa mai departe și așa mai departe ... dar toate celelalte sunt deja fixate într-un fel sau altul.
nod
Nodul are, de asemenea, un mod de inițializare. Următoarea stare în care poate fi pregătită. Mai mult, fie confirmarea COMMITED, fie ABORTED.
Are un timp de ieșire în starea inițială. În această stare, nodul așteaptă de la coordonatorul comenzii PREPARE (pregătiți-vă). Dacă această comandă nu vine de la coordonator, atunci nodul are dreptul să efectueze o revigorare unică a tranzacției.
time out în starea PREPARED. Coordonator Nodul a trimis deja mesajul său că el este pregătit pentru a confirma tranzacția, și cel puțin o parte locală și așteaptă coordonatorul va colecta toate aceste rapoarte și să ia decizia comună tuturor pentru a confirma sau a anula tranzacția. Deci, aici așteaptă. De fapt, în acest caz, dacă este posibil, rola înapoi tranzacția, este posibil de a face apel la nodul următor, și întreabă: „Ce avem acolo?“, „Care este soluția am adoptat acolo. “. Adică, acest tip de acțiune a nodurilor se numește un protocol de lichidare corporativă.
Protocolul de recuperare
Protocolul de recuperare se execută de fiecare dată când trebuie să restabiliți activitatea nodului după eșec. Acțiunile întreprinse depind de persoana care a refuzat: nodul sau coordonatorul. Un pic în ordine va merge.
Eșecul coordonatorului în starea inițială. Adică, nu a inițializat încă comiterea globală a tranzacțiilor, adică a refuzat. Restaurarea constă în pornirea din nou a procedurii.
Al doilea. Eșecul coordonatorului în starea de așteptare. Coordonatorul a trimis o comanda de sondaj de echipa. "Sunteți gata să faceți tranzacția sau nu sunteți gata (local)?" Dar nu am obținut nimic din noduri din vreun motiv. În acest caz, eșec. Recuperarea constă în repornirea procedurii de comitere a tranzacției.
Eșecul coordonatorului în starea decisă. Coordonatorul a trimis deja un mesaj despre comiterea globală sau eșecul. Prin urmare, trebuie doar să reporniți coordonatorul. Dacă repornit, acesta va primi toate aprobările necesare, putem presupune că tranzacția este de succes dacă nu primiți după repornire, este necesar să se meargă dincolo de eliminarea protocolului. În ceea ce privește nodul.
Eșec gazdă în starea inițială. În acest caz, nodul nu a votat încă.
Eșecul gazdei
Având în vedere că unitatea încă nu a votat tranzacția este completă, aceasta are dreptul de a lua refuz unilateral, iar dacă totul este bine - să voteze pentru confirmarea unei tranzacții. Eșecul nodului în starea PREPARAT, în fapt, înseamnă că nodul a trimis deja un mesaj coordonatorului că este gata să confirme tranzacția. Dacă a trimis-o și după aceea a avut un eșec, există o problemă de recuperare a datelor pe acest nod particular. Desigur, că eșecul poate apărea în orice moment, și după vot, și apoi ceva ce a putut da jos, atunci totul va confirma tranzacția, și de asemenea, trebuia sa, recunosc, dar dacă el a confirmat nu poate, atunci aici este necesar să se pornească protocolul de lichidare a unui nod separat, recuperarea datelor, încă alte date vor fi deja confirmate și nimic nu poate fi anulat aici.
Un eșec al nodului în starea ABORTED sau COMMITED.
Aceasta înseamnă:
În angajat: nod este confirmat deja tranzacția, atunci este de fapt anulat, în cazul în care este apoi că sa întâmplat ceva, formal vorbind, nici o acțiune comună să ia nu este necesar, deoarece datele sunt stocate, și dacă rupt ceva în computer, apoi la rețeaua nu este afectată. În practică, o bună probabilitate de blocare sistem de lucru unele noduri altele, nu atât de mare, protocolul trei blocare faze a fost propusă, care în acest caz nu este numit de blocare, care duce la blocarea tranzacției numai într-un singur caz, toate nodurile care sunt puțin probabil. Pentru funcționarea normală a unui astfel de mediu distribuit, este de ajuns că cel puțin un nod este disponibil. Ideea de bază a trei faze comite este de a elimina perioada de așteptare nedeterminată atunci când acesta va bloca. Introdus de-a treia etapă, care se numește predfiksatsiya, care se află între fazele de votare și adoptarea unor soluții globale.
Se introduce un mesaj suplimentar, se introduce un mesaj global. Aceasta înseamnă că fiecare nod știe acum că toată lumea a votat pentru a comite tranzacția și dacă se întâmplă ceva pe un nod separat, atunci aceasta este problema acelui nod și acestea vor fi rezolvate la nivel local.
Articole similare
Trimiteți-le prietenilor: