„Pro, aga mitte klaster“ või kuidas me andmebaasi süsteeme impordime

(c) Yandex.Pildid

Kõik tegelased on fiktiivsed, kaubamärgid kuuluvad nende omanikele, igasugused kokkusattumised on juhuslikud ja üldiselt on see minu „subjektiivne hinnang, palun ärge lõhkege ust...”.

Meil on suur kogemus infotehnoloogiliste süsteemide tõlkimisel, kus andmebaasiloogika toimub ühest andmebaasihaldussüsteemist (SÜB) teise. Vastavalt valitsuse määrusele nr 1236 16.11.2016, on see sageli üleminek Oracle'ilt PostgreSQL'ile. Kuidas korraldada protsess võimalikult tõhusalt ja valutult - saame rääkida eraldi, täna räägime klastrite kasutamise eripäradest ja milliste probleemidega võib kokku puutuda kõrgelt koormatud jaotatud süsteemide ülesehitamisel, kus on keeruline loogika protseduurides ja funktsioonides.

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

Oletame, et olete juba kogu loogika plsql-ilt pgsql-ile üle viinud. Ja teie regressioonitestid on täiesti korras, nüüd mõtlete loomulikult skaaleerimisele, kuna koormustestid ei anna just rõõmu, eriti arvestades seda riistvara, mis algselt projekti eeldati, seoses selle teise andmebaasisüsteemiga. Oletame, et leidsite kohaliku tarnija "Postgres Professional" lahenduse multimasteri valikuga, mis on saadaval ainult "Postgres Pro Enterprise" maksimaalses versioonis ja mille kirjeldus tundub teie vajadustele väga sarnane. Esmase pinnapealse uurimise järel tuleb pähe mõte: "Oh! See on just see, mida me vajame, asemel RAC! Ja veel kodumaise tehnilise toe toetusega!"

Kuid ärge kiirustage rõõmustama, ning allpool selgitame, miks neid nüansse on oluline teada, kuna neid on keeruline ette näha, isegi hästi toote dokumentatsiooni lugedes. Hinnake, kas olete valmis tihti andmebaasi versioone otse tootmisplatsil uuendama, kuna mõned vead ei ole tootmisolukorraga ühilduvad ning neid on keeruline testimise käigus tuvastada.
Alustage tootja veebisaidilt jaotise "multimaster" – "piirang" tähelepaneliku lugemisega.

Esimene asi, millega võib kokku puutuda, on tehingute töö eripära nn "kahe faasi" režiimis, ja mõnikord ei paranda muud kui kogu teie protseduuri loogika ümberkirjutamine olukorda. 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;

Tekkib viga:

VIGA:  [MTM] Tehing MTM-1-2435-10-605783555137701 (10654) on katkenud sõlmes 3. Kontrollige selle logi, et näha veadetailsid.

Edasi võite pikka aega tegeleda dead lock'iga versioonides 10.5, 10.6 ja ainus tuntud pääste, mis tapab kogu klastrite mõtte – see on 'probleemsete' tabelite väljavõtmine klastrist, st teha make_table_local, kuid see vähemalt võimaldab töötada ja ei pane kõike kinni ootele, kuna tehingute fikseerimise ootused on ripakil. Või siis uuendada versioonile 11.2, mis peaks aitama, aga võib-olla ei aita, ärge unustage kontrollida.

Teatud versioonides võite saada veelgi mõistatuslikuma lukustuse:

username= mtm ja backend_type = background worker

Ja selles olukorras aitab teid ainult andmebaasi versiooni uuendamine 11.2-le ja kõrgemale, aga võib-olla ei aita ka.

Mõned indekseerimise operatsioonid võivad põhjustada vigu, kus selgelt märgitakse, et probleem on Bi-Directional Replicationis, logides MTM näete BDRi. Kas tõesti 2ndQuadrant? Ei… me ostsime multimasteri, see on lihtsalt kokkusattumus, see on tehnoloogia nimi.

