"Pro, kuid mitte klaster" või kuidas asendasime imporditud DBMS-i

(ts) Yandex.Images

Kõik tegelased on fiktiivsed, kaubamärgid kuuluvad nende omanikele, kõik sarnasused on juhuslikud ja üldiselt on see minu "subjektiivne väärtushinnang, palun ärge ust murdke...".

Meil on märkimisväärne kogemus loogikaga infosüsteemide ülekandmisel andmebaasi ühest DBMS-ist teise. Valitsuse 1236. novembri 16.11.2016. aasta määruse nr XNUMX kontekstis on sageli tegemist Oracle'i üleminekuga Postgresqlile. Eraldi saame rääkida, kuidas protsessi võimalikult tõhusalt ja valutult korraldada, täna räägime klastri kasutamise võimalustest ja sellest, millised probleemid võivad tekkida protsessides ja funktsioonides keeruka loogikaga kõrgelt koormatud hajutatud süsteemide ehitamisel.

Spoiler – jah, cap, RAC ja pg multimaster on väga erinevad lahendused.

Oletame, et olete juba kogu loogika plsql-ilt pgsqlile üle kandnud. Ja teie regressioonitestid on päris korras, nüüd muidugi mõtlete skaleerimise peale, sest... koormustestid ei rõõmusta teid eriti selle riistvara puhul, mis oli algselt projekti kaasatud, selle väga erineva DBMS-i jaoks. Oletame, et leidsite kodumaise müüja "Postgres Professional" lahenduse valikuga "multimaster", mis on saadaval ainult "Postgres Pro Enterprise" "maksimaalses" versioonis ja kirjelduse järgi on see väga sarnane vajad ja esimese pealiskaudse uurimisega tuleb pähe mõte: “Oh! RAC-i asemel see ongi! Ja isegi tehnilise torustikuga meie kodumaal!”

Kuid ärge kiirustage rõõmustama ja edasi kirjeldame, miks peate neid nüansse teadma, sest ... neid on raske ennustada isegi pärast toote dokumentatsiooni põhjalikku lugemist. Hinnake, kas olete valmis DBMS-i versioone sageli värskendama otse tootmiskohas, kuna Mõned defektid ei sobi tööstuslikuks kasutamiseks ja neid on testimise käigus raske tuvastada.
Alustuseks lugege hoolikalt läbi tootja veebisaidi jaotis "multimaster" - "piirangud".

Esimese asjana võid kohata tehingute toimimise iseärasusi nn. "Kahefaasiline" režiim ja mõnikord pole seda võimalik parandada, välja arvatud kogu protseduuri loogika ümberkirjutamine. Siin on lihtne näide:

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;

Ilmub tõrge:

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

Siis saab versioonides 10.5, 10.6 pikalt võidelda surnud lukuga ja ainus teadaolev lahendus, mis tapab kogu klastri olemuse, on eemaldada klastrist “probleemide” tabelid, s.t. tehke make_table_local, kuid see võimaldab vähemalt sellel töötada ja ei pane kõike ootele, kuna tehingute kinnitamise ooteaeg on ootel. Noh, või installige värskendus versioonile 11.2, mis peaks aitama, kuid võib-olla mitte, ärge unustage kontrollida.

Mõnes versioonis saate veelgi salapärasema luku:

username= mtm и backend_type = background worker

Ja selles olukorras aitab teid ainult DBMS-i versiooni värskendamine versioonile 11.2 või uuemale või võib-olla see ei aita.

Mõned toimingud indeksitega võivad põhjustada vigu, mis näitavad selgelt, et probleem on kahesuunalises replikatsioonis; BDR-i näete otse MTM-i logides. Kas see on tõesti 2. kvadrant? Ei... ostsime multimasteri, see on lihtsalt juhus, see on tehnoloogia nimi.

