(c) Yandex.Images
Të gjitha karakteret janë imagjinare, markat tregtare janë pronë e pronarëve të tyre, çdo ngjashmëri është rastësore dhe në përgjithësi, ky është një "vlerësim subjektiv nga unë, ju lutem mos e prishni derën...".
Ne kemi një përvojë të konsiderueshme në përkthimin e sistemeve informative me logjikë në DB nga një SGBD në një tjetër. Në përputhje me vendimin e qeverisë nr. 1236, datë 16.11.2016, shpesh herë kjo është një përkthim nga Oracle në PostgreSQL. Si ta organizoni procesin maksimalisht efikas dhe pa dhimbje — mund të flasim veçmas, sot do të flasim për veçoritë e përdorimit të klastrit dhe me çfarë problemeve mund të përballeni gjatë ndërtimit të sistemeve të shpërndara me ngarkesë të lartë dhe logjikë të komplikuar në procedurat dhe funksionet.
Spoiler – po, keqpërdorime, RAC dhe pg multimaster janë me të vërtetë zgjidhje shumë të ndryshme.
Le të supozojmë se keni transferuar tashmë të gjithë logjikën nga plsql në pgsql. Testet tuaja regresive janë mjaft në rregull, tani sigurisht po mendoni për shkallëzimin, pasi testet e ngarkesës nuk ju kenaqin shumë, sidomos me atë harduer që ishte parashikuar në projekt fillimisht, për atë SGBD tjetër. Le të themi se keni gjetur një zgjidhje nga një ofrues vendas "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 – kjo duket shumë si ajo që ju nevojitet, dhe gjatë një studimi të parë të sipërfaqshëm do t'ju vijë në mendje mendimi: "O! Në vend të RAC kjo është ideja perfekte! Edhe me mbështetje teknike në vend!".
Por mos u nxinoni për t'u gëzuar, dhe më tej do të përshkruajmë pse këto nuanca duhet të dihen, pasi është e vështirë t'i parashikoni, edhe pse keni lexuar mirë dokumentacionin e produktit. Vlerësoni nëse do të jeni të gatshëm të përditësoni shpesh versionet e SGBD-së direkt në terren, pasi disa defekte nuk janë të përshtatshme për përdorim industrial dhe janë të vështira për tu zbuluar gjatë testimit.
Filloni me një lexim të kujdesshëm të seksionit "multimaster" — "kufizimi" në faqen e prodhuesit.
E para, me të cilën mund të përballeni, janë veçoritë e punës së transaksioneve, në atë që quhet "retransaksion dy fazor", dhe ndonjëherë, përveçse duke e shkruar të gjithë logjikën e procedurës suaj, nuk ka asnjë mënyrë tjetër për ta korrigjuar. Ja një shembull i thjeshtë:
krijo tabelën test1 (id integer, id1 integer);
shkruaj në test1 vlera (1, 1),(1, 2);
MODIFIKO TABELËN test1 SHTO KUSHTIN test1_uk UNIKE (id,id1) I PËRMBYLLUR fillimisht I PËRMBYLLUR;
aktualizo test1
vendos id1 =
rast id1
kur 1
atëherë 2
përndryshe id1 - shenje(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 tij për të parë detajet e gabimit.Mund të mbani një luftë të gjatë me dead lock në versionet 10.5, 10.6 dhe shpresa e vetme e njohur që shkatërron të gjithë kuptimin e klasterit – është të hiqni nga klasteri tabelat "problematike", dmth. të bëni make_table_local, por kjo të paktën do t'ju lejojë të punoni, dhe nuk do të bllokojë gjithçka për shkak të pritjeve të ngelura për konfirmimin e transaksioneve. Ose mund të tregoni përmirësimin në versionin 11.2, i cili duhet të ndihmojë, ndoshta edhe jo, mos harroni të kontrolloni.
Në disa versione mund të merrni një bllokim akoma më enigmatik:
username= mtm dhe backend_type = background workerDhe në këtë situatë, vetëm përmirësimi i versionit të DBMS në 11.2 dhe më lartë do t'ju ndihmojë, ose ndoshta jo.
Disa operacione me indekset mund të sjellin gabime, ku qartë shpjegohet se problemi është konkretisht në Bi-Directional Replication, në regjistrat MTM do të shihni drejtpërdrejt BDR. A është 2ndQuadrant? Jo… ne thjesht blejmë multimaster, është një rastësi, ky është emri i teknologjisë.
[MTM] bdr nuk mbështet rivlerësimet e indekseve
[MTM] 12124: REMOTE fillo të anuloj transaksionin 4083
[MTM] 12124: dërgo njoftimin ABORT për transaksionin (5467) xid lokal=4083 te koordinatori 3
[MTM] Merrni njoftimin ABORT_PREPARED logjik për transaksionin MTM-3-25030-83-605694076627780 nga nyja 3
[MTM] Anulo transaksionin e përgatitur MTM-3-25030-83-605694076627780 status InProgress nga nyja 3 originId=3
[MTM] MtmLogAbortLogicalMessage nyja=3 transaksioni=MTM-3-25030-83-605694076627780 lsn=9fff448 Nëse përdorni tabela temporale, pavarësisht premtimeve: "Zgjerimi multimaster kryen replikimin e të dhënave në mënyrë plotësisht automatike. Ju mund të kryeni transaksione shkrimi dhe të punoni me tabela temporale në çdo nyje të klasterit."
Atëherë në fakt do të merrni se replikimi nuk funksionon për të gjitha tabelat e përdorura në procedurë, nëse në kod ekziston krijimi i një tabele temporale, dhe madje përdorimi i multimaster.remote_functions nuk do të ndihmojë, do t'ju duhet të përmirësoni ose të rishkruani 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, atëherë kontrolloni që për këtë shembull të thjeshtë:
KREO TABELËN measurement (
city_id int jo s'ka null,
logdate date jo s'ka null,
peaktemp int,
unitsales int
) PARTITION BY RANGE (logdate);
KREO TABELËN measurement_y2019m06 PARTITION OF measurement PËR VLERAT NGA ('2019-06-01') DERi ('2019-07-01');
insert into measurement vlerat (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement vlerat (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement vlerat (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement vlerat (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);Në logjet e nyjave të DBMS fillojnë të shfaqen këto gabime:
…
PATHMAN_CONFIG nuk përmban marrëdhënie 23245
> find_in_dynamic_libpath: po provon "/opt/.../ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: po provon "/opt//.../ent-10/lib/pg_pathman.so"
> DEBBUGING: find_in_dynamic_libpath: po provon "/opt/.../ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: po provon "/opt/.../ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) emri: pa emër; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) emri: pa emër; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
> kaloi në timeline 1 i vlefshëm deri në 0/0
…
Transaksioni MTM-1-13604-7-612438856339841 (6919) është abortuar në nyjën 2. Kontrolloni logun e saj për të parë detajet e gabimit.
...
[MTM] 28295: REMOTE filloni abortin e transaksionit 7017
…
[MTM] 28295: dërgoni njoftimin ABORT për transaksionin (6919) xid lokal=7017 në koordinatin 1
Çfarë janë këto gabime, mund ta zbuloni në mbështetje teknike, nuk e keni blerë pa arsye.
Çfarë të bëni? E saktë! Përditësoni në «Postgres Pro Enterprise» deri në v 11.2
Veçmas duhet të dini se sekuencat, që janë objekte të DB të replikueshme, nuk kanë një vlerë përfundimtare në të gjithë klasterin, çdo sekuencë është lokale për çdo nyje dhe nëse keni fusha me kufizime unike që përdorin sekuencë, ju mund të bëni vetëm një inkrement ekuivalente me numrin e nyjës në klaster, sepse sa më shumë nyje që keni në klaster, aq më shpejt do të rritet sekuenca, dhe int përfundon më shpejt se sa e keni planifikuar. Për të lehtësuar punën me sekuencat, në produkt do të gjeni edhe funksionin alter_sequences, i cili do të bëjë inkrementet e nevojshme për çdo sekuencë në të gjitha nyjat, por bëhuni gati që funksioni nuk do të funksionojë në të gjitha versionet. Sigurisht, mund ta shkruani vetë, duke e mbështetur në kodin nga github ose duke e ndryshuar atë direkt në DBMS. Në këtë rast, fushat me tipin serial/bigserial do të funksionojnë më saktë, por për t'i përdorur ato, shumë mundësi është që duhet të ridizajnoni kodin e procedurave dhe funksioneve tuaja. Mbase për dikë do të jetë e dobishme funksioni monotonic_sequences.
Derisa të arrijë versionin 11.2 «Postgres Pro Enterprise», replikimi do të funksionojë vetëm nëse ekzistojnë çelësa unikë primarë, kini parasysh këtë gjatë zhvillimit.
Kjo është një mundësi e shkëlqyer për të theksuar veçoritë e punës së npgsql në zgjidhjet e klasterit; këto probleme nuk shfaqen në një nod, por janë të pranishme në multi-master.
Në disa versione, mund të përballeni me një gabim:
Detajet e përjashtimit: Npgsql.PostgresException: 25001: komanda 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 në lidhje me gabimin dhe se ku ka origjinën në kod. Çfarë mund të bëni? Thjesht mos përdorni disa versione. Duhet t'i njihni ato, pasi gabimi shfaqet në më shumë se një version, dhe madje pas korrigjimit të parë, mund të përballeni përsëri me të më vonë. Duhet të jeni gati për këtë dhe është më mirë që të gjitha defektet e zbuluara të DBMS-së, të cilat korrigjon prodhuesi, t'i mbuloni me teste regresioni të veçanta. Siç thonë, besoni, por kontrolloni.
Nëse aplikacioni përdor npgsql dhe kalon midis node-ve duke menduar se ato janë krejtësisht të njëjta, mund të keni një gabim:
PËRJASHTIM: Npgsql.PostgresException (0x80004005): XX000: kërkimi i cache dështoi për llojin ...Ky gabim ndodh për shkak se po kryhet lidhja
(NpgsqlConnection.GlobalTypeMapper.MapComposite("some_composite_type");) e llojeve composite në fillim të aplikacionit për të gjitha lidhjet. Si rezultat, marrim një identifikues nga një nodë e caktuar, dhe kur bëhet kërkesa në një nod tjetër, ai nuk përputhet, duke sjellë kështu gabimin; kështu që të punosh transparencë me llojet composite në një klaster për disa aplikacione do të jetë e pamundur pa rishtypje të mëtejshme në anën e aplikacionit (nëse arritni ta bëni këtë).
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 masat operative gjatë punës; në produkt do të gjeni disa funksione që duhet t'ju lehtësojnë jetën, por ndonjëherë ato mund të ofrojnë krejtësisht diçka ndryshe nga ajo që prisni ju dhe madje edhe prodhuesi vetë.
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 gjithandej qëndron numri 2, kur sipas përshkrimit të funksionimit të multi-master duhet të përputhet me numrin AllNodes=3? Përgjigja: duhet të përditësoni versionin e DBMS.
Dhe jini të gatshëm për të mbledhur log-e nga të gjitha nodet, pasi zakonisht do të shihni "gabim në log-un e nodit tjetër". Supporti teknik do të pranojë të gjitha defektet që ju identifikoni dhe do t'ju njoftojë për gatishmërinë e versionit tjetër, i cili ndonjëherë duhet të instalohet duke ndaluar shërbimin, ndonjëherë edhe për një kohë të gjatë (varet nga volumi i DB tuaj). Mos pritni që problemet e operimit do të shqetësojnë shumë ofruesin dhe që përditësimi për shkak të defekteve të identifikuara do të realizohet me pjesëmarrjen e përfaqësuesve të ofruesit, përkundrazi nuk duhet përfshirë përfaqësuesit e ofruesit, pasi në përfundim mund të përfundoni me një klaster të ndarë në prodhim pa backup.
Saktësisht, në licencën e produktit komercial prodhuesi e paralajmëron sinqerisht: "Ky software ofrohet mbi bazën e parimit 'ashtu siç është' dhe shoqëria me përgjegjësi të limituar 'Postgres Profesional' nuk ka obligim për të ofruar mbështetje, përditësime, zgjerime ose ndryshime."
Nëse ende nuk e keni kuptuar për cilin produkt bëhet fjalë, e gjithë kjo përvojë është marrë nga një vit përdorimi të bazës Postgres Pro Enterprise. Mund të nxirrni vetë përfundimin, është aq e papërgatitur se kërpudhat po rriten.
Por kjo do të ishte vetëm një pjesë e problemit, nëse do të ishin eliminuar në kohë dhe në mënyrë operative problemet që shfaqen.
Por ky është pikërishtthemi që nuk ndodh. Duket se burimet e prodhuesit nuk mjaftojnë për të eliminuar shpejt defektet e identifikuara.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutemi.
A keni përvojë në kalimin nga një DB të huaj/proprjtar në një DB të lirë/vendore?
21,3%Po, pozitive10
10,6%Po, negative5
21,3%Jo, nuk e kemi ndryshuar DB-në10
4,3%E kemi ndryshuar DB-në, por nuk ndryshoi asgjë2
42,6%Shikoni rezultatet20
Janë votuar nga 47 përdorues. Abstenuan 12 përdorues.
Burimi: habr.com
