Meniul
AcasăInstrucțiuni

Vezi ce este „ACID” în alte dicționare. Tranzacții. Proprietățile tranzacțiilor cu ACID. Managementul recuperării. algoritmul BERBEC. Fixare în două faze

Aceasta este, de asemenea, o bază de date, dar manuală

Buna ziua!

Să vorbim despre baze de date. Astăzi tranzacțiile, teorema ACID și CAP este o teorie importantă pentru articolele următoare.

Tranzacții

O tranzacție este un set de acțiuni de date combinate într-o unitate logică. Este fie complet executat, fie nu. Un exemplu clasic cu operația de transfer de bani din cont în cont:

Începeți tranzacția citiți soldul contului numărul 5 reduceți soldul cu 10 unități monetare salvați balanta noua contul numărul 5 citiți soldul contului numărul 7 măriți soldul cu 10 unități monetare salvați noul sold al contului numărul 7 Încheiați tranzacția

Dacă aceste operațiuni sunt efectuate în afara unei tranzacții, atunci o eroare în oricare dintre ele va lăsa ambele conturi într-o stare inconsistentă: de exemplu, se va dovedi că banii sunt retrase dintr-un cont, dar nu sunt primiți în celălalt. Nu există astfel de probleme cu o tranzacție - dacă apare o eroare, toate operațiunile vor fi anulate și nimic nu se va schimba pentru utilizator.

Totul sună simplu atunci când un singur utilizator lucrează la baza de date: el execută tranzacții una după alta și nu are nicio problemă cu o tranzacție care interferează cu alta. Totul se schimbă atunci când sunt mulți utilizatori.

Acesta este ceea ce se poate întâmpla atunci când rulați tranzacții neizolate în paralel.

Actualizare pierdută
Când sunt înregistrate două tranzacții sensuri diferiteîn aceeași celulă, una dintre modificări se pierde.

Lectură murdară
Când sunt citite datele, care în acel moment sunt modificate de tranzacție, apoi tranzacția este anulată și datele dispar.

Lectură nerepetitivă
Când datele sunt citite de mai multe ori, care în acel moment sunt modificate de tranzacție, de fiecare dată datele pot fi respinse de alții.

Lectură fantomă
În timpul executării sale, o tranzacție selectează mai multe rânduri folosind același criteriu de mai multe ori. O altă tranzacție, între aceste selecții, adaugă sau șterge rânduri sau modifică coloane ale unora dintre rândurile utilizate în criteriile de selecție a primei tranzacții și se finalizează cu succes. Ca rezultat, se dovedește că aceleași selecții din prima tranzacție produc seturi diferite de rânduri.

Izolarea tranzacției

Pentru ca tranzacțiile paralele să poată fi executate fără a interfera unele cu altele, au venit cu conceptul de izolare a tranzacțiilor. Există patru niveluri de izolare în total, dar unele baze de date își introduc propriile niveluri.

Citiți datele neangajate
Cel mai nivel scăzut izolare. Puteți citi liber modificările neangajate din alte tranzacții, dar scrierea este strict secvențială. În acest fel, doar problema actualizărilor pierdute este eliminată: este garantat că în cele din urmă toate tranzacțiile la rândul lor vor scrie valoarea necesară în celulă.

În mod obișnuit, acest lucru se face prin utilizarea unei blocări de scriere a celulelor destinate să fie modificate în cadrul tranzacției curente. Nu sunt puse lacăte la citire.

Citiți datele angajate
Puteți citi liber toate modificările din tranzacția dvs. și modificările înregistrate în tranzacțiile altor persoane. Actualizările pierdute și citirile murdare sunt eliminate, în timp ce problemele citirilor irepetabile și ale fantomelor rămân.

Lectură repetabilă
Puteți citi toate modificările numai ale tranzacției dvs. Datele modificate de alte tranzacții nu sunt disponibile. Singura problemă care rămâne este citirile fantomă.

Serializabil
Tranzacțiile sunt complet izolate unele de altele, fiecare executată ca și cum nu ar exista tranzacții paralele.

ACID

Acesta este un set de patru cerințe pentru sistem de tranzacții, asigurând cea mai fiabilă și previzibilă funcționare. Nu toate bazele de date implementează complet ACID.

Atomicitatea
Atomicitatea asigură că fiecare tranzacție va fi finalizată complet sau deloc. Stările intermediare nu sunt permise.

Consecvență
Consecvența este o cerință conform căreia tranzacția va avea ca rezultat date valide. Aceasta nu este o chestiune de tehnologie, ci de logica de afaceri: de exemplu, dacă suma de bani dintr-un cont nu poate fi negativă, logica tranzacției trebuie să verifice dacă vor rezulta valori negative.

Izolare
Se asigură că tranzacțiile concurente nu afectează rezultatul altor tranzacții. Ne-am ocupat mai sus de izolare.

Durabilitate
Modificările rezultate din tranzacție trebuie să rămână păstrate indiferent de eventualele eșecuri. Cu alte cuvinte, dacă utilizatorul a primit un semnal că tranzacția a fost finalizată, poate fi sigur că datele au fost salvate.

teorema CAP

Se spune că în sistem distribuit Doar două dintre cele trei proprietăți pot fi atinse: consistență, disponibilitate și rezistență la partiție. Vă ajută să înțelegeți cum va funcționa un anumit sistem distribuit și la ce să vă așteptați de la acesta.

Consecvența datelor
Când în toate nodurile în fiecare moment de timp datele sunt consecvente unele cu altele, adică nu se contrazic. Dacă un nod are date într-o celulă de bază de date, toate celelalte noduri au aceleași date.

Disponibilitate
Când orice cerere poate fi procesată de sistem, indiferent de starea acestuia.

Toleranță de partiție
Când împărțirea sistemului în mai multe secțiuni izolate, nu duce la un răspuns incorect din partea fiecărei secțiuni: rețeaua dintre două noduri a căzut, dar fiecare dintre ele poate răspunde corect clienților săi.

Toate baze de date distribuite date într-un fel sau altul cel mai bun scenariu realizează două proprietăți din trei, sacrificându-le pe cele rămase.

Următorul articol este despre baze de date rare pe care nu le veți vedea în proiecte obișnuite. Aici va fi utilă toată această teorie.

7.1 Proprietăţile ACIDE

7.1.1 În timpul acestei teste de referință, sistemul în curs de testare trebuie să aibă proprietățile ACID (Atomicity, Consistency, Isolation, Durability) care sunt cheie pentru sistemele de procesare a tranzacțiilor.

7.1.2 Scopul acestei secțiuni este de a oferi o descriere informală Proprietăți ACIDEşi precizarea seriei de încercări care trebuie efectuate pentru a demonstra că deţinerea acestor proprietăţi este asigurată.

7.1.3 Nicio secvență finită de teste nu poate dovedi că proprietățile ACID sunt pe deplin acceptate. Este necesară trecerea testelor prescrise, dar nu condiție suficientă conformitatea cu cerințele de proprietate ACID. Cu toate acestea, de dragul unei raportări curate, numai testele specificate aici vor fi considerate necesare și numai acele teste ar trebui raportate în acest raport de testare de referință.
Notă: Scopul acestor teste este de a demonstra că principiile ACID sunt susținute de sistemul în curs de testare și sunt aplicate în timpul execuției testului. Ele nu sunt concepute pentru a fi teste cuprinzătoare de asigurare a calității.

7.1.4 În timpul execuției testului, trebuie aplicată configurația necesară pentru a asigura conformitatea deplină cu proprietățile ACID. Acest lucru se aplică atât bazei de date (inclusiv TPC-E și Definit de utilizator obiecte) și la sesiunile de baze de date utilizate pentru a efectua teste ACID și execuție benchmark.
Nota 1: Conceptul „configurare” include toate proprietățile și caracteristicile bazei de date care pot fi definite extern; include, dar nu se limitează la, fișiere de configurare și inițializare, setări de mediu, comenzi și stocate Proceduri SQL, module descărcabile și suplimente. De exemplu, dacă SUT se bazează pe jurnalele de anulare/returnare, atunci înregistrarea trebuie menținută pentru toate Tranzacțiile, inclusiv pentru cele care nu conțin o opțiune de derulare înapoi în Profilul Tranzacției.
Nota 2: În cazurile în care această testare de referință este implementată pe un sistem distribuit, trebuie efectuate teste pentru a verifica dacă Tranzacțiile procesate pe două sau mai multe noduri respectă proprietățile ACID.

7.1.5 Deși testele ACID nu testează toate tipurile de Tranzacții în acest domeniu de activitate, proprietățile ACID trebuie îndeplinite pentru toate Tranzacțiile.

7.1.6 Organizatorii care trimit rezultate TPC trebuie să efectueze teste ACID pe unul dintre sistemele pentru care este furnizat rezultatul, cu condiția să utilizeze același software implementări (de exemplu, sisteme de operare, DBMS, programe de tranzacții). De exemplu, conținutul acestui paragraf ar fi adecvat atunci când Rezultatele sunt furnizate pentru mai multe sisteme din aceeași linie de produse. Cu toate acestea, testele de rezistență descrise în clauzele 7.5.2.2, 7.5.2.3 și 7.5.2.4 trebuie să fie trecute pe toate sistemele evaluate. Toate FDR-urile trebuie să afișeze sistemele utilizate pentru a verifica cerințele ACID, precum și Descriere completa testele ACID aplicate și rezultatele obținute la acestea..

