„Pro, dar nu un cluster” sau cum am înlocuit SGBD-ul importat

(ts) Yandex.Imagini

Toate personajele sunt fictive, mărcile aparțin proprietarilor lor, orice asemănări sunt aleatorii și, în general, aceasta este „judecata de valoare subiectivă, vă rog să nu spargeți ușa...”.

Avem o experiență considerabilă în transferul sistemelor informaționale cu logică într-o bază de date de la un SGBD la altul. În contextul decretului guvernamental nr. 1236 din 16.11.2016 noiembrie XNUMX, acesta este adesea un transfer de la Oracle la Postgresql. Vă putem spune separat cum să organizați procesul cât mai eficient și fără durere posibil; astăzi vom vorbi despre caracteristicile utilizării unui cluster și despre ce probleme pot fi întâmpinate la construirea unor sisteme distribuite foarte încărcate, cu o logică complexă în proceduri și funcții.

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

Să presupunem că ați transferat deja toată logica de la plsql la pgsql. Și testele tale de regresie sunt destul de OK, acum bineînțeles că te gândești la scalare, pentru că... testele de încărcare nu te fac foarte fericit, mai ales pe hardware-ul care a fost inclus inițial în proiect, pentru acel SGBD foarte diferit. Să presupunem că ați găsit o soluție de la furnizorul autohton „Postgres Professional” cu o opțiune numită „multimaster”, care este disponibilă numai în versiunea „maximum” a „Postgres Pro Enterprise” și conform descrierii - este foarte asemănătoare cu ceea ce ai nevoie, iar odată cu primul studiu superficial îmi va veni gândul: „Oh! Asta e în loc de RAC! Și chiar și cu o conductă tehnică în patria noastră!”

Dar nu vă grăbiți să vă bucurați și, în continuare, vă vom descrie de ce trebuie să cunoașteți aceste nuanțe, deoarece... sunt greu de prezis, chiar și după citirea amănunțită a documentației produsului. Evaluați dacă sunteți pregătit să actualizați frecvent versiunile DBMS direct pe site-ul de producție, deoarece Unele defecte nu sunt compatibile cu utilizarea 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 pe care l-ați putea întâlni sunt particularitățile modului în care funcționează tranzacțiile, în așa-numitul. modul „în două faze” și, uneori, nu există nicio modalitate de a remedia acest lucru decât prin rescrierea întregii logici a procedurii dvs. Iată un exemplu simplu:

create table test1 (id integer, id1 integer);
insert into test1 values (1, 1),(1, 2);
 
ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;
 
update test1
           set id1 =
               case id1
                 when 1
                 then 2
                 else id1 - sign(2 - 1)
               end
         where id1 between 1 and 2;

Apare o eroare:

ОШИБКА:  [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.

Apoi puteți lupta mult timp cu dead lock în versiunile 10.5, 10.6 și singura soluție cunoscută care distruge întreaga esență a clusterului este eliminarea tabelelor „cu probleme” din cluster, de exemplu. faceți make_table_local, dar acest lucru îi va permite cel puțin să funcționeze și nu va pune totul în așteptare din cauza așteptărilor suspendate pentru comiterea tranzacțiilor. Ei bine, sau instalați o actualizare la versiunea 11.2, care ar trebui să vă ajute, dar poate nu, nu uitați să verificați.

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

username= mtm и backend_type = background worker

Și în această situație, doar actualizarea versiunii DBMS la 11.2 și o versiune ulterioară vă va ajuta, sau poate nu vă va ajuta.

Unele operațiuni cu indexuri pot duce la erori, care indică în mod clar că problema este în Replicarea bidirecțională; veți vedea direct BDR în jurnalele MTM. Este într-adevăr al 2-lea Cadran? Nu... am cumpărat un multimaster, e doar o coincidență, este numele tehnologiei.

[MTM] bdr doesn't support index rechecks
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: send ABORT notification for transaction  (5467) local xid=4083 to coordinator 3
[MTM] Receive ABORT_PREPARED logical message for transaction MTM-3-25030-83-605694076627780 from node 3
[MTM] Abort prepared transaction MTM-3-25030-83-605694076627780 status InProgress from node 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448 

Dacă utilizați tabele temporare, în ciuda asigurărilor: „Extensia multimaster realizează replicarea datelor într-o manieră complet automată. Puteți efectua simultan tranzacții de scriere și puteți lucra cu tabele temporare pe orice nod din cluster.”

Apoi, de fapt, veți obține că replicarea nu funcționează în toate tabelele utilizate în procedură, dacă codul conține crearea unui tabel temporar și chiar și utilizarea multimaster.remote_functions nu va ajuta, va trebui să vă actualizați sau să rescrieți logica în procedura. Dacă trebuie să utilizați două extensii multimaster și pg_pathman simultan în Postgres Pro Enterprise v 10.5, atunci verificați asta cu acest exemplu simplu:

CREATE TABLE measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

CREATE TABLE measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('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);

Următoarele erori încep să apară în jurnalele de pe nodurile DBMS:

…
 PATHMAN_CONFIG doesn't contain relation 23245
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt//…/ent-10/lib/pg_pathman.so"
> ОТЛАДКА:  find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) name: unnamed; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
> switched to timeline 1 valid until 0/0
…
Transaction MTM-1-13604-7-612438856339841 (6919) is aborted on node 2. Check its log to see error details.
...
[MTM] 28295: REMOTE begin abort transaction 7017
…
[MTM] 28295: send ABORT notification for transaction  (6919) local xid=7017 to coordinator 1

Puteți afla care sunt aceste erori în suportul tehnic, nu degeaba l-ați cumpărat.

Ce să fac? Dreapta! Faceți upgrade la „Postgres Pro Enterprise” v 11.2

Separat, trebuie să știți că secvența, fiind un obiect al unei baze de date replicate, nu are o valoare end-to-end în întregul cluster, fiecare secvență este locală pentru fiecare nod și dacă aveți câmpuri cu restricții unice și secvență de utilizare, atunci puteți face doar o creștere echivalentă cu numărul nodului din cluster, deoarece Cât mai multe noduri din cluster, sequence și int vor crește mai repede decât v-ați așteptat. Pentru a simplifica lucrul cu secvența în produs, veți găsi chiar și funcția alter_sequences, care va face incrementele necesare pentru fiecare secvență pe toate nodurile, dar fiți pregătiți că funcția nu va funcționa în toate versiunile. Desigur, îl puteți scrie singur, folosind codul din github ca bază sau corectându-l singur direct în DBMS. În acest caz, câmpurile cu tipul serialbigserial vor funcționa mai corect, dar pentru a le utiliza, cel mai probabil va trebui să rescrieți codul procedurilor și funcțiilor dumneavoastră. Poate că cineva va găsi utilă funcția monotonic_sequences.

Înainte de versiunea 11.2 a Postgres Pro Enterprise, replicarea va funcționa numai dacă există chei primare unice, luați în considerare acest lucru la dezvoltare.

Separat, aș dori să menționez particularitățile modului în care funcționează npgsql într-o soluție de cluster; aceste probleme nu apar pe un singur nod, ci sunt destul de prezente într-un multimaster.
În unele versiuni este posibil să întâmpinați o eroare:

Exception Details: Npgsql.PostgresException: 25001: команда SET TRANSACTION ISOLATION LEVEL 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Ce se poate face? Trebuie doar să nu folosiți unele versiuni. Trebuie să le cunoști, pentru că... Eroarea apare în mai multe versiuni și, chiar și după prima remediere, este posibil să o întâlniți mai târziu. De asemenea, trebuie să fiți pregătit pentru acest lucru și este mai bine să acoperiți toate defectele SGBD identificate care sunt corectate de producător cu teste de regresie separate. Ca să zic așa, ai încredere, dar verifică.

Dacă aplicația folosește npgsql și comută între noduri crezând că toate sunt la fel, atunci este posibil să primiți o eroare:

EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...

Această eroare va apărea deoarece legarea este în curs

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

tipuri compozite la pornirea aplicației pentru toate conexiunile. Ca urmare, obținem un identificator de la un nod, iar la solicitarea pe un alt nod, acesta nu se potrivește, în urma căruia se returnează o eroare, adică. Lucrul transparent cu tipurile compuse dintr-un cluster nu va fi posibil pentru unele aplicații fără rescrieri suplimentare din partea aplicației (dacă reușiți să faceți acest lucru).

După cum știm cu toții, o evaluare generală a stării clusterului este foarte importantă pentru diagnosticare și măsuri operaționale în timpul funcționării, în produs puteți găsi câteva funcții care ar trebui să vă ușureze viața, dar uneori pot oferi ceva complet diferit de ceea ce tu și chiar producătorul însuși te aștepți de la ei.

De exemplu:

select mtm.collect_cluster_info();
на каждой ноде выдает одинаковый результат:
(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 câmpul LiveNodes conține peste tot numărul 2, deși conform descrierii operațiunii multimaster ar trebui să corespundă numărului AllNodes=3? Răspuns: trebuie să actualizați versiunea DBMS.

Și fiți pregătiți să colectați jurnale pentru toate nodurile, pentru că... de obicei, veți vedea „eroarea este în jurnalul altui nod”. Suportul tehnic va accepta toate defectele pe care le identificați și vă va informa că următoarea versiune este gata, care uneori va trebui instalată cu serviciul oprit, alteori pentru o perioadă lungă de timp (în funcție de dimensiunea SGBD-ului dvs.). Nu trebuie să sperați că problemele operaționale vor deranja foarte mult vânzătorul, iar actualizarea din cauza defectelor identificate va fi efectuată cu participarea reprezentanților vânzătorului sau, mai degrabă, nici nu trebuie să implicați reprezentanții vânzătorului, deoarece în În final, puteți ajunge cu un cluster dezasamblat în producție fără backup.

De fapt, în licența pentru un produs comercial, producătorul avertizează sincer: „Acest software este furnizat „ca atare” și Postgres Professional Limited Liability Company nu este obligată să ofere întreținere, asistență, actualizări, extensii sau modificări.”

Dacă încă nu ați ghicit despre ce produs vorbim, atunci toată această experiență a fost câștigată ca urmare a funcționării de-a lungul unui an a bazei de date Postgres Pro Enterprise. Puteți trage propria concluzie, este atât de umed încât cresc ciupercile.

Dar acest lucru nu ar fi atât de rău dacă ar fi făcut în timp util și ar fi eliminat prompt problemele emergente.

Dar tocmai asta nu se întâmplă. Se pare că producătorul nu are suficiente resurse pentru a elimina prompt erorile identificate.

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

Aveți experiență în trecerea de la un SGBD străin/proprietar la unul gratuit/intern?

• 21,3%Da, pozitiv10

• 10,6%Da, negativ5

• 21,3%Nu, SGBD-ul nu a fost modificat10

• 4,3%SGBD-ul a fost schimbat, dar nimic nu sa schimbat2

• 42,6%Vezi rezultatele20

Au votat 47 utilizatori. 12 utilizatori s-au abținut.

Sursa: www.habr.com