🥇"Pro, men ikke cluster" eller hvordan vi udførte importsubstitution af databasesystemet

Alle karakterer er fiktive, varemærker tilhører deres ejere, enhver lighed er tilfældig, og generelt er dette min «subjektive vurdering, vær venlig ikke at bryde døren…».

Vi har betydelig erfaring med at overføre informationssystemer med logik i databasen fra én DBMS til en anden. I henhold til regeringsbeslutning nr. 1236 af den 16.11.2016 er det ofte overgangen fra Oracle til PostgreSQL. Hvordan man organiserer processen så effektivt og smertefrit som muligt – kan vi fortælle om separat; i dag vil vi dog fokusere på klyngefunktionalitet og de udfordringer, der kan opstå ved opbygningen af højtydende distribuerede systemer med kompleks logik i procedurer og funktioner.

Spoiler - ja, CAP, RAC og pg multimaster er meget forskellige løsninger.

Lad os antage, at I allerede har overført al logik fra PL/SQL til PG/SQL. Jeres regresionstest er helt OK, og nu tænker I naturligvis på skalering, da belastningstestene ikke yderligere glæder jer, især ikke på det udstyr, der blev fastsat i projektet fra starten til den anden DBMS. Lad os sige, at I har fundet en løsning fra den indenlandske leverandør 'Postgres Professional' med en funktion kaldet 'multimaster', som kun er tilgængelig i den 'maksimale' version af 'Postgres Pro Enterprise', og beskrivelsen lyder meget lig det, I har brug for; ved et første overfladisk kig tænker man: 'Åh! Det er perfekt som erstatning for RAC! Og oven i det, med teknisk support hjemmefra!'.

Men skynd jer ikke at glæde jer, vi vil beskrive, hvorfor disse nuancer skal være kendt, da de er svære at forudse, selv ved grundig læsning af produktdokumentationen. Overvej, om I vil være klar til ofte at opdatere versionerne af DBMS direkte på produktionsmiljøet, da nogle fejl ikke er kompatible med industriel brug og er svære at identificere under test.
Start med en grundig gennemlæsning af afsnittet 'multimaster' - 'begrænsninger' på producentens hjemmeside.

Det første, I kan støde på, er karakteristika ved arbejdet med transaktioner i det, der kaldes 'to-fase'-tilstand, og nogle gange kan dette ikke rettes uden at omskrive hele logikken i jeres procedure. Her er et simpelt eksempel:

opret tabel test1 (id integer, id1 integer);
indsæt i test1 værdier (1, 1),(1, 2);
 
ALTER TABLE test1 TILFØJ BEGRÆNSNING test1_uk UNIKT (id,id1) DEFERRABLE INITIALLY DEFERRED;
 
opdater test1
           sæt id1 =
               sag id1
                 når 1
                 så 2
                 ellers id1 - sign(2 - 1)
               slut
         hvor id1 er mellem 1 og 2;

Der opstår en fejl:

FEJL:  [MTM] Transaktion MTM-1-2435-10-605783555137701 (10654) er annulleret på node 3. Tjeks dens log for at se fejldetaljer.

Man kan længe kæmpe mod dead lock i versionerne 10.5, 10.6, og den eneste kendte redning, der dræber hele essensen af klyngen – er at fjerne de "problematiske" tabeller fra klyngen, dvs. lave make_table_local, men det vil i det mindste tillade drift, i stedet for at alt står stille på grund af hængte ventninger til transaktionsfixering. Eller opgrader til version 11.2, som burde hjælpe, men måske ikke, glem ikke at tjekke.

I nogle versioner vil du kunne få en endnu mere mystisk lås:

brugername= mtm og backend_type = baggrundsarbejder

Og i denne situation hjælper kun opgradering af DBMS-versionen til 11.2 eller højere, men det kan også være, at det ikke hjælper.

Nogle operationer med indekser kan føre til fejl, som tydeligt angiver, at problemet er i Bi-Directional Replication; i MTM-loggene vil du se BDR direkte. Er det virkelig 2ndQuadrant? Nej… vi har jo købt multimaster, det er bare en tilfældighed, det er navnet på teknologien.