7.2 Cerințe de atomicitate

7.2.1 Definirea proprietății de atomicitate

Sistemul testat trebuie să se asigure că Tranzacțiile cu baze de date sunt atomice; sistemul fie va finaliza toate operațiunile individuale asupra datelor, fie se va asigura că niciuna dintre operațiunile finalizate parțial nu are vreun efect asupra datelor în vreun fel.

7.2.2 Teste de atomicitate

Executați tranzacția de tranzacționare pe piață prin setarea indicatorului roll_it_back la 0. Verificați dacă au fost adăugate rândurile corespunzătoare la tabelele TRADE și TRADE_HISTORY.
Executați tranzacția de tranzacționare cu comandă de piață setând indicatorul roll_it_back la 1. Verificați dacă nu au fost adăugate rânduri asociate cu tranzacția de comandă de tranzacționare la tabelele TRADE și TRADE_HISTORY.

7.3 Cerințe de secvență

7.3.1 Definirea proprietății Sequence

Consistența este o proprietate a Aplicației care asigură că orice execuție a unei Tranzacții cu baze de date va duce la tranziția acesteia de la o stare la alta.

7.3.1.1 Baza de date TPC-E populată prima dată utilizând EgenLoader trebuie să aibă proprietăți de secvență.

7.3.1.2 În cazul în care datele sunt replicate conform prevederilor de la clauza 2.3.3.3, fiecare copie trebuie să respecte starea secvenței descrise în clauza 7.3.2.

7.3.2 Stări de secvență
Următoarele paragrafe definesc cele trei stări de secvență. Fiecare dintre cele trei condiții necesită o demonstrație clară că condițiile sunt îndeplinite.

7.3.2.1 Starea secvenței 1


B_NUM_TRADES = numărare(*)

pentru fiecare broker, definit prin următoarele:



7.3.2.2 Starea secvenței 2

Înregistrările din tabelele BROKER și TRADE trebuie să respecte relația:

B_COMM_TOTAL = suma(T_COMM)

pentru fiecare broker definit de următoarele:

(B_ID = CA_B_ID) și (CA_ID = T_CA_ID) și (T_ST_ID = „CMPT”).

7.3.2.3 Starea secvenței 3

Înregistrările din tabelele HOLDING_SUMMARY și HOLDING trebuie să respecte relația:

HS_QTY = suma(H_QTY)

pentru fiecare grup de active definite de următoarele:

(HS_CA_ID = H_CA_ID) și (HS_S_SYMB = H_S_SYMB).

7.3.3 Teste de secvență
Testarea pâlnie în trei stări ar trebui efectuată atât după însămânțarea inițială a bazei de date, cât și după orice teste de recuperare a afacerii.

7.4 Cerințe de izolare

7.4.1 Determinarea proprietății de izolare

7.4.1.1 Având în vedere Tranzacția T1 și Tranzacția T2 care se execută simultan, pot fi descrise următoarele fenomene (de la P0 la P3) care au loc în T1.

  • P0 (Dirty Write) - Tranzacția T2 modifică (sau injectează) elementele de date ale lui R. Apoi, înainte ca acțiunile COMMIT ale tranzacției T2 să aibă loc, începe Tranzacția T1, care poate modifica (sau șterge) elementele de date ale lui R și poate apoi emite un COMMIT.
Notă: T2 poate efectua operațiuni suplimentare de bază de date pe baza stării în care a lăsat elementele lui R, creând o potențială problemă de consistență a datelor.
  • P1 (Dirty Read) - Tranzacția T2 modifică (sau inserează) elementele de date R. Apoi, înainte ca T2 să emită un COMMIT, Tranzacția T1 începe, citește elementele de date R și este capabil să recupereze starea elementelor de date așa cum a fost după T2 schimbat. Ulterior, T2 poate efectua o operație ROLLBACK.
Notă: T1 poate efectua operațiuni suplimentare de bază de date pe baza stării elementelor de date ale lui R care au fost anulate și se presupune că nu au existat niciodată, creând potenţială problemă secvențe de date.
  • P2 (“Non-repeatable read”) - Tranzacția T1 citește elementele de date R. Apoi, înainte ca Tranzacția T1 să efectueze un COMMIT, începe Tranzacția T2, care modifică (sau șterge) elementele de date R și emite un COMMIT. T1 repetă apoi citirea elementelor de date R și poate obține starea elementelor de date după ce a fost modificat de Tranzacția T2.
Notă: Înainte de a detecta starea modificată (sau ștearsă) a elementelor de date R, T1 ar putea efectua operațiuni suplimentare de bază de date pe baza stării elementelor de date R care nu mai sunt considerate valide, creând o potențială problemă de consistență a datelor.
  • P3 („Phantom Read”) - Tranzacția T1 citește un set de elemente de date care corespund cuiva. Apoi, înainte ca Tranzacția T1 să efectueze o operațiune COMMIT, Tranzacția T2 începe și inserează sau șterge unul sau mai multe elemente de date corespunzătoare celei utilizate de T1. T1 repetă apoi citirea inițială pe aceeași și poate obține un set diferit de articole de date decât cel original.
Notă: Înainte de a descoperi un set mai mare sau mai mic de elemente de date, T1 poate efectua operațiuni suplimentare de bază de date pe baza setului de articole de date care nu mai este considerată relevantă, creând o potențială problemă de consistență a datelor.

7.4.1.2 Izolarea este o proprietate a unei Tranzacții care indică gradul în care este izolată de acțiunile altor Tranzacții care rulează simultan cu aceasta. Tabelul de mai jos, care este ordonat de la cel mai mic (L0) la cel mai înalt (L3) nivel de restricție, descrie patru grade de izolare în funcție de care eveniment nu ar trebui să apară

7.4.1.3 În timpul executării testului, fiecare Tranzacție TPC-E va oferi un grad de izolare față de Tranzacțiile Arbitrare nu mai puțin decât gradul specificat în următorul tabel:

7.4.1.4 În timpul executării testului, SUT trebuie să permită executarea simultană a Tranzacțiilor Arbitrare.

7.4.1.5 În timpul executării testului, datele citite de fiecare Tranzacție TPC-E nu trebuie să fie mai vechi decât cele mai recente Date Verificate la momentul începerii Tranzacției.

7.4.1.6 Sistemele care implementează izolarea Tranzacțiilor folosind tehnici de blocare sau de versiuni trebuie să demonstreze conformitatea cu cerințele de izolare prin trecerea testelor descrise în Clauza 7.4.2.

7.4.1.7 Sistemele care implementează izolarea tranzacțiilor folosind tehnici altele decât blocarea sau versiunea pot necesita alte tehnici pentru a demonstra că cerințele de izolare sunt îndeplinite. Este responsabilitatea Organizatorului testului, împreună cu auditorul, să identifice aceste tehnici, să le implementeze, să le efectueze ca o demonstrație a conformității cu cerințele de izolare și să furnizeze suficiente informații în FDR pentru a susține afirmația că cerințele de izolare au fost întâlnit.

7.4.2 Teste de izolare
Următoarele teste de izolare sunt concepute pentru a verifica dacă configurația și implementarea Sistemului în curs de testare oferă Tranzacțiilor gradele de izolare necesare, așa cum este descris în clauza 7.4.1.3.

7.4.2.1 P3 Test de citire-scriere

Acest test este menit să demonstreze că o tranzacție de citire-scriere a rezultatului tranzacției, atunci când este executată concomitent cu o altă tranzacție de citire-scriere a rezultatelor tranzacției, este protejată de fenomenul fantomă P3. A doua Tranzacție cu rezultat comercial (Sesiunea S4 de mai jos) îndeplinește funcțiile unei Tranzacții aleatoare, care adaugă un rând la tabelul HOLDING_SUMMARY care a fost deja accesat de prima Tranzacție cu rezultat (Sesiunea S3 de mai jos).

În scopul acestei testări, aceste două Tranzacții cu rezultate comerciale trebuie să fie pregătite pentru a executa înregistrarea hs_qty la întoarcerea din Cadrul 1. În plus, Tranzacția cu rezultatul tranzacției executată de S3 trebuie să poată repeta execuția Cadrului 1 și să suspende executarea sa înainte ca Frame-ul să înceapă execuția 2.



1. Din S1, selectați acct_id. După executarea tranzacției specificate în modul doar citire, găsiți valoarea simbolului pentru care nu există un rând corespunzător în tabelul HOLDING_SUMMARY pentru parametrul acct_id selectat și commit.

2. De la S1, apelați și finalizați cu succes tranzacția de comandă de tranzacționare pentru act_id și parametrii simbol selectați la pasul 1. Înregistrați trade_id asociat cu aceste tranzacții.

3. Din S2, solicitați și finalizați cu succes o altă tranzacție de comandă comercială pentru parametrii act_id și simbol utilizați la pasul 2. Înregistrați trade_id asociat cu aceste tranzacții.

