🥇"Pro, por jo kluster" ose si i zëvendësuam DBMS-të

Të gjitha personazhet janë të imagjinuara, markat tregtare i përkasin pronarëve të tyre, çdo përputhje është rastësore dhe në përgjithësi, kjo është një "vlerësim subjektiv, ju lutemi mos thyni derën…".

Ne kemi një përvojë të konsiderueshme në përkthimin e sistemeve informative me logjikë në BD nga një DBMS në një tjetër. Në përputhje me rregulloren e qeverisë nr. 1236, 16.11.2016, shpesh ky është një transfertë nga Oracle në Postgresql. Si ta organizoni procesin sa më efektivisht dhe pa dhimbje – mund të flasim veçmas për këtë, sot do të flasim për veçoritë e përdorimit të klasterit dhe për problemet me të cilat mund të përballeni gjatë ndërtimit të sistemeve të shpërndara me ngarkesë të lartë dhe logjikë komplekse në procedura dhe funksione.

Spoiler – po, këmisha, RAC dhe pg multimaster janë zgjidhje shumë të ndryshme.

Supozoni se keni transferuar tashmë gjithë logjikën nga plsql në pgsql. Dhe testet tuaja regresive janë të gjitha në rregull, tani sigurisht po mendoni për shkallëzim, pasi testet e ngarkesës nuk ju gëzojnë shumë, sidomos në atë harduer që ishte planifikuar në projekt fillimisht, për atë DBMS tjeter. Supozoni se keni gjetur një zgjidhje nga një furnizues vendor "Postgres Professional" me një mundësi të quajtur "multimaster", e cila është e disponueshme vetëm në versionin "maksimal" "Postgres Pro Enterprise" dhe sipas përshkrimit – duket shumë e ngjashme me atë që ju nevojitet, dhe në një studim të parë të sipërfaqshëm do t'ju vijë në mendje mendimi: "Oh! Në vend të RAC kjo është pikërisht ajo! Po ashtu me mbështetje teknike në atdhe!".

Por mos u ngutni të gëzoheni, dhe më tej do të përshkruajmë pse këto nuanca duhen ditur, pasi është e vështirë t'i parashikoni, madje edhe duke lexuar mirë dokumentacionin e produktit. Vlerësoni nëse do të jeni të gatshëm të përditësoni shpesh versionet e DBMS-së direkt në vendin e prodhimit, pasi disa defekte nuk janë të përshtatshme për përdorim në prodhim dhe është e vështirë t'i zbulojmë gjatë testimeve.
Filloni me një lexim të kujdesshëm të seksionit "multimaster" – "kufizimi" në webfaqen e prodhuesit.

E para me të cilën mund të përballeni, janë veçoritë e funksionimit të transaksioneve, në modin "me dy faza", dhe ndonjëherë, përveçse duke ripërshkruar të gjithë logjikën e procedurës tuaj, nuk ka mënyrë tjetër për ta rregulluar. Këtu është një shembull i thjeshtë:

krijo tabelën test1 (id integer, id1 integer);
shkruaj në test1 vlera (1, 1),(1, 2);
 
MODIFIKOHU TABELA test1 SHTO KUSHTIN test1_uk UNIK (id,id1) TË LANSHUESHME fillimisht TË SUSPENDUAR;
 
përditëso test1
           vendos id1 =
               rast id1
                 kur 1
                 atëherë 2
                 përndryshe id1 - shenjë(2 - 1)
               fund
         ku id1 midis 1 dhe 2;

Ndodh një gabim:

GABIM:  [MTM] Transaksioni MTM-1-2435-10-605783555137701 (10654) është anuluar në nyjën 3. Kontrolloni regjistrin e saj për të parë detajet e gabimit.

Mund të vazhdoni të luftoni gjatë me dead lock në versionet 10.5, 10.6 dhe zgjidhja e vetme e njohur që shkatërron të gjithë thelbin e klasterit – është heqja e tabelave "problematike" nga klasteri, dmth. të bëni make_table_local, por kjo do të lejojë të punoni, përndryshe do të bllokoni gjithçka për shkak të pritjeve të varura për konfirmimin e transaksioneve. Ose mund të përditësoni në versionin 11.2, i cili duhet të ndihmojë, ndoshta dhe jo, mos harroni ta kontrolloni.

Në disa versione mund të merrni një bllokim edhe më misterioz:

emri i përdoruesit= mtm dhe backend_type = punonjës i sfondit

Dhe në këtë situatë, vetëm përditësimi i versionit të DBMS deri në 11.2 dhe lart mund t'ju ndihmojë, ndoshta dhe jo.

Disa operacione me indekset mund të çojnë në gabime, ku qartë shfaqet se problemi është pikërisht në Replikimin Bi-Directional, në regjistrat MTM do të shihni menjëherë BDR. A është 2ndQuadrant? Jo… ne e blejmë multimaster, është thjesht një rastësi, kjo është emri i teknologjisë.

