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

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

"Pro, por jo klaster" ose si ne zëvendësuam DB-në
(c) Yandex.Images

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

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster