«Pro, aga mitte klaster» või kuidas me DBMS-i importasendame

(c) Yandex.Images

Kõik tegelased on väljamõeldud, kaubamärgid kuuluvad nende omanikele, kõik kokkusattumised on juhuslikud ja üldiselt, see on minu «subjektiivne hinnang, palun ärge püüdke ust murda…».

Meil on märkimisväärne kogemus teabehaldussüsteemide tõlkimisel andmebaasi loogikaga ühelt DBMS-ilt teisele. Seoses valitsuse määrusega nr 1236 16.11.2016, on see sageli tõlgendus Oracle'ist PostgreSQLi. Kuidas korraldada protsessi 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õrge koormusega jaotatud süsteemide ülesehitamisel keeruka loogikaga protseduurides ja funktsioonides.

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

Oletame, et olete juba kogu plsql loogika pgsql-ile üle viinud. Ja teie regressioonitestid on üsna head, nüüd mõtlemegi loomulikult skaleerimisele, kuna koormustestid ei paku teile suurt rõõmu, eriti selle riistvaraga, mis algselt projektis ette nähtud oli, selle teise DBMS-i jaoks. Oletame, et leiate kodumaise tarnija „Postgres Professional“ lahenduse, millel on valik nimega „multimaster“, mis on saadaval ainult „Postgres Pro Enterprise“ maksimaalses versioonis ning kirjelduse põhjal tundub see olevat just see, mida vajate, ja esimese pinnapealse uurimise käigus tuleb pähe mõte: „O! See on just nagu RAC! Ja veel kodumaise tehnilise toe võimalus!“

Aga ärge kiirustage rõõmustama, ja edasi kirjeldame, miks neid nüansse on oluline teada, kuna neid on raske ette näha, isegi pärast toote dokumentatsiooni põhjalikku lugemist. Hinnake, kas olete valmis sageli DBMS-i versioone tootmispaigas uuendama, kuna mõned vead ei ole tootmisprotsessiga ühilduvad ja neid on keeruline testi käigus avastada.
Alustage tootja veebisaidil jaotise „multimaster“ – „piirangud“ tähelepaneliku lugemisega.

Esimene asi, millega võib kokku puutuda, on tehingute töö eripära nn „kahefaasilises“ režiimis, ja vahel ei saa seda parandada muul viisil kui kogu teie protseduuri loogika ümber kirjutamisega. Siin on lihtne näide:

loo tabel test1 (id integer, id1 integer);
inserteeri test1 väärtused (1, 1),(1, 2);

MUUDA TABELIT test1, LISADES KONSTRUKTSIOONI test1_uk UNIKAALSE (id,id1) EDASI LÜKKAMISEGA ALGUSES EDASI LÜKKATUD;

uuenda test1
           seadke id1 =
               juhtum id1
                 kui 1
                 siis 2
                 muidu id1 - sign(2 - 1)
               lõpp
         kus id1 on vahemikus 1 kuni 2;

Tekkis viga:

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

Edasi võib pikka aega võidelda dead lock'iga versioonides 10.5, 10.6 ja ainus teadaolev pääseteede, mis tapab kogu klastrite mõtte – on „probleemsete“ tabelite eemaldamine klastrist, st teha make_table_local, kuid see vähemalt võimaldab töötada, mitte peatada kõike kõrgenenud tehingu fikseerimise ootustes. Võite ka proovida uuendada versioonile 11.2, mis peaks aitama, võib-olla ka mitte, ärge unustage kontrollida.

Mõnedes versioonides võite saada veelgi salapärasemat lukustust:

kasutajanimi = mtm ja backend_type = taustatöötaja

Ja sellises olukorras aitab teid vaid andmebaasi versiooni uuendamine 11.2-le ja kõrgemale, võib-olla ei aita.

Mõned operatsioonid indeksitega võivad põhjustada vigu, kus selgelt öeldakse, et probleem seisneb Bi-Directional Replication'is, MTM logides näete otseselt BDR. Tõesti 2ndQuadrant? Ei, me ostsime multimasteri, see on lihtsalt juhus, see tehnoloogia nimi.