[MTM] bdr understøtter ikke indeksgenkontroller
[MTM] 12124: REMOTE begynd annullere transaktion 4083
[MTM] 12124: send ABORT-underretning for transaktion (5467) lokal xid=4083 til koordinator 3
[MTM] Modtag ABORT_PREPARED logisk besked for transaktion MTM-3-25030-83-605694076627780 fra node 3
[MTM] Annuller forberedt transaktion MTM-3-25030-83-605694076627780 status In Progress fra node 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaktion=MTM-3-25030-83-605694076627780 lsn=9fff448

Hvis du bruger midlertidige tabeller, på trods af forsikringerne: "Multimaster-udvidelsen udfører replikering af data på helt automatisk vis. Du kan udføre skrivetransaktioner samtidig og arbejde med midlertidige tabeller på enhver node i klyngen."

Så får du i praksis, at replikeringen ikke virker for alle tabeller, der anvendes i proceduren, hvis koden indeholder oprettelse af en midlertidig tabel, og selv brug af multimaster.remote_functions vil ikke hjælpe; det bliver nødvendigt at opgradere eller omskrive din logik i proceduren. Hvis du skal bruge to multimaster-udvidelser og pg_pathman sammen i "Postgres Pro Enterprise" v 10.5, så tjek, at i dette enkle eksempel:

OPRET TABEL måling (
    by_id         int ikke null,
    logdato       dato ikke null,
    top-temperatur int,
    enhedssalg    int
) PARTITION BY RANGE (logdato);