4. Din S3, solicitați trade_id de la Trade-Result folosit la pasul 2. Suspendați tranzacția dintre Frame 1 și Frame 2. Înregistrați hs_qty și verificați dacă este setat la zero.

5. Din S4, interogați trade_id din tranzacția de rezultat al tranzacției utilizată la pasul 3. Verificați dacă tranzacția completează Cadrul 1 și începe să execute Cadrul 2. Înregistrați hs_qty și verificați dacă este setată la zero.

Utilizați cazul A, în cazul în care S4 se oprește în Cadrul 2 și apoi se derulează înapoi în timp ce S3 se termină:
6A. Din S3, repetați execuția Cadrului 1 și faceți o pauză din nou între Cadrul 1 și Cadrul 2. Scrieți hs_qty și verificați dacă valoarea acestuia este setată la zero.
7A. Reluați execuția S3 pe Cadrul 2. Verificați dacă cadrele rămase sunt finalizate cu succes.
8A. Verificați dacă S4 a fost pompat.




6C. Dacă apare o astfel de situație, testul este considerat invalid. Pentru a testa corect protecția la citire fantomă, este necesar ca sesiunea S4 să atingă punctul din Cadrul 2 al Tranzacției de rezultat comercial atunci când un nou rând este adăugat la tabelul HOLDING_SUMMARY. Este posibil ca tranzacția de rezultat al tranzacției utilizată pentru S4 să fie modificată pentru a preveni blocarea acesteia în cadrul 1. De exemplu, poate fi rulată la un nivel mai scăzut de izolare a tranzacției arbitrare.

Nota 1: Testul P3 trece dacă apare fie cazul A sau B. Și eșuează dacă apare cazul C. Pot exista alte opțiuni valide (de exemplu, atât S3, cât și S4 pot eșua), dar dacă atât S3, cât și S4 scrieți hs_qty = 0 în timpul execuției Cadrului 1, atunci cel mult una dintre aceste Sesiuni se poate finaliza normal și poate comite Tranzacția. Scopul acestui test este de a demonstra că, în orice circumstanțe, dacă S3 recitește tabelul HOLDING_SUMMARY după ce S4 a adăugat (sau a încercat să adauge) un nou rând pentru parametrii acct_id și simbol selectați, un rând care se potrivește tot nu va fi găsit. în S3.
Nota 2: acest test izolarea creează unul sau mai multe active noi. Execuția ulterioară a testului P2 în citire-scriere (a se vedea paragraful 7.4.2.2) pentru aceiași parametri selectați act_id și simbol poate duce la închiderea poziției create în timpul acestui test.

7.4.2.2 Test P2 în citire-scriere

Acest test arată că o tranzacție de citire-scriere a rezultatelor tranzacției, în timp ce execuția simultană a unei alte tranzacții de citire-scriere a rezultatelor tranzacției, este protejată de fenomenul de citire nerepetabilă P2. A doua Tranzacție cu rezultat comercial (Sesiunea S4 de mai jos) acționează ca o Tranzacție aleatorie care actualizează rândul din tabelul HOLDING_SUMMARY care a fost citit de prima Tranzacție cu rezultat (Sesiunea S3 de mai jos).

În scopul acestei testări, aceste două Tranzacții cu rezultate comerciale trebuie să fie pregătite pentru a executa înregistrarea hs_qty la întoarcerea din Cadrul 1. În plus, Tranzacția cu rezultatul tranzacției executată de S3 trebuie să poată repeta execuția Cadrului 1 și să suspende executarea sa înainte ca Frame-ul să înceapă execuția 2.

Folosind cele patru sesiuni de la S1 la S4, următorii pași sunt efectuati în ordinea corespunzătoare.
1. Din S1, selectați acct_id. Cu tranzacția specificată în modul numai citire, găsiți valoarea simbolului pentru care există un rând corespunzător în tabelul HOLDING_SUMMARY pentru acct_id selectat, înregistrați HS_QTY pentru acel activ și comite.

2. Din S1, solicitați și finalizați cu succes o tranzacție de comandă comercială cu parametrii acct_id și simbol selectați la pasul 1. Înregistrați parametrul trade_id asociat acestor tranzacții.

3. Din S2, solicitați și finalizați cu succes o altă tranzacție de comandă comercială cu parametrii acct_id și simbol utilizați la pasul 2. Înregistrați parametrul trade_id asociat cu aceste tranzacții.

4. Din S3, solicitați o Tranzacție Trade-Result cu parametrul trade_id obținut în pasul 2 și suspendați execuția între Frame 1 și Frame 2. Înregistrați hs_qty și verificați dacă este egal cu HS_QTY obținut la pasul 1.

5. Din S4, solicitați o Tranzacție Trade-Result cu parametrul trade_id obținut la pasul 3. Verificați că acesta completează Cadrul 1 și începe execuția Cadrului 2. Scrieți hs_qty și verificați dacă este egal cu HS_QTY obținut la pasul 1.

Utilizați cazul A, dacă S4 se blochează în Cadrul 2, apoi se derulează înapoi în timp ce S3 se finalizează:
6A. Din S3, reapelați Cadrul 1 și întrerupeți din nou între Cadrele 1 și 2. Înregistrați hs_qty și verificați dacă este egal cu HS_QTY obținut la pasul 1.
7A. Reluați execuția S3 apelând Cadrul 2. Verificați executarea cu succes a Cadrelor rămase.
8A. Verificați dacă S4 a fost pompat.
Utilizați cazul B, în cazul în care S4 se termină (eventual după oprire) și S3 este anulat:
6B. Verificați dacă S4 finalizează execuția Cadrului 2 și a Cadrelor rămase.
7B. Verificați dacă S3 a fost descărcat.
Cazul C dacă S4 se oprește în cadrul 1 (incorect):
6C. Dacă apare o astfel de situație, testul este considerat invalid. Pentru a testa corect securitatea împotriva evenimentului P2 Non-Repeatable Read, este necesar ca sesiunea S4 să ajungă la momentul din Frame 2 al Tranzacției Trade-Result când unul dintre rânduri este actualizat în tabelul HOLDING_SUMMARY. Este posibil ca tranzacția de rezultat al tranzacției utilizată pentru S4 să fie modificată pentru a preveni blocarea acesteia în cadrul 1. De exemplu, poate fi rulată la un nivel mai scăzut de izolare a tranzacției arbitrare.

Notă: Acest test trece dacă apare cazul A sau B. Și eșuează dacă apare cazul C. Pot exista alte opțiuni valide (de exemplu, atât S3, cât și S4 pot eșua), dar dacă S3 și S4 scrieți aceeași valoare hs_qty în timpul execuția Cadrului 1, atunci cel mult una dintre aceste Sesiuni se poate finaliza normal și poate comite Tranzacția. Scopul acestui test este de a demonstra că, în orice condiții, atunci când S3 repetă citirea tabelului HOLDING_SUMMARY având în vedere acct_id și simbolul, rândul și valoarea găsite vor fi aceleași ca la pasul 1.


7.4.2.3 Test P1 în citire-scriere

Acest test arată că o tranzacție de citire-scriere a rezultatelor tranzacției, în timp ce o altă tranzacție de citire-scriere a rezultatelor tranzacției se execută concomitent, este protejată de un eveniment de citire murdară P1. Pentru a a acestei testari Tranzacția Trade-Result trebuie configurată pentru a executa înregistrarea se_amount la întoarcerea din Frame 5 și trebuie să poată suspenda execuția în Frame 6 imediat înainte de comitere.

Folosind cele trei sesiuni de la S1 la S3 în ordinea corespunzătoare, se parcurg următorii pași

1. Din S1, apelați Tranzacția Client-Posiție pe parametrul cust_id selectat, finalizați Tranzacția și notați setul de parametri finali acct_id și cash_ball.

2. Din S1, apelați și finalizați cu succes Tranzacția de comandă comercială cu parametrul acct_id selectat din setul înregistrat la pasul 1 al parametrul dat simbol și cu type_is_margin setat la 0. Notați trade_id-ul atribuit acestor tranzacții.

3. Din S1, apelați și finalizați cu succes o altă tranzacție de comandă comercială cu același parametru acct_id, dar un parametru simbol diferit de cel utilizat la pasul 2 și un parametru type_is_margin setat la 0. Înregistrați ID-ul comercial atribuit acestor tranzacții.

4. Din S2, apelați Transaction Trade-Result cu parametrul de intrare trade_id obținut la pasul 2. Înainte de a apela Frame-ul 6, scrieți se_amount, apoi apelați Frame-ul 6 și faceți o pauză înainte de a efectua comiterea.

5. Din S3, apelați Transaction Trade-Result cu parametrul de intrare trade_id primit la pasul 3. Tranzacția poate fi suspendată, s-ar putea să nu se finalizeze cu succes sau poate fi blocată temporar de a fi executată complet. Dacă ajunge la începutul Cadrului 6, scrieți se_amount, apoi apelați Cadrul 6. Dacă ajunge la sfârșitul Cadrului 6, faceți o pauză înainte de a confirma.

