🥇"Pro, por jo një klaster" ose si importuam DBMS

(ts) Yandex.Images

Të gjithë personazhet janë fiktivë, markat tregtare u përkasin pronarëve të tyre përkatës, çdo ngjashmëri është thjesht rastësi dhe, në përgjithësi, ky është "gjykimi im subjektiv i vlerave, ju lutem mos ma thyeni derën...".

Ne kemi përvojë të gjerë në migrimin e sistemeve të informacionit me logjikën e bazës së të dhënave nga një DBMS në tjetrin. Në përputhje me Rezolutën e Qeverisë Nr. 1236 të 16 nëntorit 2016, kjo shpesh përfshin migrimin nga Oracle në PostgreSQL. Mund të diskutojmë se si ta organizojmë këtë proces sa më efikas dhe pa dhimbje të jetë e mundur veçmas. Sot, do të diskutojmë specifikat e përdorimit të një klasteri dhe sfidat që mund të hasni kur ndërtoni sisteme të shpërndara me ngarkesë të lartë me logjikë komplekse në procedura dhe funksione.

Spoiler: po, cap, RAC dhe pg multimaster janë zgjidhje shumë të ndryshme.

Le të themi se e keni migruar tashmë të gjithë logjikën tuaj nga plsql në pgsql. Dhe testet tuaja të regresionit janë plotësisht në rregull. Tani po mendoni natyrshëm për shkallëzimin, pasi testimi i ngarkesës nuk është pikërisht një problem i madh, veçanërisht në harduerin e projektuar fillimisht për atë DBMS tjetër. Le të themi se keni gjetur një zgjidhje nga një shitës vendas, Postgres Professional, me një veçori të quajtur "multimaster", e cila është e disponueshme vetëm në versionin "përfundimtar", Postgres Pro Enterprise. Duke gjykuar nga përshkrimi, duket shumë e ngjashme me atë që ju nevojitet, dhe në shikim të parë, mund të mendoni, "Oh! Pikërisht gjëja në vend të RAC! Dhe me mbështetje teknike vendase gjithashtu!"

Por mos u entuziazmoni shumë. Do të shpjegojmë pse duhet të jeni të vetëdijshëm për këto nuanca, pasi ato janë të vështira për t'u parashikuar, edhe pasi të keni lexuar me kujdes dokumentacionin e produktit. Konsideroni nëse jeni të përgatitur të përditësoni shpesh versionet e DBMS direkt në vendin e prodhimit, pasi disa defekte nuk janë të pajtueshme me përdorimin e prodhimit dhe janë të vështira për t'u zbuluar gjatë testimit.
Filloni duke lexuar me kujdes seksionin "multimaster" - "kufizim" në faqen e internetit të prodhuesit.

Gjëja e parë që mund të hasni janë veçoritë e mënyrës se si funksionojnë transaksionet në të ashtuquajturin modalitet "dyfazor", dhe ndonjëherë nuk ka mënyrë për ta rregulluar këtë përveç rishkrimit të të gjithë logjikës së procedurës suaj. Ja një shembull i thjeshtë:

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;

Ndodh një gabim:

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

Mund të vazhdoni të përballeni me bllokime në versionet 10.5 dhe 10.6 për një kohë të gjatë, dhe e vetmja zgjidhje e njohur, e cila shkatërron plotësisht të gjithë qëllimin e një klasteri, është heqja e tabelave "problematike" nga klasteri, d.m.th., ekzekutimi i make_table_local. Por kjo të paktën do të lejojë që gjërat të funksionojnë, në vend që të rrëzojë gjithçka për shkak të pritjes së bllokuar që transaksionet të kryhen. Ose mund të përditësoni në versionin 11.2, gjë që duhet të ndihmojë, por ndoshta jo - sigurohuni që ta kontrolloni.

Në disa versione, mund të merrni një bravë edhe më misterioze:

username= mtm и backend_type = background worker

Dhe në këtë situatë, vetëm përditësimi i versionit DBMS në 11.2 ose më të lartë do t'ju ndihmojë, por mund të mos ndihmojë.

Disa operacione indeksimi mund të shkaktojnë gabime që tregojnë qartë se problemi është Replikimi Bi-Directional; do të shihni BDR-të në regjistrat MTM. A është 2ndQuadrant? Jo... ne blemë multimaster, është thjesht një rastësi; është emri i teknologjisë.

[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

Nëse përdorni tabela të përkohshme, pavarësisht garancive: "Shtesa multimaster kryen replikimin e të dhënave plotësisht automatikisht. Mund të ekzekutoni njëkohësisht transaksione shkrimi dhe të punoni me tabela të përkohshme në çdo nyje klasteri."

Në fakt, do të përfundoni me replikim që nuk funksionon në të gjitha tabelat e përdorura në procedurë nëse kodi krijon një tabelë të përkohshme, dhe madje edhe përdorimi i multimaster.remote_functions nuk do të ndihmojë. Do t'ju duhet të azhurnoni ose rishkruani logjikën tuaj në procedurë. Nëse duhet të përdorni njëkohësisht të dyja shtesat multimaster dhe pg_pathman në Postgres Pro Enterprise v10.5, kontrolloni nëse ky shembull i thjeshtë funksionon:

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);

Gabimet e mëposhtme fillojnë të shfaqen në regjistrat në nyjet e 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

Ju mund të zbuloni se cilat janë këto gabime duke kontaktuar mbështetjen teknike; nuk ishte kot që e keni blerë.

