"Pro, da nu cluster" sau cum ne-am substituit SGBD-urile

(c) Yandex.Images

Toți caracterii sunt fictivi, mărci comerciale aparțin proprietarilor lor, orice coincidences sunt întâmplătoare și, în general, aceasta este „o judecată subiectivă, vă rugăm să nu spargeți ușa…”.

Avem o experiență considerabilă în traducerea sistemelor informaționale cu logică în baza de date dintr-o SGBD în alta. În conformitate cu hotărârea guvernului nr. 1236 din 16.11.2016, adesea este vorba de o migrare de la Oracle la PostgreSQL. Cum să organizăm procesul cât mai eficient și fără dureri — putem discuta separat, astăzi vom vorbi despre particularitățile utilizării clusterului și despre ce probleme pot apărea la construirea sistemelor distribuite cu încărcare ridicată și cu logică complexă în proceduri și funcții.

Spoiler – da, RAC și pg multimaster sunt soluții foarte diferite.

Să presupunem că ați migrat deja toată logica de la plsql la pgsql. Iar testele dumneavoastră de regresie sunt în regulă, acum desigur vă gândiți la scalabilitate, având în vedere că testele de încărcare nu vă mulțumesc, mai ales pe acel hardware care a fost planificat inițial în proiect pentru acea altă SGBD. Să zicem că ați găsit o soluție de la un vendor local "Postgres Professional" cu o opțiune numită "multimaster", care este disponibilă doar în versiunea "maximală" "Postgres Pro Enterprise" și, conform descrierii, este foarte asemănătoare cu ceea ce aveți nevoie, iar la prima examinare superficială vă poate veni în minte gândul: "O! Este exact ce ne trebuie, în loc de RAC! Plus, cu suport tehnic în țară!".

Dar nu vă grăbiți să vă bucurați, și mai departe vom descrie de ce aceste nuanțe trebuie cunoscute, deoarece este dificil să le anticipați, chiar și citind bine documentația produsului. Evaluati daca v-ati pregatit sa actualizați frecvent versiunile SGBD direct pe platforma de producție, deoarece unele defecte nu sunt compatibile cu exploatarea industrială și sunt greu de detectat în timpul testării.
Începeți prin a citi cu atenție secțiunea „multimaster” — „limitări” de pe site-ul producătorului.

Primul lucru cu care vă puteți confrunta sunt particularitățile funcționării tranzacțiilor, în așa-numitul mod „în două faze”, iar uneori, fără a rescrie întreaga logică a procedurii dvs., nu se poate corecta. Iată un exemplu simplu:

creați tabelă test1 (id integer, id1 integer);
introduceți valori în test1 (1, 1),(1, 2);
 
ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;
 
actualizați test1
           set id1 =
               caz id1
                 când 1
                 atunci 2
                 alt id1 - semn(2 - 1)
               sfârșit
         unde id1 între 1 și 2;

Apare o eroare:

EROARE:  [MTM] Tranzacția MTM-1-2435-10-605783555137701 (10654) este abandonată pe nodul 3. Consultați jurnalul său pentru a vedea detaliile erorii.

Mai departe, puteți lupta mult timp cu dead lock-urile în versiunile 10.5, 10.6 și singura salvare cunoscută, care distruge esența cluster-ului – este să eliminați din cluster tabelele „problematice”, adică să faceți make_table_local, dar asta cel puțin vă va permite să lucrați, fără a bloca totul din cauza așteptărilor suspendate ale confirmării tranzacțiilor. Sau să treceți la actualizarea versiunii 11.2, care ar trebui să ajute, dar poate că nu, nu uitați să verificați.

În unele versiuni veți putea obține o blocare și mai misterioasă:

nume utilizator= mtm și backend_type = background worker

Și în această situație, singura soluție pentru dvs. va fi actualizarea versiunii DBMS la 11.2 sau mai sus, dar poate că nici aceasta nu va ajuta.

Unele operațiuni cu indecși pot duce la erori, unde se indică clar că problema este în Bi-Directional Replication, în jurnalele MTM veți vedea direct BDR. Oare 2ndQuadrant? Nu... am cumpărat multimaster, este doar o coincidență, acesta este numele tehnologiei.