6. Din S2, continuați cu confirmarea și finalizarea cu succes a Tranzacției. Înregistrați valoarea rezultată a parametrului acct_bal.

7. Din S3, în funcție de comportamentul tranzacției la sfârșitul pasului 5:
Dacă a ajuns la o suspendare în Cadrul 6, lăsați-o să continue și verificați dacă a fost confirmată și finalizată cu succes.

Dacă a fost blocat înainte de a termina Cadrul 5, verificați dacă a fost deblocat, a completat Cadrul 5, a scris se_amount, numit Frame 6, a fost Confirmat și finalizat cu succes.

Dacă nu s-a finalizat cu succes și a fost derulat înapoi, reapelați tranzacția Trade-Result cu același parametru de intrare trade_id. Verificați dacă Tranzacția cu rezultatul comerțului se execută complet, scrie valoarea se_amount la începutul cadrului 6, se angajează la sfârșitul cadrului 6 și se finalizează cu succes.

8. Din S3, înregistrați cont_bal rezultat și verificați dacă este egal cu valoarea cash_bal de la pasul 1 (folosind acct_id selectat la pasul 2) plus suma sumei se_amount de ieșire pentru aceste două Tranzacții cu rezultate comerciale.

7.4.2.4 Test P1 în citire-scriere

Acest test arată că Tranzacția Citire-Scrie Poziția Clientului în timpul execuției concomitente a Tranzacției Citire-Scriere Rezultatul tranzacției este protejată de evenimentul de citire murdară P1. În scopul acestei testări, Tranzacția cu rezultatul tranzacției trebuie să poată suspenda execuția în Cadrul 6 imediat înainte de confirmare.

Folosind cele patru sesiuni de la S1 la S4, următorii pași sunt efectuati în ordinea corespunzătoare:

1. Din S1, apelați Tranzacția Client-Posiție pe parametrul cust_id selectat, finalizați Tranzacția și notați setul de parametri finali acct_id și cash_ball.

2. De la S1, apelați și finalizați cu succes o tranzacție de comandă de tranzacționare în care parametrul de intrare corespunzător acct_id se potrivește cu unul dintre parametrii acct_id înregistrați la pasul 1 și valoarea tip_is_margin este 0. Înregistrați ID-ul comercial atribuit acestor tranzacții.

3. Din S2, apelați Transaction Trade-Result cu parametrul de intrare trade_id primit la pasul 2 și apoi întrerupeți execuția în Cadrul 6 înainte de comitere.

4. Din S3, apelați Tranzacția Client-Posiție cu parametrul de intrare cust_id selectat la pasul 1. Tranzacția poate reuși sau eșua sau poate fi blocată temporar de la executarea completă.

5. Din S2, continuați cu continuarea și finalizarea cu succes a Tranzacției cu rezultatul comerțului. Înregistrați rezultatul acct_bal.

6. Din S3 în funcție de comportamentul Tranzacției Client-Poziție la sfârșitul pasului 4:

Dacă se finalizează, înregistrați setul de acct_id și cash_bal rezultate și verificați dacă valorile cash_bal pentru acct_id utilizate la pasul 2 rămân neschimbate de la primul pas.

Dacă a fost blocat, verificați dacă acum s-a finalizat, înregistrați setul rezultat de acct_id și cash_bal și verificați dacă valoarea cash_bal pentru acct_id-ul dat folosit la pasul 2 se potrivește cu acct_bal de la pasul 5.

Dacă nu a fost finalizat, treceți la pasul următor.

7. Din S4, apelați Tranzacția Client-Posiție cu parametrul cust_id selectat la pasul 1, finalizați Tranzacția, înregistrați setul de parametri rezultați acct_id și cash_bal și verificați dacă cash_bal pentru act_id dat utilizat în pasul 2 s-a modificat de la pasul 1 și reflectă volumul tranzacțiilor executate în etapa 5 (în comparație cu acct_bal din etapa 5).


7.5 Cerințe de stabilitate

Sistemul testat trebuie să fie configurat pentru a îndeplini cerințele de robustețe specificate în această clauză. Sistemul testat demonstrează proprietăți de stabilitate în cazul salvării Tranzacțiilor confirmate și al menținerii structurii bazei de date după defecțiunile enumerate în clauza 7.5.2. Testarea rezistenței este efectuată prin apelarea defecțiunilor catastrofale și non-catastrofale pe componentele SUT. Eșecurile necatastrofale, descrise în clauza 7.5.5, testează capacitatea SUT de a menține capacitatea de a accesa date. Eșecurile catastrofale descrise în clauza 7.5.6 testează capacitatea SUT de a păstra efectele Tranzacțiilor Confirmate. Durata efectelor unei Eșecuri catastrofale este descrisă în Raportul de testare ca Timp de recuperare a afacerii. Nici unul dintre ei sistemele existente nu oferă stabilitate absolută (adică stabilitate în orice scenarii de defecțiune). Setul specific de defecțiuni individuale enumerate în Clauza 7.5.2 este considerat suficient de indicativ pentru a afirma prezența Rezilienței în cazurile de astfel de defecțiuni. Cu toate acestea, natura limitată a testelor prezentate nu ar trebui interpretată ca permițând existența altor cazuri irecuperabile de defecțiuni unice.

7.5.1 Definiția conceptelor

Disponibilitate: Abilitatea de a efectua operațiuni de bază de date cu acces complet la date după un accident permanent irecuperabil al oricăruia Transportator permanent care conțin tabele de baze de date, date din jurnalul de recuperare sau Metadatele bazei de date. A se vedea clauza 7.5.2.1.

7.5.1.1 Restaurarea aplicației Catastrofal

7.5.1.2 Timp de recuperare aplicații: Timpul scurs de la începutul Recuperării aplicației până la sfârșit (a se vedea punctul 0).

7.5.1.3 Redresarea afacerii: Procesul de restaurare a unei aplicații de afaceri după Catastrofal defectarea sistemului și atingerea unui punct în care afacerea atinge anumite criterii operaționale.

7.5.1.4 Timp de recuperare a afacerii: Timpul scurs de la începutul Recuperării aplicației până la sfârșit (a se vedea Clauza 7.5.6.8).

7.5.1.5 Catastrofal: Un tip de eroare în care procesarea este întreruptă fără avertisment dat de SUT. După această eroare, numai pentru baza de date prăbușită, toată memoria este ștearsă și tot contextul activ al aplicației este pierdut.

7.5.1.6 Confirmat: O tranzacție este confirmată atunci când acțiunile sale (Adăugați, Eliminați, Modificați) sunt permanente și vizibile pentru alte Tranzacții

7.5.1.7 Notă: Tranzacțiile pot fi efectuate fără ca șoferul să fie notificat ulterior despre acest fapt, deoarece integritatea mesajului nu este necesară.

7.5.1.8.Recuperarea bazei de date: Procesul de recuperare a unei baze de date după o defecțiune catastrofală a sistemului.

7.5.1.9 Timp de recuperare a bazei de date: Durata de la început Recuperarea bazei de date până când fișierele bazei de date sunt complet restaurate.

Cerințe de evaluare a durabilității: condiții pe care SUT trebuie să le îndeplinească în timpul tuturor testelor de stabilitate (a se vedea clauza 7.5.3)

7.5.1.10 Robust: O stare care poate rezista la eșecuri (așa cum este descris în Clauza 7.5.2) și care are semantică de actualizare tranzacțională.

7.5.1.11 Transportator permanent: stocare de date nevolatilă, persistentă, cum ar fi disc magnetic sau bandă.

7.5.1.12 Concept Necatastrofale se referă la o singură defecțiune care nu întrerupe procesarea, dar poate degrada performanța și poate face ca SUT să nu mai fie într-o stare de echilibru până când își revine din defecțiune.

7.5.2 Puncte unice de eșec
Următoarele puncte descriu componente individuale SUT-uri testate prin defecțiuni non-catastrofale și catastrofale descrise în clauzele 7.5.5 și 7.5.6. Punctele unice de defecțiune se aplică componentelor SUT necesare pentru a îndeplini cerințele de Reziliență.

Organizatorul testului poate aplica un singur test pentru a efectua testarea de reziliență pe mai multe puncte unice de defecțiune (de exemplu, un singur „test de defecțiune totală a sistemului” poate fi aplicat celor trei puncte de defecțiune descrise în clauzele 7.5.2.2, 7.5.2.3 și 7.5. .2.4).

7.5.2.1 Eroare permanentă irecuperabilă a unuia dintre mediile persistente.

7.5.2.2 Pauza instantanee(defecțiune de sistem/blocarea sistemului) în procesul de procesare, care necesită o repornire a sistemului pentru a se recupera.
Notă: asta înseamnă și rezilierea incorectă lucru care necesită descărcarea unei noi copii Sistem de operare Cu Dispozitiv de pornire. Nu înseamnă neapărat pierderea datelor din memoria nevolatilă. Un exemplu de mecanism pentru a depăși un eveniment de anulare instantanee în procesare este jurnalul de anulare/refacere.

7.5.2.3 Eșecul întregului spațiu de memorie(pierderea conținutului).
Notă: Aceasta presupune că întregul spațiu de memorie a eșuat. Acest lucru poate fi cauzat de o pierdere a aprovizionării alimentare externă sau defecțiune permanentă a plăcii de memorie.