Çfarë duhet të bëj? Pikërisht! Përditësojeni në Postgres Pro Enterprise (v11.2).

Është e rëndësishme të theksohet se një sekuencë, duke qenë një objekt i bazës së të dhënave i replikuar, nuk ka një vlerë të qëndrueshme në të gjithë klasterin. Çdo sekuencë është lokale për secilën nyje. Nëse keni fusha me kufizime unike që përdorin sekuencë, mund të rriteni vetëm me numrin e nyjes së klasterit. Kjo do të thotë që sa më shumë nyje në klaster, aq më shpejt do të rritet sekuenca juaj, dhe si sekuenca ashtu edhe int do të mbarojnë më shpejt se sa pritej. Për të thjeshtuar punën me sekuencat, produkti përfshin edhe një funksion alter_sequences, i cili do të kryejë rritjet e kërkuara për secilën sekuencë në të gjitha nyjet. Megjithatë, kini kujdes se ky funksion nuk do të funksionojë në të gjitha versionet. Sigurisht, mund ta shkruani vetë, duke përdorur kodin nga GitHub ose duke e modifikuar atë direkt në DBMS. Fushat Serialbigserial do të funksionojnë më saktë, por përdorimi i tyre ka të ngjarë të kërkojë rishkrimin e procedurave dhe funksioneve tuaja. Ndoshta funksioni monotonic_sequences do të jetë i dobishëm për dikë.

Përpara Postgres Pro Enterprise 11.2, replikimi do të funksiononte vetëm nëse ka çelësa primarë unikë, prandaj mbani mend këtë gjatë dizajnimit.

Do të doja të përmendja edhe specifikat e funksionimit të npgsql në një zgjidhje të grupuar. Këto probleme nuk lindin në një nyje të vetme, por janë mjaft të pranishme në një zgjidhje me shumë mastera.
Në disa versione mund të hasni një gabim:

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.

Çfarë mund të bëhet? Thjesht shmangni përdorimin e versioneve të caktuara. Është e rëndësishme t'i njihni ato, pasi gabimi shfaqet në më shumë se një version, dhe edhe pas rregullimit fillestar, mund ta hasni më vonë. Duhet të jeni të përgatitur edhe për këtë, dhe është më mirë të mbuloni të gjitha defektet e identifikuara të DBMS që shitësi rregullon me teste të veçanta regresioni. Besoni, por verifikoni, si të thuash.

Nëse aplikacioni juaj përdor npgsql dhe kalon midis nyjeve, duke menduar se janë të gjitha njësoj, mund të hasni gabimin e mëposhtëm:

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

Ky gabim do të ndodhë sepse lidhja është në vazhdim.

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

Llojet e përbëra përdoren në nisjen e aplikacionit për të gjitha lidhjet. Si rezultat, një identifikues i marrë nga një nyje nuk përputhet kur kërkohet në një nyje tjetër, duke rezultuar në një gabim. Kjo do të thotë që puna transparente me llojet e përbëra në një klaster do të jetë e pamundur për disa aplikacione pa rishkrime shtesë nga ana e aplikacionit (nëse mund ta bëni këtë).

Siç e dimë të gjithë, një vlerësim i përgjithshëm i gjendjes së klasterit është thelbësor për diagnostikimin dhe ndërhyrjet operative. Produkti përfshin disa veçori që duhet ta bëjnë jetën tuaj më të lehtë, por ndonjëherë ato mund të mos ofrojnë atë që ju, apo edhe prodhuesi, prisni.

Për shembull:

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")

Por pse fusha LiveNodes tregon gjithmonë numrin 2, edhe pse përshkrimi i multimaster thotë AllNodes = 3? Përgjigje: Ju duhet të përditësoni versionin tuaj të DBMS.

Jini të përgatitur të mbledhni regjistra për të gjitha nyjet, pasi zakonisht do të shihni "gabim të vendosur në regjistrin e një nyjeje tjetër". Mbështetja teknike do të pranojë të gjitha defektet që keni identifikuar dhe do t'ju njoftojë kur versioni tjetër të jetë gati, gjë që ndonjëherë do të kërkojë kohë ndërprerjeje, ndonjëherë edhe për një kohë të gjatë (në varësi të madhësisë së DBMS-së tuaj). Mos prisni që problemet operative të jenë shumë shqetësuese për shitësin, dhe përditësimi për shkak të defekteve të zbuluara do të kryhet me përfshirjen e përfaqësuesve të shitësit. Në fakt, nuk duhet të përfshini as përfaqësuesit e shitësve, pasi mund të përfundoni me një grumbull të çmontuar në prodhim pa kopje rezervë.

Në fakt, në licencën e produktit komercial, prodhuesi paralajmëron qartë: "Ky softuer ofrohet 'siç është' dhe Postgres Professional Limited Liability Company nuk ka asnjë detyrim të ofrojë mirëmbajtje, mbështetje, përditësime, zgjerime ose modifikime."

Nëse nuk e keni menduar ende për çfarë produkti po flasim, e gjithë kjo përvojë është fituar nga një vit përdorimi i një baze të dhënash Postgres Pro Enterprise. Mund të nxirrni vetë përfundimin: është aq e lagësht sa po mbin si kërpudha.

Por kjo nuk do të ishte aq keq nëse do të kryhej në kohën e duhur dhe çdo problem që do të lindte do të zgjidhej shpejt.

Por kjo është pikërisht ajo që nuk po ndodh. Me sa duket, prodhuesit i mungojnë burimet për të rregulluar menjëherë çdo defekt që zbulohet.

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