[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 

Kui kasutate ajutisi tabeleid, hoolimata kinnitustest: "Multimasteri laiendus teostab andmete replikatsiooni täiesti automaatselt. Saate üheaegselt teha kirjutamistoiminguid ja töötada ajutiste tabelitega klastri mis tahes sõlmes.

Siis saate tegelikult aru, et replikatsioon ei tööta kõigis protseduuris kasutatud tabelites, kui kood sisaldab ajutise tabeli loomist ja isegi multimaster.remote_functions kasutamine ei aita, peate oma loogikat värskendama või ümber kirjutama. protseduur. Kui peate versioonis Postgres Pro Enterprise v 10.5 kasutama korraga kahte laiendust multimaster ja pg_pathman, siis kontrollige seda selle lihtsa näitega:

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

DBMS-i sõlmede logides hakkavad ilmnema järgmised vead:

…
 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

Mis need vead on, saate teada tehnilisest toest, pole asjata, et ostsite selle.

Mida teha? Õige! Minge üle versioonile "Postgres Pro Enterprise" v 11.2

Eraldi peate teadma, et jada, mis on paljundatud andmebaasi objekt, ei oma kogu klastris lõppväärtust, iga jada on iga sõlme jaoks lokaalne ja kui teil on kordumatute piirangutega väljad ja kasutusjada, siis saate teha ainult juurdekasvu, mis on samaväärne klastri sõlme numbriga, sest Klastris võimalikult palju sõlme, järjestus ja int kasvavad oodatust kiiremini. Tootes järjestusega töötamise lihtsustamiseks leiate isegi funktsiooni alter_sequences, mis teeb kõigis sõlmedes iga jada jaoks vajalikud sammud, kuid olge valmis, et funktsioon ei tööta kõigis versioonides. Loomulikult saate selle ise kirjutada, võttes aluseks githubi koodi või parandades seda ise otse DBMS-is. Sel juhul töötavad serialbigserial tüüpi väljad korrektsemalt, kuid nende kasutamiseks peate tõenäoliselt oma protseduuride ja funktsioonide koodi ümber kirjutama. Võib-olla on kellelegi kasulik funktsioon monotonic_sequences.

Enne Postgres Pro Enterprise'i versiooni 11.2 töötab replikatsioon ainult unikaalsete esmaste võtmete olemasolul, võtke seda arendamisel arvesse.

Eraldi tahaksin mainida npgsql-i toimimise iseärasusi kobarlahenduses, need probleemid ei teki ühes sõlmes, vaid on üsna olemas multimasteris.
Mõnes versioonis võib ilmneda tõrge:

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. 

Mida saaks teha? Peate lihtsalt mitte kasutama mõnda versiooni. Sa pead neid teadma, sest... Viga ilmneb rohkem kui ühes versioonis ja isegi pärast selle esimest parandamist võite sellega hiljem kokku puutuda. Samuti tuleb selleks valmis olla ja parem on katta kõik tuvastatud DBMS-i vead, mida tootja parandab eraldi regressioonitestidega. Nii-öelda usalda, aga kontrolli.

Kui rakendus kasutab npgsql-i ja lülitub sõlmede vahel, arvates, et need on kõik ühesugused, võite saada veateate:

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

See tõrge ilmneb, kuna sidumine on pooleli

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

komposiittüübid rakenduse käivitamisel kõigi ühenduste jaoks. Selle tulemusena saame ühest sõlmest identifikaatori ja teises sõlmes pärides see ei ühti, mille tulemusena tagastatakse viga, s.t. Komposiittüüpidega klastris läbipaistev töötamine ei ole mõne rakenduse puhul võimalik ilma täiendava rakendusepoolse ümberkirjutamiseta (kui see õnnestub).

Nagu me kõik teame, on klastri seisukorra üldine hinnang töö ajal diagnostika ja operatiivmeetmete jaoks väga oluline, tootest leiate mõned funktsioonid, mis peaksid teie elu lihtsamaks tegema, kuid mõnikord võivad need anda midagi täiesti erinevat teie ja isegi tootja ise ootate neilt seda, mida te ootate.

Näiteks:

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

Aga miks on väljal LiveNodes kõikjal arv 2, kuigi multimasteri töö kirjelduse järgi peaks see vastama numbrile AllNodes=3? Vastus: peate värskendama DBMS-i versiooni.

Ja olge valmis koguma logisid kõigi sõlmede kohta, sest... tavaliselt näete "viga on teise sõlme logis". Tehniline tugi aktsepteerib kõiki tuvastatud defekte ja teavitab teid, et järgmine versioon on valmis, mis tuleb mõnikord installida, kui teenus on peatatud, mõnikord aga pikemaks ajaks (olenevalt teie DBMS-i suurusest). Ei tasu loota, et tööprobleemid müüjat oluliselt häirivad ning tuvastatud defektide tõttu uuendamine toimub müüja esindajate osalusel, õigemini ei pea te isegi müüja esindajaid kaasama, kuna lõpuks võite tootmises ilma varundamiseta saada lahti võetud klastri.

Tegelikult hoiatab tootja kaubandusliku toote litsentsis ausalt: "Seda tarkvara pakutakse "sellisena" ja Postgres Professional Limited Liability Company ei ole kohustatud pakkuma hooldust, tuge, värskendusi, laiendusi ega muudatusi.

Kui te pole veel arvanud, millisest tootest me räägime, siis kogu see kogemus on saadud Postgres Pro Enterprise andmebaasi aastapikkuse toimimise tulemusena. Võite teha oma järelduse, see on nii niiske, et seened kasvavad.

Kuid see poleks nii hull, kui seda tehtaks õigeaegselt ja tekkivad probleemid kiiresti kõrvaldataks.

Kuid just seda ei juhtu. Ilmselt pole tootjal piisavalt ressursse tuvastatud vigade kiireks kõrvaldamiseks.

Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.

Kas teil on kogemusi välismaise/varalise DBMS-i vahetamisel vabale/kodumaisele DBMS-ile?

• 21,3%Jah, positiivne 10

• 10,6%Jah, negatiivne5

• 21,3%Ei, DBMS-i ei muudetud10

• 4,3%DBMS-i muudeti, kuid midagi ei muutunud2

• 42,6%Vaata tulemusi20

47 kasutajat hääletas. 12 kasutajat jäi erapooletuks.

Allikas: www.habr.com