7.5.2.4 Încetarea alimentării externe a SUT pentru o perioadă nedeterminată (pentru de curent). Aceasta trebuie să includă cel puțin toate părțile SUT care sunt implicate în etapele de lucru ale Tranzacției cu baze de date.

Notă: Cerințele de protecție împotriva căderii de curent pot fi îndeplinite prin utilizarea unui număr suficient de UPS pentru a asigura disponibilitatea la nivel de sistem a tuturor componentelor care se confruntă cu o întrerupere a curentului în 30 de minute. Utilizarea unei configurații protejate UPS nu ar trebui să introducă noi puncte unice de defecțiune care nu sunt protejate de alte părți ale configurației. Această afirmație poate fi dovedită fie prin măsurarea, fie prin calculul consumului electric de 30 de minute (în wați) al porțiunii protejate a SUT, înmulțit cu 1,4.

7.5.3 Cerințe pentru evaluarea stabilității.

Toate testele de stabilitate trebuie să îndeplinească următoarele cerințe:

  • în timpul unui Interval de măsurare să fie efectuat cu același număr de utilizatori configurați și încărcare de șofer
  • apar într-o stare stabilă
  • să îndeplinească restricțiile privind timpul de răspuns stabilite în clauza 6.5.1.7.
  • să îndeplinească cerințele pentru o Combinație de Tranzacții enumerate în clauza 6.3.1.
  • să fie executat la o valoare de performanță de 95% sau mai mare din Raportat fără erori
  • potriviți toate setările de configurare Driver și SUT aplicate în timpul Intervalului de Măsurare.
7.5.4 Instanțe multiple ale sistemului de operare

7.5.4.1 În configurațiile în care funcții similare de analiză comparativă sunt efectuate de mai mult de o instanță a sistemului de operare, testele de defecțiune enumerate în clauza 7.5.2 trebuie efectuate pe cel puțin una dintre acele instanțe.

7.5.4.2 Dacă mai multe instanțe ale sistemului de operare gestionează date care sunt procesate ca o singură imagine din punctul de vedere al aplicațiilor de evaluare comparativă (de exemplu, un cluster de baze de date), atunci testul de întrerupere a alimentării trebuie să fie rulat simultan pe toate aceste cazuri.

Notă: Întreruperea de alimentare a mai multor instanțe în SUT trebuie să apară în decurs de 3 secunde pentru a introduce diferențe în rezultatele procedurilor manuale care pot fi utilizate pentru a finaliza testul.

7.5.4.3 Dacă mai mult de o instanță a sistemului de operare gestionează date care sunt procesate într-o aplicație de referință ca o singură imagine și conectate prin medii fiziceîn afară de o magistrală încorporată (de exemplu, un cablu de expansiune de magistrală, o rețea LAN de mare viteză sau altă metodă de furnizare a comunicației între mai multe instanțe ale sistemului de operare care pot fi supuse întreruperii fizice), este inclusă întreruperea instantanee a unei astfel de comunicări. în lista obiectelor care trebuie testate conform clauzei 7.5 2.2. Doar una dintre instanțe de conexiune care utilizează redundanță trebuie verificată pentru eșec.

Notă: acest paragraf nu este destinat să stabilească o cerință de a întrerupe conexiunea cu stocarea pe disc sau subsisteme de discuri cu redundanţă.

7.5.5 Eșecuri non-catastrofale

O defecțiune non-catastrofală este orice defecțiune care nu pierde datele stocate în memoria SUT sau nu necesită descărcare nouă Sistem de operare de pe dispozitivul de pornire. Eșecurile non-catastrofale descrise în acest paragraf au un impact asupra accesului la datele stocate pe Media Persistent. Aceste cerințe sunt denumite și cerințe de disponibilitate a datelor.

7.5.5.1 SUT va menține accesul la datele de pe suportul persistent în timpul și după o defecțiune identificată în clauza 7.5.2.1 (eșecul permanent nerecuperabil al oricărui mediu persistent care conține tabele baze de date, date jurnal de recuperare sau metadatele bazei de date). Organizatorul testului trebuie, de asemenea, să restabilească mediul Persistent Media la starea anterioară eșecului, menținând în același timp capacitatea de a accesa datele de pe Persistent Media.

7.5.5.2 Mediile persistente pot fi medii volatile sau nevolatile configurate corespunzător pentru a îndeplini cerințele clauzei 7.5.2.1. Mediile nevolatile sunt de obicei discuri magnetice, utilizând replicarea (oglindire RAID-1) sau alte metode de protecție (RAID-5, etc.) care garantează accesul la date în timpul unei eșecuri Persistent Media. Suporturile volatile, cum ar fi memoria, pot fi utilizate acolo unde mediile volatile pot oferi transfer automat de date înainte ca orice date să fie pierdute pe medii nevolatile după o întrerupere a alimentării, indiferent de momentul în care este restabilită alimentarea.

Nota 1: Sursa configurată și evaluată Putere neîntreruptibilă(UPS) nu contează sursă externă nutriție.

Nota 2: Memoria poate fi considerată stocare permanentă dacă poate păstra datele suficient de mult pentru a îndeplini cerințele descrise mai sus, de exemplu dacă este suplimentată cu o sursă de alimentare neîntreruptibilă și conținutul memoriei poate fi redirecționat către stocare nevolatilă la momentul eșecului. Trebuie menționat că nu se face distincție între memoria principală și memoria care îndeplinește funcții similare de stocare permanentă sau temporară a datelor în alte părți ale sistemului (de exemplu, cache-ul controlerului de disc). Dacă memoria principală este folosită ca mediu persistent, aceasta trebuie considerată ca un potențial punct unic de defecțiune. Un exemplu de soluție pentru o singură eșec media persistentă este oglindirea media persistentă.

Dacă memoria este un mediu permanent, iar oglindirea este folosită pentru a asigura stabilitatea, atunci băncile de memorie în oglindă trebuie să aibă surse de alimentare independente.

7.5.5.3 Testele de disponibilitate a datelor (numite și Teste de eșec non-catastrofal) trebuie să respecte Cerințele de evaluare a rezistenței din clauza 7.5.3.

7.5.5.4 Niveluri de redundanță
Nivelul de redundanță denotă gradul în care disponibilitatea datelor este garantată în cazul unei singure defecțiuni a componentelor de stocare a datelor. SUT trebuie să folosească unul dintre nivelurile următoare Redundanțe:

  • Redundanță de nivel 1 (redundanță media persistentă): garantează accesul la datele de pe mediile persistente în cazul unei defecțiuni pe unul dintre mediile persistente.
Notă: sarcină acest nivel redundanța este de a testa mediul media persistent pentru a rezista la eșecul unuia dintre mediile persistente și de a continua procesarea cererilor din sistemul de operare și/sau DBMS.

Exemplu: Organizatorul de testare a implementat utilizarea RAID-1 (oglindire) pe discurile din stocare. În cazul unei defecțiuni pe unul dintre discuri, Organizatorul trebuie să ofere acces la datele de pe toate discurile rămase.

  • Redundanță de nivel 2 (redundanța controlerului media persistentă): Activează redundanța de nivel 1 și garantează accesul la datele de pe suportul media persistent atunci când apare o singură defecțiune în controlerul de stocare utilizat pentru atingerea nivelului de redundanță sau în comunicațiile dintre controlerul de stocare și dispozitivul persistent. Mass-media.
Notă: Scopul acestui nivel de redundanță este de a testa capacitatea schema implementata supraviețui eșecului controlerului de stocare care implementează redundanța de nivel 1.

Exemplu: Dacă redundanța de nivel 1 este atinsă prin implementarea protecției RAID-5 pe disc, atunci redundanța de nivel 2 va fi testată prin defectarea hardware-ului utilizat pentru implementarea protecției RAID-5.

Dacă controlerul care implementează RAID-5 este conținut într-o structură de disc (sau un dispozitiv similar atașat extern), atunci Organizatorul trebuie să demonstreze că este în continuare capabil să acceseze datele stocate în structură.

Dacă controlerul care implementează RAID-5 este situat separat de carcasa care conține discurile și controlerul nu este utilizat ca mediu persistent (de exemplu, un cache de scriere în oglindă), atunci este suficient să rupeți conexiunile dintre controler și structura discului.

  • Redundanță de nivel 3 (redundanță completă): Activează redundanța de nivel 2 și garantează accesul la datele de pe media persistentă atunci când apare o singură defecțiune în sistemul media persistentă, inclusiv legăturile dintre stratul B și sistemul media persistentă.
Nota 1: Sistemul Persistent Media conține toate componentele necesare pentru a îndeplini cerințele de durabilitate descrise mai sus. Acesta nu include un sistem de nivel B sau o magistrală de sistem, dar include un adaptor pentru magistrala de sistemși toate componentele situate „sub” adaptor.

Nota 2: Scopul acestei clauze este de a testa capacitatea sistemului de Nivel B de a rezista defecțiunilor componentelor sale și de a continua să proceseze Tranzacțiile.