[MTM] bdr ei toeta indeksi uuesti kontrollimist
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: saata ABORT teade tehingu (5467) kohaliku xid=4083 koordinaatorile 3
[MTM] Vastuvõetud ABORT_PREPARED loogiline sõnum tehingu MTM-3-25030-83-605694076627780 kohta sõlmelt 3
[MTM] Looge purustatud tehing MTM-3-25030-83-605694076627780 olekuga InProgress sõlmelt 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448 

Kui kasutate ajutisi tabeleid, vaatamata kinnitustele: „Multimasteri laiendus viib andmete replikatsioon läbi täielikult automaatsel viisil. Saate samaaegselt teostada kirjutavaid tehinguid ja töötada ajutiste tabelitega igas klastris olekus.”

Seega saate tegelikult lõpuks teada, et replikatsioon ei toimi kõigi tabelite osas, mida protseduuris kasutatakse, kui koodis on ajutise tabeli loomine, ja isegi multimaster.remote_functions kasutamine ei aita. Peate oma loogikat protseduuris värskendama või ümber kirjutama. Kui peate samaaegselt kasutama kahte laiendust multimaster ja pg_pathman Postgres Pro Enterprise v 10.5 piires, kontrollige, et sellise lihtsa näite korral:

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

Andmebaasi sõlmedes hakkavad ilmuma sellised veateated:

…
 PATHMAN_CONFIG ei sisalda suhet 23245
> find_in_dynamic_libpath: proovib "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: proovib "/opt//…/ent-10/lib/pg_pathman.so"
> DEPUR >:  find_in_dynamic_libpath: proovib "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: proovib "/opt/…/ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) nimi: ilma nimeeta; ploki olek: PREPARE; olek: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) nimi: ilma nimeeta; ploki olek: DEFAULT; olek: INPROGR, xid/subid/cid: 0/1/0
> lülitatud ajalool 1, kehtiv kuni 0/0
…
Tehing MTM-1-13604-7-612438856339841 (6919) on katkenud sõlmes 2. Kontrollige selle logi, et näha tõrke üksikasju.
...
[MTM] 28295: KAUGLÜLI algab tehingu katkestamine 7017
…
[MTM] 28295: saadab ABORT teate tehingu (6919) kohalik xid=7017 koordinaatorile 1

Mis need vead on, saate teada tehnilisest toetusest, te ei ole ju seda niisama ostnud.

Mida teha? Õige! Uuendada «Postgres Pro Enterprise» versioonile 11.2

Oluline on teada, et sequence, olles replitseerimise andmebaasi objekt, ei oma ühtset väärtust kogu klastris. Iga sequence on kohalik iga sõlme jaoks. Kui teil on unikaalsed piirangud kasutavad väljad ja kasutate sequence, siis saate teha ainult inkremendi, mis on võrdne sõlme numbriga klastris, kuna mida rohkem sõlmi klastris, seda kiiremini teie sequence kasvab. Jah, int saab kiiremini otsa kui olete planeerinud. Toote kasutamise lihtsustamiseks leiate isegi funktsiooni alter_sequences, mis teostab vajalikud inkremendid iga sequence'i jaoks kõigis sõlmedes, kuid olge valmis, et funktsioon ei pruugi kõikides versioonides toimida. Loomulikult saate selle ise kirjutada, võttes aluseks koodi GitHubist või muutes seda otse SÜB-d. Samuti töötavad serial ja bigserial tüüpi väljad täpsemalt, kuid selle kasutamiseks peate tõenäoliselt ümber kirjutama oma protseduuride ja funktsioonide koodi. Võib-olla on kasulik funktsioon monotonic_sequences.

Enne versiooni 11.2 „Postgres Pro Enterprise“ töötab replikatsioon ainult unikaalsete põhivõtmete olemasolu korral, pidage seda arendamisel meeles.

Eraldi tasub mainida npgsql töö eripära klastrilahendustes; need probleemid ei esine ühel noodil, kuid mitme sõlme puhul on need täiesti olemas.
Mõnedes versioonides võib esineda viga:

Exception Details: Npgsql.PostgresException: 25001: käsk SET TRANSACTION ISOLATION LEVEL 
Description: Käesoleva veebipäringu täitmisel tekkis käsitlemata erand. Palun vaadake virna jälge, et saada lisainfot vea ja selle koodi kohta, kust see pärineb. 