[MTM] bdr ei toeta indeksi uuesti kontrollimist
[MTM] 12124: REMOTE algus katkestada tehing 4083
[MTM] 12124: saata KATKESTA teade tehingu (5467) kohaliku xid=4083 koordinaatorile 3
[MTM] Vastuvõtja KATKESTA_PAREM loogiline sõnum tehingu MTM-3-25030-83-605694076627780 jaoks sõlmest 3
[MTM] Katkestada ettevalmistatud tehing MTM-3-25030-83-605694076627780 olek InProgress sõlmest 3 originId=3
[MTM] MtmLogAbortLogicalMessage sõlm=3 tehing=MTM-3-25030-83-605694076627780 lsn=9fff448 

Kui kasutate ajutisi tabeleid, hoolimata kinnitustest: „Multimaster laiendus viib andmete replikatsiooni täiesti automaatselt läbi. Võite samaaegselt teostada kirjutavaid tehinguid ja töötada ajutiste tabelitega igas klastris oleku sõlmest.“

Siis tegelikult te saate, et replikatsioon ei toimi kõikidel tabelitel, mida protseduuris kasutatakse, kui koodis on ajutise tabeli loomine, ja isegi multimaster.remote_functions'i kasutamine ei aita, tuleb uuendada või ümber kirjutada oma loogika protseduuris. Kui peate samaaegselt kasutama kahte laiendit multimaster ja pg_pathman „Postgres Pro Enterprise“ v 10.5 raames, siis kontrollige, et selle lihtsa näite juures:

LOOBA ANDMEBAAS measurement (
    city_id         int mitte,
    logdate         kuupäev mitte,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

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

DB serverite logides hakkavad tekkima sellised vead:

…
 PATHMAN_CONFIG ei sisalda suhet 23245
> find_in_dynamic_libpath: proovin "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: proovin "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> DEBBUGING:  find_in_dynamic_libpath: proovin "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: proovin "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) nimi: nimetuks; blockState: PREPARE; seisund: INPROGR, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) nimi: nimetuks; blockState: DEFAULT; seisund: INPROGR, xid\/subid\/cid: 0\/1\/0
> vahetatud ajajoonele 1, kehtiv kuni 0\/0
…
Tehing MTM-1-13604-7-612438856339841 (6919) on katkestatud sõlmes 2. Kontrollige selle logi, et näha veateateid.
...
[MTM] 28295: KAUDA algab katkestus tehingu 7017
…
[MTM] 28295: saatma ABORT teate tehingu (6919) kohalik xid=7017 koordinaatorile 1

Mis need vead on, saate teada tehnilisest toelt, ei tasu ju te selle eest maksma hakata.

Mida teha? Õige! Uuendage "Postgres Pro Enterprise" versioonile 11.2

Erakordselt tuleb teada, et sequence, olles replikatsiooni andmebaasi objekt, ei oma üldiselt väärtust kogu klustis, iga sequence on kohaliku kehtivusega iga sõlme puhul ja kui teil on unikaalsete piirangutega väljad ja kasutate sequence, siis saate ainult teha inkrementi, mis on võrdne sõlme numbriga klustis, kuna klustis on sama palju sõlmi, nii kiiresti suureneb ka sequence ja int lõppeb kiiremini, kui ootate. Sequence'i lihtsustamiseks leiate tootes isegi funktsiooni alter_sequences, mis teeb vajalikud inkremendid iga sequence'i jaoks kõikidel sõlmedel, kuid olge valmis, et funktsioon ei pruugi töötada kõigis versioonides. Loomulikult on selle ise kirjutamine võimalik, võttes aluseks koodi githubist või muutes otse andmebaasis. Samuti töötavad väljad tüübiga serialbigserial täpsemalt, kuid nende kasutamiseks peate tõenäoliselt kirjutama oma protseduuride ja funktsioonide koodi ümber. Võib-olla on kellegi jaoks kasulik funktsioon monotonic_sequences.

Kuni versioonini 11.2 "Postgres Pro Enterprise" töötab replikatsioon ainult juhul, kui on olemas unikaalsed esimesed võtmed, pidage seda meeles arendamisel.

Eraldi tahaksin rääkida npgsql-i töös esinevatest eripäradest just klastrilahendustes, need probleemid ei esine üksikutes sõlmides, kuid mitme võrgu puhul on need täiesti olemas.
Mõnedes versioonides võidakse kokku puutuda veaga:

Exception Details: Npgsql.PostgresException: 25001: käsk SET TRANSACTION ISOLATION LEVEL 
Kirjeldus: Töötlemata erand tekkis praeguse veebipäringu käitlemise ajal. Palun vaadake teeki jälgi, et saada rohkem teavet vea ja selle alguskoha kohta koodis. 

Mida teha? Lihtsalt ärge kasutage mõningaid versioone. Tuleb neid teada, kuna viga ei esine vaid ühes versioonis ning isegi pärast selle esmast parandamist võite sellega hiljem kokku puutuda. Sellele tuleb samuti ette valmistuda ja parem on kõik tuvastatud andmebaasi vead, mille parendab tootja, katta eraldi regressioonitestidega. Usalda, aga kontrolli.

Kui rakendus kasutab npgsql-i ja vahetab sõlmede vahel, arvates, et need on absoluutselt ühesugused, siis võib teil tekkida viga:

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

See viga tekib seetõttu, et käivitatakse sidumine

(NpgsqlConnection.GlobalTypeMapper.MapComposite("some_composite_type");) 

koostüübid rakenduse käivitamisel kõikide ühenduste jaoks. Selle tulemusena saame identifikaatori ühest sõlmest ja teisel sõlmel päringut tehes ei ühti see, mistõttu tagastatakse viga, s.t. töötamine koostüüpidega klastris osade rakenduste jaoks on võimalik ainult lisarewrittenide poolse rakenduse küljest (kui suudate seda teha).

Kuna me kõik teame, et klastrite üldine seisundi hindamine on väga oluline diagnostika ja operatiivmeetmete jaoks, siis tootest leiate mõned funktsioonid, mis peaksid elu mugavamaks tegema, kuid mõnikord võivad need pakkuda täiesti eri tulemusi, kui te ja isegi tootja neid ootavad.

Näiteks:

select mtm.collect_cluster_info();
iga sõlmes 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 väljal LiveNodes on igal pool number 2, kuigi mitme võrgu töö kirjeldus peaks vastama numbrile AllNodes=3? Vastus: tuleb värskendada andmebaasi versiooni.

Ja olge valmis koguma logisid kõigis sõlmedes, kuna tavaliselt näete "viga on teise sõlme logis". Tehniline tugi aktsepteerib kõik teie tuvastatud vead ja teavitab teid järgmise versiooni valmidusest, mille installimine võib mõnikord nõuda teenuse peatamist, mõnikord ka pikema aja jooksul (olenevalt teie andmebaasi mahust). Ärge lootke, et tootja muretseb teie kasutusprobleemide pärast ning et värskendused tuvastatud vigade tõttu toimuvad tootja esindajate osalusel, täpsemalt ei ole vaja tootja esindajaid kaasata, kuna võite lõppkokkuvõttes saada tootmises lagunenud klastriga ilma varundamiseta.

Tegelikult hoiatab tootja kommertstoote litsentsis ausalt: "See tarkvara on antud 'nagu on' ja tuntud nimi OÜ 'Postgres Professionaalne' ei ole kohustatud pakkuma hooldust, tuge, uuendusi, laiendusi ega muudatusi."

Kui te pole veel aru saanud, millise toote kohta on jutt, siis kogu see kogemus on saadud Postgres Pro Enterprise'i aastase kasutamise tulemusena. Järelduse võite teha ise, niivõrd toores, et seente kasvamiseks on ideaalne.

Aga see oleks veel pool häda, kui probleeme lahendatakse õigeaegselt ja operatiivselt.

Kuid seda ei toimu. Tundub, et tootjal ei ole piisavalt ressursse, et kiiresti tuvastatud vigu kõrvaldada.

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

Kas teil on kogemusi välismaalt/omandiandjalt tasuta/rahvuslikule andmebaasile üleminekul?

• 21,3%Jah, positiivne10

• 10,6%Jah, negatiivne5

• 21,3%Ei, andmebaasi ei ole vahetatud10

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

• 42,6%Tulemustega tutvumiseks20

Hääletas 47 kasutajat. 12 kasutajat olid erapooletud.

Allikas: habr.com