Notă: Componentele testate în acest paragraf sunt considerate module care se pot înlocui rapid. Intenția acestei clauze nu este de a solicita Organizatorului să testeze stabilitatea backplane-ului în stocarea Media Persistente sau a componentelor similare care nu pot fi înlocuite. În același timp, sarcinile de testare includ verificarea proprietăților de toleranță la erori ale controlerelor de stocare, inclusiv cache-ul oglindit pe controler și software-ul corespunzător.

7.5.5.5 Procedura de testare a robusteței pentru disponibilitatea datelor

1. Determinați numărul curent de tranzacții finalizate în baza de date, rulând interogarea:
selectați count(*) ca count1 din SETTLEMENT

2. Începeți să trimiteți Tranzacții pentru procesare și să creșteți performanța la nivelul cerințelor de evaluare a rezistenței (așa cum este descris în clauza 7.5.3) și mențineți la acest nivel timp de cel puțin 5 minute.

Notă: Odată ce cerințele de evaluare a stabilității sunt îndeplinite:

  • Orice modificare a configurației driverului este interzisă până la finalizarea etapei 5
  • Orice modificare a configurației SUT este interzisă, cu excepția celor necesare pentru a parcurge pașii 3 și 4.
3. Nu verificați, după cum este necesar, nivelul de redundanță demonstrat.

4. Începeți procedurile necesare recuperare.

5. Continuați să lucrați cu driverul timp de 20 de minute.

6. Încheiați corect execuția de la Driver.

7. Obțineți noul număr de tranzacții finalizate în baza de date rulând:



8. Comparați numărul de tranzacții cu rezultatul tranzacției finalizate de șofer cu valoarea
(număr 2 - număr 1). Verificați dacă (count2 - count1) este egal cu numărul de intrări ale tranzacțiilor cu rezultate comerciale reușite în fișierul jurnal al driverului.

9. Permiteți ca procedura de recuperare să se termine conform așteptărilor.

7.5.6 Eșecuri catastrofale.

Unele defecțiuni pot fi de natură catastrofală și, în astfel de cazuri, accesul la date se pierde. SUT-ul trebuie să fie capabil să salveze starea bazei de date și să restabilească accesul la date în cel mai scurt timp posibil.
Eșecuri catastrofale sunt de natură bruscă și imprevizibilă, ducând adesea la pierderi neașteptate în procesarea tranzacțiilor. Cerințele din această clauză testează capacitatea SUT de a păstra consecințele Tranzacțiilor Confirmate. Deoarece capacitatea de procesare a tranzacțiilor este esențială într-un mediu OLTP, organizatorul de testare trebuie să măsoare și să raporteze timpul necesar DBMS-ului pentru a se recupera de la eșecurile catastrofale. Acest timp de recuperare se numește Business Recovery Time.
Notă: Eșecurile catastrofale reprezintă o întrerupere uriașă a proceselor de afaceri, prin urmare este imperativ ca întreprinderile să-și revină după astfel de eșecuri cât mai repede posibil. Există mulți parametri și practici de configurare a bazei de date care afectează direct performanța DBMS și timpul de recuperare a acestuia după o defecțiune catastrofală. Deși este cunoscut faptul că timpii de încărcare sunt sisteme diferite poate varia într-un interval foarte mare, parametrii de încărcare au un efect extrem de mic asupra performanței DBMS și nu fac parte din timpul de recuperare a afacerii.


7.5.6.1 Testele de eșec catastrofal trebuie să respecte Cerințele de evaluare a rezistenței prevăzute în Clauza 7.5.3.

7.5.6.2 Implementați imaginea de recuperare de la copie de arhivă baza de date (de exemplu, o copie făcută înainte de execuție), utilizarea datelor jurnalului Rollback/Undo nu este acceptabilă ca mecanism de recuperare pentru defecțiunile enumerate în clauzele 7.5.2.2, 7.5.2.3 și 7.5.2.4. Trebuie remarcat faptul că puncte de control, Punctele de validare, Punctele de secvență (și similare) bazele de date create în timpul rulării unui job nu sunt considerate date arhivate.

7.5.6.3 Dacă mecanismul de recuperare se bazează pe conținutul memoriei volatile înainte de defecțiune, atunci mijloacele utilizate pentru a evita pierderea conținutului memoriei volatile (de exemplu, o sursă de alimentare neîntreruptibilă) vor fi luate în considerare la calcularea costului sistemul (a se vedea clauza 8.3.1.3).

7.5.6.4 Începutul recuperării bazei de date este momentul în care fișierele bazei de date sunt accesate pentru prima dată de un proces care cunoaște conținutul acelor fișiere și intenționează să recupereze baza de date sau să execute Tranzacții care operează pe baza de date.

Notă: acces la fișiere de către procesele sistemului de operare pentru a verifica integritatea Sistemul de fișiere sau volume pentru a corecta erorile din structurile de date nu înseamnă începerea recuperării bazei de date.

7.5.6.5 Finalizarea recuperării bazei de date este punctul în care fișierele bazei de date au fost restaurate.

Notă: De obicei, baza de date va indica această oră în fișierele sale jurnal.

7.5.6.6 Începutul recuperării aplicației este momentul în care prima Tranzacție este trimisă după începerea recuperării bazei de date.

7.5.6.7 Sfârșitul recuperării aplicației este punctul în care SUT începe să funcționeze la o performanță mai mare sau egală cu 95% din Raportat și continuă să facă acest lucru timp de cel puțin 20 de minute.

7.5.6.8 Procedura de testare pentru defecțiuni catastrofale

1. Determinați numărul curent de tranzacții finalizate în baza de date rulând:
selectați count(*) ca count1 din SETTLEMENT.

2. Începeți execuția Tranzacțiilor și creșteți performanța la nivelul cerințelor de evaluare a rezistenței (așa cum este descris în clauza 7.5.3) și respectați aceste cerințe timp de cel puțin 20 de minute.

3. Efectuați una sau mai multe Eșecuri catastrofale de la paragrafele 7.5.2.2, 7.5.2.3 sau 7.5.2.4.

4. Dacă se potrivește configurație de testare, nu mai trimiteți Tranzacții.

5. Dacă este necesar, reporniți SUT (care poate implica o repornire completă).

6. Marcați ora de începere a recuperării bazei de date (vezi paragraful 7.5.6.4), fie automat, fie manual de către operator.

7. Când procedura de recuperare a bazei de date se încheie, notați ora. Acest lucru se poate întâmpla în timpul pasii urmatori(a se vedea paragraful 7.5.6.5).

8. Începeți Executarea Testului 2 sau continuați să trimiteți Tranzacții și marcați acest moment drept începutul Recuperării aplicației (vezi Clauza 7.5.6.6). Creșteți productivitatea la 95% din productivitatea raportată.

Notă: Dacă există un interval de timp între sfârșitul restabilirii bazei de date și începerea restabilirii aplicației și dacă driverele și tranzacțiile trebuie repornite (în loc să continue), atunci o tranzacție de curățare a comerțului poate fi începută în timpul această perioadă de timp.

9. Marcați sfârșitul Recuperării aplicației, așa cum este descris în paragraful 7.5.6.7.

10. Opriți corect driverul.

11. Verificați dacă driverul nu a raportat nicio eroare la pașii de la 7 la 10. Acest lucru este pentru a vă asigura că Utilizator final nu va asista la niciuna efecte negative(pe lângă disponibilitatea aplicației și performanța potențial redusă) din cauza eșecului SUT și a recuperării ulterioare a afacerii.

12. Obțineți noul număr de tranzacții finalizate în baza de date rulând:
selectați count(*) ca count2 din SETTLEMENT

13. Comparați numărul de tranzacții Trade-Result finalizate de Driver cu valoarea (count2 - count1). Verificați că (count2 - count1) este mai mare sau egal cu numărul total de intrări de tranzacție cu rezultat tranzacționat reușit din fișierul jurnal al driverului legat de rulările efectuate în etapa 2 și etapa 7.
Dacă există o inegalitate, atunci tabelul SETTLEMENT trebuie să conțină intrări suplimentare iar diferența trebuie să fie mai mică sau egală cu număr maxim Tranzacții care pot fi simultan în proces de transfer de la șofer la SUT. Acest număr este legat de implementarea driverului și setările de configurare la momentul defecțiunii.

Notă: Această diferență ar trebui să existe numai din cauza Tranzacțiilor efectuate pe sistemul în curs de testare pentru care, în ciuda acestui fapt, nicio ieșire nu a fost returnată driverului înainte de eșec.

14. Verificați condițiile secvenței așa cum sunt specificate în Clauza 7.3.3.

15. Calculați timpul de recuperare a afacerii ca sumă a timpului de recuperare a aplicației și a timpului de recuperare a bazei de date, cu excepția cazului în care aceste perioade de timp se suprapun. Dacă Recuperarea aplicației începe înainte de sfârșitul Recuperării bazei de date, atunci Timpul de recuperare a afacerii este timpul scurs între începerea Recuperării bazei de date și sfârșitul Recuperării aplicației.

7.5.7 Raportarea de durabilitate obligatorie.

7.5.7.1 Organizatorul testului trebuie să descrie nivelul de redundanță și să descrie testul(ele) folosit(e) pentru a demonstra conformitatea în raport.