Mida saab teha? Lihtsalt ei tohi kasutada mõningaid versioone. Tuleb neid teada, kuna viga ei esine ainult ühes versioonis, ja isegi pärast selle esimest parandamist võite sellega hiljem uuesti kokku puutuda. Olge selleks valmis ja katke kõik tootja parandatud andmebaasi defektid eraldi regressioonitestidega. Usaldage, kuid kontrollige.

Kui rakendus kasutab npgsql-i ja vahetab sõlmede vahel, arvates, et need on kõik täiesti identsed, võib teil tekkida viga:

EXCEPTION: Npgsql.PostgresException (0x80004005): XX000: vahemälu otsing ebaõnnestus tüübile ...

See viga tekib seetõttu, et toimub sidumine

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

komposiit tüüpidel rakenduse käivitamise ajal kõikide ühenduste jaoks. Tulemuseks on identifikaator mõne ühe sõlme jaoks, ja kui päring tehakse teisel sõlmel, ei lange see kokku, mistõttu tagastatakse viga, st läbipaistvalt töötamine komposiit tüüpidega klastris mõnede rakenduste jaoks on võimatu lisal isti üleskirjutusteta rakenduse poolel (kui teil õnnestub seda teha).

Kuidas me kõik teame, on klastrite üldise seisundi hindamine väga oluline diagnostikaks ja operatiivseteks meetmeteks, et töötada, tootes leiate mõned funktsioonid, mis peaksid teie elu lihtsamaks tegema, kuid mõnikord võivad need anda täiesti erinevaid tulemusi, kui te ja isegi tootja sellelt ootab.

Näiteks:

select mtm.collect_cluster_info();
iga sõlmel annab sama tulemuse:
(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 LiveNodes väljal igal pool number 2, kuigi mitme meistritevahelise töö kirjeldus peaks vastama AllNodes=3 arvule? Vastus: DB versioon tuleb uuendada.

Ja olge valmis koguma logisid kõikidel sõlmedel, kuna tavaliselt näete teateid "viga on teise sõlme logis". Tehniline tugi aktsepteerib kõik teie avastatud vead ja teavitab teid järgmise versiooni valmidusest, mille paigaldamine võib mõnikord vajada teenuse peatamist või kesta kauem (sõltub teie andmebaasi mahust). Ei tasu loota, et kasutusprobleemid häirivad tootjat, ning värskendus seoses avastatud vigadega toimub koos tootja esindajate osavõtuta, täpsemalt ei tasu kaasata tootja esindajaid, kuna lõpuks võib teil olla tootmises lahku läinud klaster ilma varukoopiateta.

Tegelikult hoiatab tootja kommertsprodukte litsentsis ausalt: "See tarkvara on ette nähtud riigi „nagu on“ alusel ja OÜ „Postgres Professionaalne“ ei ole kohustatud pakkuma teenindust, tuge, värskendusi, laiendusi või muudatusi."

Kui te pole veel mõistnud, millist toodet silmas peetakse, siis kogu see kogemus on saadud Postgres Pro Enterprise andmebaasi aastase kasutamise tulemusena. Järelduse võite teha ise, selline niiskus, et seened kasvavad.

Aga see oleks veel pool häda, kui probleemid lahendataks õigeaegselt ja efektiivselt.

Aga seda just ei toimu. Tundub, et tootjal pole piisavalt ressursse, et avastatud vigu kiiresti kõrvaldada.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kas teil on kogemusi võõr- või autoriõigusega andmebaasi haldustarkvara üleminekuga vabale või kohalikele lahendustele?

• 21,3%Jah, positiivne10

• 10,6%Jah, negatiivne5

• 21,3%Ei, andmebaasi ei ole vahetatud10

• 4,3%Andmebaasi on vahetatud, kuid midagi ei ole muutunud2

• 42,6%Vaata tulemusi20

Hääletas 47 kasutajat. Erakuks jäi 12 kasutajat.

Allikas: habr.com