[MTM] bdr nu suportă re-verificările de index
[MTM] 12124: REMOTE începe abandonarea tranzacției 4083
[MTM] 12124: trimite notificare ABORT pentru tranzacția (5467) xid local=4083 către coordonator 3
[MTM] Primește mesajul logic ABORT_PREPARED pentru tranzacția MTM-3-25030-83-605694076627780 de la nodul 3
[MTM] Abandonare tranzacție pregătită MTM-3-25030-83-605694076627780 status InProgress de la nodul 3 originId=3
[MTM] MtmLogAbortLogicalMessage nod=3 tranzacție=MTM-3-25030-83-605694076627780 lsn=9fff448 

Dacă folosiți tabele temporare, în ciuda asigurărilor: „Extensia multimaster efectuează replicarea datelor complet automat. Puteți efectua simultan tranzacții de scriere și să lucrați cu tabele temporare pe orice nod al cluster-ului”.

Atunci, de fapt, veți obține că replicarea nu funcționează pe toate tabelele utilizate în procedură, dacă în cod există creația unei tabele temporare, și chiar folosirea multimaster.remote_functions nu va ajuta, va trebui să vă actualizați sau să rescrieți logica în procedură. Dacă trebuie să folosiți simultan două extensii multimaster și pg_pathman în cadrul „Postgres Pro Enterprise” v 10.5, asigurați-vă că în acest exemplu simplu:

CREAȚI TABELA measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) PARTIȚIONAT PE RANGE (logdate);

CREAȚI TABELA measurement_y2019m06 PARTIȚIE A measurement PENTRU VALORI DE LA ('2019-06-01') LA ('2019-07-01');
insert into measurement values (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

În jurnalurile de pe nodurile SGBD încep să apară următoarele erori:

…
 PATHMAN_CONFIG nu conține relația 23245
> find_in_dynamic_libpath: încercând "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: încercând "\/opt\/\/…\/ent-10\/lib\/pg_pathman.so"
> DEBUG:  find_in_dynamic_libpath: încercând "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: încercând "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) nume: fără nume; blockState: PREPARE; stare: INPROGR, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) nume: fără nume; blockState: DEFAULT; stare: INPROGR, xid\/subid\/cid: 0\/1\/0
> comutat pe timeline 1 valid până la 0\/0
…
Transaction MTM-1-13604-7-612438856339841 (6919) este abortată pe nodul 2. Verificați jurnalul său pentru detalii despre eroare.
...
[MTM] 28295: REMOTE începe abortul tranzacției 7017
…
[MTM] 28295: trimite notificarea ABORT pentru tranzacția (6919) xid local=7017 către coordonator 1

Ce sunt aceste erori, veți putea afla de la suportul tehnic, nu degeaba l-ați cumpărat.

Ce trebuie să faceți? Corect! Să actualizați la „Postgres Pro Enterprise” versiunea 11.2

De asemenea, trebuie să știți că sequence, fiind un obiect al bazei de date replicabile, nu are un valoare globală pe întregul cluster, fiecare sequence este local pentru fiecare nod, iar dacă aveți câmpuri cu restricții unice și folosiți sequence, atunci puteți face doar un increment echivalent cu numărul nodului din cluster, deoarece cu câte noduri are cluster-ul, atât de repede va crește și sequence, și int se va termina mai repede decât ați estimat. Pentru a simplifica lucrul cu sequence în produs, veți găsi chiar funcția alter_sequences, care va face incrementările necesare pentru fiecare sequence pe toate nodurile, dar fiți pregătiți că funcția nu va funcționa în toate versiuni. Bineînțeles că o puteți scrie voi înșivă, luând ca bază codul de pe github sau modificându-l direct în SGBD. Câmpurile cu tipul serialbigserial vor funcționa mai corect, dar pentru utilizarea lor probabil va trebui să rescrieți codul procedurilor și funcțiilor voastre. Poate că funcția monotonic_sequences va fi utilă pentru cineva.

Până la versiunea 11.2 „Postgres Pro Enterprise”, replicarea va funcționa doar în prezența cheilor primare unice, țineți cont de acest lucru în timpul dezvoltării.

Ar trebui să menționăm în mod special caracteristicile funcționării npgsql în soluția cluster, aceste probleme nu apar pe un nod unic, dar în multimasternum sunt prezent.
În unele versiuni, poate apărea o eroare:

Detalii despre excepție: Npgsql.PostgresException: 25001: comanda SET TRANSACTION ISOLATION LEVEL 
Descriere: A apărut o excepție necontrolată în timpul executării cererii web curente. Vă rugăm să revizuiți urma stivei pentru mai multe informații despre eroare și de unde a provenit în cod. 

Ce se poate face? Pur și simplu nu trebuie să folosiți anumite versiuni. Trebuie să le cunoașteți, deoarece eroarea apare nu într-o singură versiune și chiar după prima sa corectare, s-ar putea să vă întâlniți cu ea mai târziu. De asemenea, trebuie să fiți pregătit pentru acest lucru și este mai bine să acoperiți toate defectele identificate ale SGBD-ului, corectate de producător, cu teste regresionale separate. Așa să zicem, încredere, dar verificați.

Dacă aplicația folosește npgsql și comută între noduri credând că sunt toate identice, atunci s-ar putea să aveți o eroare:

EXCEPTION: Npgsql.PostgresException (0x80004005): XX000: căutarea în cache a eșuat pentru tip ...

O astfel de eroare va apărea deoarece este realizată o legătură

(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) 

tipurilor composite la pornirea aplicației pentru toate conexiunile. Ca rezultat, obținem un identificator de la un anumit nod, iar la interogarea pe alt nod, nu se potrivește, din această cauză se returnează o eroare, adică va fi imposibil să lucrăm transparent cu tipurile composite în cluster pentru anumite aplicații fără modificări suplimentare la nivelul aplicației (dacă reușiți să faceți acest lucru).

Așa cum știm cu toții, evaluarea generală a stării clusterului este foarte importantă pentru diagnosticare și măsuri operative în funcționare, în produs veți găsi anumite funcții care ar trebui să vă ușureze viața, dar uneori acestea pot oferi exact opusul a ceea ce vă așteptați, chiar și producătorul.

De exemplu:

select mtm.collect_cluster_info();
pe fiecare nod dă același rezultat:
(1,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(2,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(3,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:09")

Dar de ce în câmpul LiveNodes apare peste tot numărul 2, deși conform descrierii funcționării multimasternum ar trebui să corespundă numărului AllNodes=3? Răspuns: este necesară actualizarea versiunii SGBD.

Și fiți pregătiți să colectați jurnalele de pe toate nodurile, deoarece de obicei veți vedea „eroarea se află în jurnalul unui alt nod”. Suportul tehnic va accepta toate defectele descoperite de dvs. și vă va informa despre disponibilitatea următoarei versiuni, care va trebui instalată uneori cu oprirea serviciului, alteori pentru o perioadă mai lungă (în funcție de dimensiunea bazei dvs. de date). Nu ar trebui să sperați că problemele de exploatare vor deranja prea mult vendorul și că actualizarea din cauza defectelor identificate va fi efectuată cu implicarea reprezentanților vendorului; de fapt, nu ar trebui să implicați reprezentanții vendorului, deoarece, în cele din urmă, puteți obține un cluster dezmembrat fără backup în producție.

În licența pentru produsul comercial, producătorul avertizează onest: „Acest software este oferit pe baza principiului „așa cum este”, iar societatea cu răspundere limitată „Postgres Profesional” nu este obligată să ofere asistență, suport, actualizări, extensii sau modificări.”

Dacă nu ați ghicit despre ce produs este vorba, atunci întreaga această experiență a fost obținută în urma unei exploatări de un an a bazei de date Postgres Pro Enterprise. Puteți trasa concluziile singuri, este atât de umed încât cresc ciuperci.

Dar aceasta ar fi fost doar o jumătate din problemă, dacă problemele ar fi fost remediate în timp util și operativ.

Dar acest lucru nu se întâmplă, de fapt. Se pare că resursele producătorului nu sunt suficiente pentru a remedia rapid bug-urile identificate.

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.

Aveți experiență în trecerea de la o bază de date străină/proprietară la una liberă/autohtonă?

• 21,3%Da, pozitiv10

• 10,6%Da, negativ5

• 21,3%Nu, nu am schimbat baza de date10

• 4,3%Am schimbat baza de date, dar nimic nu s-a schimbat2

• 42,6%Vizualizați rezultatele20

Au votat 47 de utilizatori. S-au abținut 12 utilizatori.

Sursa: habr.com