7.5.7.2 Diagrama de disponibilitate a datelor
Raportul trebuie să prezinte un grafic al Performanței Măsurate în raport cu timpul scurs pentru fragmente de execuție a Testului de Disponibilitate a Datelor, pregătit în conformitate cu următoarele convenții:

  • Axa X reprezintă timpul scurs pentru testele descrise în Clauza 7.5.5.5, pentru etapele 2 până la 6
  • Axa Y reprezintă performanța exprimată în tpsE
Notă: Scopul este de a demonstra impactul procedurii de recuperare asupra performanței.

7.5.7.3 Evaluări raportate
Momentul pentru redresarea afacerii ar trebui să fie indicat în Ordinul executoriu final și în Raport. Dacă defecțiunile descrise în clauzele 7.5.2.2, 7.5.2.3 și 7.5.2.4 nu au fost combinate într-un singur test de rezistență (de obicei prin întreruperea alimentării la serverul bazei de date în timpul execuției), atunci timpul de recuperare a afacerii pentru eșecul descris pentru întrerupere bruscă este - acesta este timpul de recuperare a afacerii care ar trebui inclus în ordinul final de executare. Toate valorile timpului de recuperare a afacerii pentru fiecare test care necesită recuperarea afacerii trebuie raportate în raport.

7.5.7.4Cronologia redresării afacerii
Raportul va include un grafic al performanței măsurate în raport cu timpul scurs pentru segmentele de execuție a testului de redresare a afacerii, pregătit în conformitate cu următoarele aranjamente:
  • Axa X afișează timpul maxim scurs pentru cele două runde de testare descrise la punctul 7.5.6.8 pentru etapele 2 și 8
  • Axa Y reprezintă performanța exprimată în tpsE
  • Trebuie utilizată o dimensiune a scării grafice de 1 minut.
  • Datele pe axa Y ar trebui să fie reprezentate grafic pentru ambele rulări pe același grafic, cu punctele finale ale fiecărei rulări indicate clar.
  • În scopul creării unui grafic, punctul de referință zero este definit după cum urmează:
  • Pentru rularea descrisă la pasul 2 din clauza 7.5.6.8, punctul de referință zero este definit ca momentul în timp în care prima Tranzacție este aplicată bazei de date.
  • Pentru rularea descrisă la pasul 8 din clauza 7.5.6.8, punctul de referință zero este definit ca momentul în care începe recuperarea bazei de date.
  • În scopul creării unui program, sfârșitul unei rulări este determinat după cum urmează:
  • Pentru rularea descrisă la pasul 2 din clauza 7.5.6.8, sfârșitul rulării este momentul în care are loc defecțiunea (a se vedea pasul 3 din clauza 7.5.6.8)
  • Pentru rularea descrisă la pasul 8 din clauza 7.5.6.8, sfârșitul rulării este momentul la care Recuperarea aplicației s-a finalizat cu succes (consultați pasul 8 din clauza 7.5.6.8)
  • Pentru rularea descrisă la pasul 8 din clauza 7.5.6.8, dacă există vreo perioadă de timp între sfârșitul recuperării bazei de date și începerea recuperării aplicației, această perioadă trebuie ignorată și cele două perioade ar trebui să fie reprezentate grafic lângă fiecare. alte.










Nu este un secret că, în prezența unei reguli euristice formulate numită Teorema CAP, spre deosebire de sistemul obișnuit RDBMS, clasa de soluții NoSQL nu poate oferi sprijin deplin ACID. Trebuie spus că pentru o serie de sarcini nu este nevoie de acest lucru și susținerea unuia dintre elemente duce la un compromis în rezolvarea celorlalte, ca urmare - o mare varietate de soluții existente. În acest articol, aș dori să iau în considerare diverse abordări arhitecturale pentru rezolvarea problemelor de îndeplinire parțială a cerințelor pentru un sistem tranzacțional.

Atomicitatea „A”.

Atomicitatea asigură că nicio tranzacție nu este parțial angajată în sistem. Fie vor fi efectuate toate suboperațiunile sale, fie niciuna nu va fi efectuată.

Sistemele NoSQL sunt de obicei alese performanta ridicata nu de dragul semanticii tranzacționale, deoarece respectarea acesteia introduce costuri suplimentare de procesare. Multe sisteme încă oferă garanții la nivel de cheie sau rând (Google BigTable) sau oferă un API de operații atomice (Amazon DynamoDB) în care doar un fir poate modifica o înregistrare dacă, de exemplu, doriți să aveți un contor de accesări al utilizatorului distribuit în întreaga cluster . Majoritatea sistemelor aderă la bucle de citire-modificare-scriere neblocante. Ciclul este format din trei etape- citiți valoarea, modificați, scrieți. După cum puteți vedea, într-un mediu multi-threaded există multe lucruri care pot merge prost, de exemplu, ce se întâmplă dacă cineva schimbă o înregistrare între fazele de citire și scriere. Principalul mecanism de rezolvare a unor astfel de conflicte este utilizarea algoritmului Compare and Swap - dacă cineva a schimbat o înregistrare în timpul ciclului - trebuie să înțelegem că înregistrarea s-a schimbat și să repetăm ​​ciclul până la stabilirea valorii noastre, acest algoritm pare de preferat complet mecanism de blocare a scrierii. Numărul de astfel de cicluri poate fi foarte mare, așa că avem nevoie de un anumit timeout pentru operație, după care operația va fi respinsă.

Consecvența „C”.

O tranzacție care ajunge la finalizarea normală și, prin urmare, își angajează rezultatele, menține consistența bazei de date. Având în vedere specificul NoSQL la distribuirea informațiilor pe servere, aceasta înseamnă dacă toate replicile care conțin o copie a datelor conțin întotdeauna aceeași versiune a datelor.

Datorită specificului său, NoSQL modern trebuie să aleagă disponibilitate ridicată și capacitatea de a scalare orizontală cluster - se dovedește că sistemul nu poate asigura coerența completă a datelor și face unele ipoteze în definirea conceptului de consistență. Există două abordări:

Consecvență strictă
Astfel de sisteme asigură că replicile sunt întotdeauna capabile să convină asupra unei singure versiuni a datelor returnate utilizatorului. Unele replici nu vor conține această valoare, dar atunci când sistemul procesează o solicitare pentru o valoare prin cheie, mașina va putea întotdeauna să decidă ce valoare să returneze - pur și simplu nu va fi întotdeauna ultima. Cum funcționează - de exemplu, avem N replici ale aceleiași chei. Când vine o solicitare de actualizare a unei valori cheie, sistemul nu va returna rezultatul utilizatorului până când W replicile nu vor răspunde că au primit actualizarea. Când utilizatorul solicită o valoare, sistemul returnează un răspuns utilizatorului când cel puțin R replicile au returnat aceeași valoare. Apoi considerăm că sistemul este strict consecvent dacă condiția este îndeplinită R+W>N. Selectarea valorilor RȘi W afectează câte mașini trebuie să răspundă înainte ca răspunsul să fie returnat utilizatorului, alegând de obicei o condiție R+W=N+1- minim conditie necesara pentru a asigura o consistență strictă.
Posibila consistenta
Unele sisteme ( Voldemort, Cassandra, Riak) vă permit să selectați RȘi W la care R+V . Când un utilizator solicită informații, pot exista momente în care sistemul nu poate rezolva un conflict între versiunile unei valori cheie. Pentru a rezolva conflictele, se folosește un tip de versiuni numit vector clock. Acesta este un vector asociat cu fiecare cheie care conține contoare de modificare pentru fiecare replică. Lasă serverul A, BȘi C- replici ale aceleiași chei, vectorul va conține trei valori (N_A, N_B, N_C), inițial inițial în (0,0,0) . De fiecare dată când o replică schimbă valoarea unei chei, aceasta își crește contorul în vector. Dacă B modifică valoarea unei chei care a avut anterior o versiune (39, 1, 5) - vectorul își va schimba valoarea în (39, 2, 5) . Când o altă replică, să zicem C, primește actualizare de la replica B compară valoarea vectorului cu propria sa. Atâta timp cât toate contoarele vectorului sunt mai mici decât cele livrate cu B, valoarea returnată este o versiune stabilă și vă puteți suprascrie propria copie. Dacă este pornit BȘi C există vectori în care unele contoare sunt mai mari și altele mai mici, de exemplu, (39, 2, 5) Și (39, 1, 6) , apoi sistemul identifică conflictul.

Rezolvarea acestui conflict variază pe diferite sisteme, Voldemort returnează mai multe copii ale valorii, lăsând rezolvarea conflictului în sarcina utilizatorului. Două versiuni ale coșului de cumpărături al unui utilizator de pe un site pot fi îmbinate fără pierderi de informații, în timp ce îmbinarea a două versiuni ale aceluiași document editabil necesită intervenția utilizatorului. Cassandra, care stochează marca temporală a fiecărei înregistrări, returnează cea mai recentă în cazul în care este detectat un conflict; această abordare nu permite îmbinarea a două versiuni fără a pierde informații, dar simplifică partea client.