[MTM] bdr nuk mbështet kontrollin e indekseve
[MTM] 12124: RISHIKONI fillimin e anuluar të transaksionit 4083
[MTM] 12124: dërgo Njoftimin ANULLO për transaksionin (5467) xid lokal=4083 në koordinuesin 3
[MTM] Marrja e mesazhit ANULLO_PREPARED logjik për transaksionin MTM-3-25030-83-605694076627780 nga nyja 3
[MTM] Anulo transaksionin e përgatitur MTM-3-25030-83-605694076627780 statusi InProgress nga nyja 3 origjinaId=3
[MTM] MtmLogAbortLogicalMessage nyja=3 transaksioni=MTM-3-25030-83-605694076627780 lsn=9fff448

Nëse përdorni tabela përkohshme, pavarësisht nga pretendimet: "Zgjerimi multimaster realizon replikimin e të dhënave në mënyrë plotësisht automatike. Ju mund të ekzekutoni transaksione shkrimi njëkohësisht dhe të punoni me tabela përkohshme në çdo nyje të klasterit."

Aherë, në fakt do të merrni se replikimi nuk funksionon për të gjitha tabelat që përdoren në procedurë, nëse në kod ka krijim të tabelës përkohshme, dhe madje përdorimi multimaster.remote_functions nuk do të ndihmojë, do t'ju duhet të përditësoni ose të ripërpunoni logjikën tuaj në procedurë. Nëse keni nevojë të përdorni njëkohësisht dy zgjerime multimaster dhe pg_pathman brenda "Postgres Pro Enterprise" v 10.5, kontrolloni se në këtë shembull të thjeshtë:

KRIJONI TABELËN e matjes (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) NDARË ME RANGE (logdate);

KRIJONI TABELËN measurement_y2019m06 NDARË TË measurement PËR VLERAT NGA ('2019-06-01') DERI ('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ë log-et e nyjeve të DBMS fillojnë të shfaqen këto gabime:

…
 PATHMAN_CONFIG nuk përmban lidhjen 23245
> find_in_dynamic_libpath: duke provuar "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: duke provuar "\/opt\/\/…\/ent-10\/lib\/pg_pathman.so"
> DEBAGIMI:  find_in_dynamic_libpath: duke provuar "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: duke provuar "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) emri: pa emër; blockState: PREPARE; gjendja: INPROGR, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) emri: pa emër; blockState: DEFAULT; gjendja: INPROGR, xid\/subid\/cid: 0\/1\/0
> kaloi në timeline 1 e vlefshme deri në 0\/0
…
Transaksioni MTM-1-13604-7-612438856339841 (6919) është anuluar në nyjen 2. Kontrolloni log-un e saj për të parë detajet e gabimeve.
...
[MTM] 28295: BEGIN ANULLO TRANSAKSIONIN 7017
…
[MTM] 28295: dërgo NJOFTIMIN ABORT për transaksionin (6919) xid lokal=7017 te koordinatori 1.

Çfarë janë këto gabime, do të mund të mësoni në mbështetje teknike, nuk e blerëti kot.

Çfarë të bëni? E saktë! Azhurnoni në «Postgres Pro Enterprise» deri në v 11.2.

Veçmas duhet të dini se sekuencat, si një objekt i bllokuar për replikim, nuk kanë një vlerë të vazhdueshme për të gjithë klasterin, çdo sekuencë është lokale për çdo nyje dhe nëse keni fusha me kufizime unike dhe përdorni sekumenca, atëherë mund të krijoni vetëm një inkrement të barabartë me numrin e nyjeve në klaster, pasi aq shumë nyje ka në klaster, aq më shpejt do të rritet edhe sekuenca, dhe numri int do të përfundojë më shpejt sesa ju keni parashikuar. Për ta thjeshtuar punën me sekumenca, në produkt do të gjeni edhe funksionin alter_sequences, i cili do të bëjë inkrementet e nevojshme në çdo sekuencë në të gjitha nyjet, por bëni kujdes që funksioni nuk do të funksionojë në të gjitha versionet. Sigurisht, mund ta shkruani vetë, duke marrë si bazë kodin nga github ose duke e rregulluar vetë direkt në DBMS. Në të njëjtën kohë, fushat me tipin serialbigserial do të funksionojnë më saktë, por për t'i përdorur ato, ndoshta do t'ju duhet të shkruani përsëri kodin e procedurave dhe funksioneve tuaja. Ndoshta ndonjë njëri do t'i hyjë në punë funksioni monotonic_sequences.

Derisa të arrihet versioni 11.2 «Postgres Pro Enterprise», replikimi do të funksionojë vetëm nëse ka çelësa primarë unikë, mbani parasysh këtë gjatë zhvillimit.

Dëshiroj të përmend veçoritë e funksionimit të npgsql në zgjidhjet dhe në klaster, këto probleme nuk shfaqen në një nod, por në multimastrin janë të pranishme.
Në disa versione mund të hasni një gabim:

Detajet e Gabimit: Npgsql.PostgresException: 25001: komandë SET TRANSACTION ISOLATION LEVEL 
Përshkrimi: Ndodhi një përjashtim i papërpunuar gjatë ekzekutimit të kërkesës aktuale në web. Ju lutemi rishikoni gjurmën e stack për më shumë informacion rreth gabimit dhe vendit ku e mori origjinën në kod.

Çfarë mund të bëni? Thjesht mos përdorni disa versione. Duhet t'i dini ato, pasi gabimi shfaqet në më shumë se një version, dhe madje pas korrigjimit të tij të parë, mund të haseni përsëri me të më vonë. Duhet të jeni gati për këtë dhe është më mirë që të shfarosni të gjitha defektet e zbuluara së bashku me SGBD që prodhuesi i riparon, duke i mbuluar ato me teste regresioni të veçanta. Kështu, besoni, por kontrolloni.

Nëse aplikacioni përdor npgsql dhe kalon midis nodave duke menduar se ata janë krejt të njëjtë, mund të hasni gabimin:

EXCEPTION: Npgsql.PostgresException (0x80004005): XX000: kërkimi në cache dështoi për tipin ...

Ky gabim do të ndodhte për shkak se ndodhi lidhja

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

e tipave kompozitë në fillimin e aplikacionit për të gjitha lidhjet. Si rezultat, merrni një identifikues nga një nodë e caktuar, dhe kur kërkoni në një nodë tjetër, ai nuk përputhet, duke shkaktuar një gabim, dmth. do të jetë e pamundur të punoni në mënyrë transparente me tipa kompozit në klaster për disa aplikacione pa rishkrime të tjera në anën e aplikacionit (nëse mund ta bëni atë).

Siç e dimë të gjithë, vlerësimi i përgjithshëm i gjendjes së klasterit është shumë i rëndësishëm për diagnostikimin dhe veprimet operative gjatë punës, në produkt do të gjeni disa funksione që duhet t’ju lehtësojnë jetesën, por ndonjëherë ato mund të ofrojnë diçka krejtësisht ndryshe nga ajo që ju dhe madje edhe vetë prodhuesi e prisni prej tyre.

Për shembull:

select mtm.collect_cluster_info();
në çdo nodë jep të njëjtin 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")

Por pse në fushën LiveNodes është numri 2, ndonëse sipas përshkrimit të punës së multimastrit do të duhej të përputhej me numrin AllNodes=3? Përgjigjja: duhet të azhurnoni versionin e SGBD.

Dhe qëndroni të gatshëm për të grumbulluar log-un në të gjithë nyjat, sepse zakonisht do të shihni "gabimi ndodhet në log-un e nyjës tjetër". Shërbimi teknik do të pranojë të gjitha defektet e identifikuara nga ju dhe do të njoftojë për gatishmërinë e versionit tjetër, i cili ndonjëherë duhet të instalohet dhe me ndalim shërbimi, ndonjëherë edhe për një kohë të gjatë (varet nga volumi i bazës suaj të të dhënave). Nuk duhet të shpresoni se problemet e funksionimit do të shqetësojnë shumë ofruesin, dhe rifreskimi për defektet e identifikuara do të bëhet me pjesëmarrjen e përfaqësuesve të ofruesit, më saktë as që nuk duhet të tërhiqni përfaqësuesit e ofruesit, pasi në fund mund të merrni një klaster të çmontuar në prodhim pa backup.

Në fakt, në licencën për produktin komercial, prodhuesi e paralajmëron hapur: "Ky softuer ofrohet mbi parimin 'si është' dhe shoqëria me përgjegjësi të kufizuar 'Postgres Profesional' nuk është e detyruar të ofrojë mbështetje, përditësime, zgjerime ose ndryshime."

Nëse ende nuk keni kuptuar për cilin produkt bëhet fjalë, gjithë kjo përvojë është fituar si rezultat i një viti të funksionimit të bazës Postgres Pro Enterprise. Mund të nxirrni përfundimet vetë, kaq i papjekur sa që kërpudhat rriten.

Por kjo do të ishte vetëm një gjysmë e keqe, nëse do të përballeshin në kohë dhe në mënyrë efektive për të zgjidhur problemet e shfaqura.

Por kjo ndodhi pikërisht dhe nuk ndodh. Duket se prodhuesi nuk ka burime të mjaftueshme për të eliminuar shpejt defektet e zbuluara.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.

A keni përvojë në kalimin nga një DBMS të huaj/proprijetar në një të lirë/vendore?

21,3%Po, pozitive10
10,6%Po, negative5
21,3%Jo, nuk kemi ndryshuar DBMS10
4,3%Kemi ndërruar DBMS, por nuk ka ndryshuar asgjë2
42,6%Shikoni rezultatet20

Kanë votuar 47 përdorues. Përmbahen 12 përdorues.

Burimi: habr.com

"Pro, por jo klaster" ose si ne zëvendësuam DB-në

A keni përvojë në kalimin nga një DBMS të huaj/proprijetar në një të lirë/vendore?