OPRET TABEL måling_y2019m06 PARTITION OF måling FOR VALUES FROM ('2019-06-01') TO ('2019-07-01');
indsæt i måling værdier (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
indsæt i måling værdier (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
indsæt i måling værdier (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
indsæt i måling værdier (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

I loggene på DBMS-noderne begynder sådanne fejl at dukke op:

…
 PATHMAN_CONFIG indeholder ikke relation 23245
> find_in_dynamic_libpath: forsøger "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: forsøger "\/opt\/\/…\/ent-10\/lib\/pg_pathman.so"
> DEBAT:  find_in_dynamic_libpath: forsøger "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: forsøger "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) navn: unnamed; blockState: PREPARE; state: INPROGR, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) navn: unnamed; blockState: DEFAULT; state: INPROGR, xid\/subid\/cid: 0\/1\/0
> skiftet til tidslinje 1 gyldig indtil 0\/0
…
Transaktion MTM-1-13604-7-612438856339841 (6919) er annulleret på node 2. Tjek dens log for at se fejlbeskeder.
...
[MTM] 28295: REMOTE begynde annulere transaktion 7017
…
[MTM] 28295: send ABORT underretning for transaktion  (6919) lokal xid=7017 til koordinator 1

Hvad betyder disse fejl? Du kan finde ud af det i teknisk support, du har ikke købt det forgæves.

Hvad skal man gøre? Rigtigt! Opgradere til "Postgres Pro Enterprise" til v 11.2

Det er vigtigt at vide, at sekvensen, som er et objekt i den replikerede DB, ikke har en universel værdi for hele klyngen; hver sekvens er lokal for hver node, og hvis du har felter med unikke begrænsninger og bruger sekvens, kan du kun udføre en inkrement, der er lig med nummeret på noden i klyngen, fordi jo flere noder, jo hurtigere vil sekvensen også vokse, og int vil muligvis løbe tør hurtigere end forventet. For at forenkle arbejdet med sekvenser i produktet finder du endda funktionen alter_sequences, som vil udføre de nødvendige inkrementer for hver sekvens på alle noder, men vær forberedt på, at funktionen ikke vil fungere i alle versioner. Selvfølgelig kan man skrive den selv ved at tage udgangspunkt i koden fra github eller ændre den direkte i DBMS. Feltet med typen serialbigserial vil fungere mere korrekt, men for at bruges kræver det sandsynligvis, at du omskriver koden til dine procedurer og funktioner. Måske vil nogen finde funktionen monotonic_sequences nyttig.

Indtil version 11.2 af "Postgres Pro Enterprise" vil replikation kun fungere, hvis der er unikke primære nøgler, så husk dette under udviklingen.

Det er værd at nævne nogle af de særlige karakteristika ved npgsql, især i klusterløsningen; disse problemer opstår ikke på en enkelt node, men de er til stede i multimasteren.
I nogle versioner kan man støde på fejlen:

Exception Details: Npgsql.PostgresException: 25001: kommandoen SET TRANSACTION ISOLATION LEVEL 
Beskrivelse: En ubehandlet undtagelse opstod under udførelsen af den aktuelle webanmodning. Gennemgå venligst stack-tracen for yderligere information om fejlen og hvor den stammer fra i koden.

Hvad kan der gøres? Det er bedst ikke at bruge visse versioner. Man skal være opmærksom på dem, da fejlen ikke kun optræder i én version, og selv efter den første rettelse kan man støde på den senere. Man skal også være forberedt på dette og helst dække alle identificerede defekter i databasen, som producenten retter, med separate regressionstest. Som man siger,

Hvis appen bruger npgsql og skifter mellem noder, under forudsætningen om, at de allesammen er ens, kan du få en fejl:

EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache opslag mislykkedes for type ...

En sådan fejl vil opstå, fordi der udføres binding af

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

komposittyper ved opstart af appen for alle forbindelser. Resultatet er, at vi får en identifikator fra en node, og når vi spørger en anden node, stemmer den ikke overens, hvilket resulterer i en fejl; det vil sige, at det vil være umuligt at arbejde transparent med komposittyper i klusteret for nogle applikationer uden yderligere omskrivninger på applikationssiden (hvis du kan lykkes med det).

Som vi alle ved, er den generelle vurdering af klusterets tilstand meget vigtig for diagnosticering og hurtige handlinger; i produktet vil du finde nogle funktioner, der skal gøre dit liv lettere, men nogle gange kan de give helt andre resultater end hvad du og endda producenten forventer.

For eksempel:

select mtm.collect_cluster_info();
på hver node giver det et identisk resultat:
(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")

Men hvorfor står der tallet 2 i feltet LiveNodes, når det i multimasterens beskrivelse skulle svare til antallet af AllNodes=3? Svaret er: du skal opdatere databaseversionen.

Og vær klar til at indsamle logfiler fra alle noder, da du normalt vil se "fejlen findes i loggen fra en anden node". Teknisk support vil acceptere alle fejl, du finder, og informere om klarheden af den næste version, som nogle gange skal installeres med nedetid på tjenesten og andre gange vil tage lang tid (afhænger af størrelsen på din databasesystem). Det er ikke en god idé at håbe, at driftsproblemer vil bekymre leverandøren for meget, og opdateringen på grund af opdagede fejl vil gennemføres med repræsentanter fra leverandøren. Faktisk er det bedre ikke at involvere leverandørens repræsentanter, da du i sidste ende kan få et produktionsmiljø med et nedbrudt cluster uden backup.

I licensen til det kommercielle produkt advarer producenterne ærligt: "Denne software leveres på en "som den er" basis, og selskabet Postgres Professionel er ikke forpligtet til at levere støtte, service, opdateringer, udvidelser eller ændringer."

Hvis du endnu ikke har gættet, hvilket produkt der er tale om, så er alle disse erfaringer blevet opnået ved et års drift af Postgres Pro Enterprise-databasen. Du kan selv drage konklusionen – det er så råt, at svampe vokser.

Men det ville kun være en del af problemet, hvis man hurtigere og mere effektivt rettede opståede problemer.

Men det sker netop ikke. Tilsyneladende har producenten ikke nok ressourcer til hurtigt at rette de identificerede fejl.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.

Har du erfaring med overgang fra udenlandsk/proprietær databasesystem til et frit/nationalt?

21,3%Ja, positiv10
10,6%Ja, negativ5
21,3%Nej, vi har ikke ændret databasesystem10
4,3%Vi har ændret databasesystem, men der er ikke sket nogen ændringer2
42,6%Se resultater20

47 brugere har stemt. 12 brugere har undladt at tage stilling.

Kilde: habr.com

«Pro, men uden klynge» eller hvordan vi har importeret databaser

Har du erfaring med overgang fra udenlandsk/proprietær databasesystem til et frit/nationalt?