Cassandra, începând cu versiunea 1.1, se asigură că dacă faceți upgrade:

UPDATE Utilizatorii
SETează login="login" ȘI parola="parolă"
WHERE key="key"

Atunci nicio citire concomitentă nu va vedea o actualizare parțială a datelor (autentificarea s-a schimbat, dar parola nu), iar acest lucru este valabil doar la nivelul rândurilor care se află în același familie de coloaneși având o cheie comună. Acest lucru poate corespunde nivelului de izolare a tranzacției citeste neangajat, în care conflictele sunt rezolvate actualizare pierdută. Dar Cassandra nu oferă un mecanism de rollback la nivel de cluster, de exemplu, este posibilă o situație când autentificarea și parola vor fi salvate pe un anumit număr de noduri, dar nu suficient W pentru a oferi utilizatorului rezultatul corect, utilizatorul este obligat să rezolve el însuși acest conflict. Mecanismul de asigurare a izolării este acela că pentru fiecare înregistrare care este schimbată se creează o versiune invizibilă, izolată pentru clienți, care ulterior înlocuiește automat versiunea veche prin mecanismele de comparare și schimb descrise mai sus.

„D” Fiabilitate

Indiferent de problemele de la niveluri inferioare (de exemplu, întreruperea sistemului sau defecțiunile hardware), modificările efectuate printr-o tranzacție finalizată cu succes ar trebui să rămână salvate după ce sistemul este readus în funcțiune. Cu alte cuvinte, dacă utilizatorul a primit confirmarea din partea sistemului că tranzacția a fost finalizată, el poate fi sigur că modificările pe care le-a făcut nu vor fi anulate din cauza unor eșecuri.

Cel mai previzibil scenariu de eșec este o întrerupere de curent sau o repornire a serverului. Un sistem complet fiabil în acest caz nu ar trebui să returneze un răspuns utilizatorului până când nu scrie toate modificările din memorie pe hard disk. Scrierea pe disc durează prea mult și multe sisteme NoSQL fac compromisuri de dragul performanței.

Asigurarea fiabilității într-un singur server
Un disc standard poate rezista la 70-150 de operațiuni pe secundă, ceea ce reprezintă un debit de până la 150 MB/s, ssd - 700 MB/s, DDR - 6000 - 17000 MB/s. Prin urmare, asigurarea fiabilității într-un singur server, asigurând în același timp performanțe ridicate, înseamnă reducerea numărului de scrieri cu acces aleatoriu și creșterea scrierilor secvențiale. În mod ideal, sistemul ar trebui să minimizeze numărul de intrări între apeluri fsync(sincronizarea datelor în memorie și pe disc). Pentru aceasta sunt folosite mai multe tehnici.
Controlul frecvenței fsync
Redis oferă mai multe modalități de a configura când să apelați fsync. Îl puteți configura pentru a fi apelat după fiecare schimbare de înregistrare - care este cea mai lentă și mai sigură alegere. Pentru a îmbunătăți performanța, puteți declanșa o spălare a discului la fiecare N secunde, în cel mai rău caz veți pierde date în N ultimele secunde, ceea ce poate fi destul de acceptabil pentru unii utilizatori. Dacă fiabilitatea nu este deloc critică, atunci puteți dezactiva fsync și vă puteți baza pe sistemul însuși, la un moment dat, sincronizarea memoriei cu discul.
Creșterea scrierii secvențiale prin înregistrare
Pentru a căuta în mod eficient date, sistemele NoSQL folosesc adesea structuri suplimentare, de exemplu, arbori B pentru a construi indecși; lucrul cu acestea provoacă accesări aleatorii multiple la disc. Pentru a reduce acest lucru, unele sisteme ( Cassandra, HBase, Riak) adaugă operațiuni de actualizare la un fișier scris secvențial numit reface log. În timp ce unele structuri sunt scrise pe disc destul de rar, jurnalul este scris des. După un accident, înregistrările lipsă pot fi restaurate folosind jurnalul.
Creșterea debitului prin gruparea înregistrărilor
Cassandra grupează mai multe modificări simultane într-o fereastră scurtă care poate fi combinată într-una singură fsync. Această abordare, numită comiterea grupului, crește timpul de răspuns pentru un utilizator, deoarece este forțat să aștepte mai multe alte tranzacții pentru a le înregistra pe ale sale. Avantajul aici este obținut prin creșterea debitului general, deoarece mai multe intrări aleatorii pot fi îmbinate.
Asigurarea fiabilității în cadrul unui cluster de servere
Datorită posibilității de defecțiuni neașteptate de disc și server, este necesar să se distribuie informații pe mai multe mașini.
Redis reprezintă un clasic stăpân-sclav arhitectura pentru replicarea datelor. Toate operațiunile asociate cu masterul se reduc la replici sub forma unui jurnal.
MongoDB este o structură în care un anumit număr de servere stochează fiecare document și este posibil să se stabilească numărul de servere W , descris mai sus, care este minimul necesar pentru a înregistra și a returna controlul utilizatorului.
HBase atinge fiabilitatea multi-server prin utilizarea unui sistem de fișiere distribuit HDFS.

În general, se poate observa o anumită tendință în instrumentele moderne NoSQL de a oferi o mai mare consistență a datelor. Dar totuși, instrumentele SQL și NoSQL pot exista și dezvolta în paralel și pot rezolva probleme complet diferite.

Poate că ați auzit deja termenul ca tranzacţie . Dacă nu sau ați uitat, atunci permiteți-ne să vă reamintim că mai jos tranzacţie se referă la o anumită secvență de operații (acțiuni de inserare, actualizare sau ștergere) din baza de date care trebuie efectuate ca parte a unui singur întreg.

Cu toții folosim serviciile băncilor și efectuăm diverse tranzacții cu fonduri. Cum să obțineți fiabilitatea în acest caz? Cerințele de securitate pentru efectuarea operațiunilor în astfel de sisteme sunt crescute. Acum imaginați-vă că transferați fonduri unei persoane cunoscute. Doriți ca fondurile să fie debitate din contul dvs. și transferate în contul destinatarului. Dar ce se întâmplă în cazul unei pene de curent, cum ar fi o întrerupere de curent sau o altă urgență? Cine vă garantează că nu vă veți găsi într-o situație în care banii v-au părăsit contul, dar transferul în contul destinatarului nu a avut loc. Ajută la prevenirea unor astfel de situații tranzacții.

Angajarea și retragerea unei tranzacții.

O tranzacție combină mai multe extrase SQL. Dacă apare vreun eșec ca urmare a executării a cel puțin uneia dintre cereri, tranzacția este imediat anulată ( rollback). Dacă totul este în regulă și toate acțiunile dintr-o tranzacție au fost finalizate cu succes, atunci se efectuează comiterea ( comite) tranzacții și numai în acest caz modificările corespunzătoare sunt scrise în baza de date.

Acum să demonstrăm un exemplu de utilizare a tranzacțiilor în SGBD MySQL(în cele mai populare SGBD acest mecanism nu este fundamental diferit):

Să avem un tabel de testare conturi, care stochează informații despre conturile de utilizator. Și un domeniu care ne interesează se numește echilibru. Când se transferă dintr-un cont în altul, fondurile ar trebui să fie debitate într-un cont și creditate în altul (în scopuri practice, puteți crea singur o mică bază de date).

Tranzacția începe cu un cuvânt cheie ÎNCEPE. Doi operatori ACTUALIZAȚI tranzacțiile interne fac parte din aceeași tranzacție și pot fi executate fie ambele în același timp, fie niciuna dintre ele (trebuie să aibă loc o derulare). Echipă COMMIT servește pentru a indica încheierea unei tranzacții și efectuarea modificărilor. Dacă commit-ul are succes, atunci toate modificările din baza de date sursă vor fi afișate.

Pentru a anula o tranzacție, puteți scrie în mod explicit comanda ROLLBACK.

Proprietăți ACIDE.

Deci, ne-am familiarizat cu conceptul de tranzacție, commit și rollback. Acum să ne uităm la patru proprietăți foarte importante ale unei tranzacții despre care oamenii le place adesea să întrebe în interviuri. Cerințe ACID la sfârșitul anilor 70 formulat de Jim Gray (câștigător al Premiului Turing pentru contribuția sa la dezvoltarea bazelor de date). Și așa sună:

  • Atomicitatea- atomicitate. Despre ce am vorbit mai sus. tranzacția este atomică, adică toate acțiunile efectuate în cadrul unei singure tranzacții sunt un singur întreg.
  • Consecvență— consistența. Fiecare nouă tranzacție mută baza de date dintr-o stare consistentă în alta. Dacă baza de date este distribuită, atunci toate replicile sale trebuie să conțină aceeași versiune a datelor pentru a asigura disponibilitatea. Această regulă este adesea încălcată de mulți NoSQL baze de date.
  • Izolare- izolare. Tranzacțiile nu se afectează reciproc. În cazul execuției paralele, actualizarea parțială a datelor nu ar trebui să aibă loc.
  • Durabilitate- fiabilitate. Doriți ca toate modificările făcute prin această tranzacție să fie salvate în caz de eșec? De aceea această listă are proprietatea de fiabilitate.