„Pro, en ekki þyrping“ eða hvernig við skiptum um innflutt DBMS

(ts) Yandex.Myndir

Allar persónur eru uppdiktaðar, vörumerki tilheyra eigendum þeirra, hvers kyns líkindi eru tilviljunarkennd og almennt séð er þetta „huglægt gildismat mitt, vinsamlegast ekki brjóta upp hurðina...“.

Við höfum töluverða reynslu af því að flytja upplýsingakerfi með rökfræði inn í gagnagrunn frá einu DBMS til annars. Í tengslum við stjórnarskipun nr. 1236 frá 16.11.2016. nóvember XNUMX, er þetta oft flutningur frá Oracle til Postgresql. Við getum sagt þér sérstaklega hvernig á að skipuleggja ferlið eins skilvirkt og sársaukalaust og mögulegt er; í dag munum við tala um eiginleika þess að nota klasa og hvaða vandamál er hægt að lenda í þegar byggt er mjög hlaðin dreifð kerfi með flóknum rökfræði í verklagsreglum og aðgerðum.

Spoiler – já, cap, RAC og pg multimaster eru mjög ólíkar lausnir.

Segjum að þú hafir þegar flutt alla rökfræðina frá plsql til pgsql. Og aðhvarfsprófin þín eru alveg í lagi, nú ertu að sjálfsögðu að hugsa um skala, því... hleðslupróf gera þig ekki mjög ánægðan, sérstaklega á vélbúnaðinum sem var upphaflega innifalinn í verkefninu, fyrir þetta mjög mismunandi DBMS. Segjum að þú hafir fundið lausn frá innlenda söluaðilanum "Postgres Professional" með valmöguleika sem kallast "multimaster", sem er aðeins fáanlegur í "hámarks" útgáfu af "Postgres Pro Enterprise" og samkvæmt lýsingunni - það er mjög svipað því sem þú þarft, og með fyrstu yfirborðslegu rannsókninni kemur hugsunin í hausinn á mér: „Ó! Það er það í staðinn fyrir RAC! Og jafnvel með tæknilega leiðslu í heimalandi okkar!“

En ekki flýta þér að gleðjast, og frekar munum við lýsa hvers vegna þú þarft að þekkja þessi blæbrigði, vegna þess að ... Erfitt er að spá fyrir um þær, jafnvel eftir að hafa lesið vöruskjölin vel. Metið hvort þú sért tilbúinn til að uppfæra DBMS útgáfur oft beint á framleiðslusíðunni vegna þess Sumir gallar eru ekki samrýmanlegir iðnaðarnotkun og erfitt er að greina við prófun.
Byrjaðu á því að lesa vandlega hlutann „multimaster“ - „takmarkanir“ á vefsíðu framleiðanda.

Það fyrsta sem þú gætir rekist á eru sérkenni þess hvernig viðskipti virka, í svokölluðu. „tvífasa“ ham, og stundum er engin leið til að laga þetta nema með því að endurskrifa alla rökfræði málsmeðferðarinnar. Hér er einfalt dæmi:

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;

Villa kemur upp:

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

Svo er hægt að berjast í langan tíma með dead lock í útgáfum 10.5, 10.6 og eina þekkta lausnin sem drepur allan kjarna klasans er að fjarlægja “vandamál” töflur úr klasanum, þ.e.a.s. gerðu_table_local, en þetta mun að minnsta kosti leyfa því að virka, og mun ekki setja allt í bið vegna hangandi bið eftir viðskiptaskuldbindingum. Jæja, eða settu upp uppfærslu á útgáfu 11.2, sem ætti að hjálpa, en kannski ekki, ekki gleyma að athuga.

Í sumum útgáfum geturðu fengið enn dularfullari lás:

username= mtm и backend_type = background worker

Og í þessum aðstæðum mun aðeins uppfæra DBMS útgáfuna í 11.2 og hærri hjálpa þér, eða kannski mun það ekki hjálpa.

Sumar aðgerðir með vísitölum geta leitt til villna, sem gefa skýrt til kynna að vandamálið sé í tvíátta afritun; þú munt sjá beint BDR í MTM annálunum. Er það virkilega 2ndQuadrant? Nei... við keyptum multimaster, þetta er bara tilviljun, það heitir tæknin.

[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 

Ef þú ert að nota tímabundnar töflur, þrátt fyrir tryggingarnar: „Fjölmeistaraviðbótin framkvæmir afritun gagna á fullkomlega sjálfvirkan hátt. Þú getur samtímis framkvæmt skriffærslur og unnið með tímabundnar töflur á hvaða hnút sem er í klasanum.

Þá muntu í raun fá að afritun virkar ekki yfir allar töflur sem notaðar eru í málsmeðferðinni, ef kóðinn inniheldur að búa til tímabundna töflu, og jafnvel notkun multimaster.remote_functions mun ekki hjálpa, verður þú að uppfæra eða endurskrifa rökfræði þína í málsmeðferðina. Ef þú þarft að nota tvær viðbætur multimaster og pg_pathman samtímis innan Postgres Pro Enterprise v 10.5, athugaðu það með þessu einfalda dæmi:

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

Eftirfarandi villur byrja að birtast í annálunum á DBMS hnútunum:

…
 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

Þú getur fundið út hverjar þessar villur eru í tækniaðstoð, það er ekki til einskis að þú keyptir það.

Hvað skal gera? Rétt! Uppfærðu í „Postgres Pro Enterprise“ v 11.2

Sérstaklega þarftu að vita að röð, sem er hlutur í endurteknum gagnagrunni, hefur ekki gildi frá enda til enda um allan klasann, hver röð er staðbundin fyrir hvern hnút og ef þú ert með reiti með einstökum takmörkunum og notkunarröð, þá geturðu aðeins gert aukningu sem jafngildir hnútnúmerinu í þyrpingunni, því Eins margir hnútar í þyrpingunni og mögulegt er, röð og int munu vaxa hraðar en þú bjóst við. Til að einfalda vinnu með röð í vörunni finnurðu jafnvel alter_sequences aðgerðina, sem mun gera nauðsynlegar hækkanir fyrir hverja röð á öllum hnútum, en vertu viðbúinn því að aðgerðin virkar ekki í öllum útgáfum. Auðvitað geturðu skrifað það sjálfur, notað kóðann frá github sem grunn eða leiðrétt hann sjálfur beint í DBMS. Í þessu tilviki munu reitir með serialbigserial gerðinni virka betur, en til að nota þá þarftu líklegast að endurskrifa kóðann fyrir aðferðirnar þínar og aðgerðir. Kannski mun einhverjum finnast monotonic_sequences aðgerðin gagnleg.

Fyrir útgáfu 11.2 af Postgres Pro Enterprise mun afritunin aðeins virka ef það eru einstakir aðallyklar, taktu þetta með í reikninginn við þróun.

Sérstaklega vil ég nefna sérkenni þess hvernig npgsql virkar í klasalausn; þessi vandamál koma ekki upp á einum hnút heldur eru þau alveg til staðar í multimaster.
Í sumum útgáfum gætir þú rekist á villu:

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. 

Hvað er hægt að gera? Þú þarft bara ekki að nota sumar útgáfur. Þú þarft að þekkja þá, því... Villan birtist í fleiri en einni útgáfu og jafnvel eftir fyrstu lagfæringu gætirðu rekist á hana síðar. Þú þarft líka að vera tilbúinn fyrir þetta og það er betra að ná til allra auðkenndra DBMS galla sem eru leiðréttar af framleiðanda með sérstökum aðhvarfsprófum. Svo að segja, treysta, en sannreyna.

Ef forritið notar npgsql og skiptir á milli hnúta og heldur að þeir séu allir eins, þá gætirðu fengið villu:

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

Þessi villa kemur upp vegna þess að bindingin er í gangi

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

samsettar tegundir við ræsingu forrita fyrir allar tengingar. Fyrir vikið fáum við auðkenni frá einum hnút og þegar beðið er um á öðrum hnút passar það ekki, þar af leiðandi kemur villa til baka, þ.e. Að vinna gegnsætt með samsettum tegundum í klasa er ekki mögulegt fyrir sum forrit án viðbótar endurskrifa á forritahlið (ef þér tekst það).

Eins og við öll vitum er heildarmat á ástandi klasans mjög mikilvægt fyrir greiningar og rekstrarráðstafanir í rekstri, í vörunni má finna nokkrar aðgerðir sem ættu að auðvelda þér lífið en stundum geta þær gefið eitthvað allt annað en það sem þú og jafnvel framleiðandinn sjálfir búist við af þeim sem þú átt von á.

Til dæmis:

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

En hvers vegna inniheldur LiveNodes reiturinn númerið 2 alls staðar, þó samkvæmt lýsingu á aðgerð fjölmeistarans ætti það að samsvara tölunni AllNodes=3? Svar: þú þarft að uppfæra DBMS útgáfuna.

Og vertu tilbúinn til að safna annálum fyrir alla hnúta, því... venjulega muntu sjá "villan er í skrá annars hnút." Tækniþjónusta mun samþykkja alla galla sem þú greinir og upplýsa þig um að næsta útgáfa sé tilbúin, sem þarf stundum að setja upp með stöðvun þjónustu, stundum í langan tíma (fer eftir stærð DBMS). Þú ættir ekki að vona að rekstrarvandamál trufli seljandann verulega og uppfærslan vegna auðkenndra galla verður framkvæmd með þátttöku fulltrúa söluaðilans, eða réttara sagt, þú þarft ekki einu sinni að hafa fulltrúa seljanda með í för, þar sem í enda geturðu endað með sundurtekinn klasa í framleiðslu án öryggisafrits.

Reyndar, í leyfinu fyrir viðskiptavöru, varar framleiðandinn heiðarlega við: „Þessi hugbúnaður er veittur „eins og er“ og Postgres Professional hlutafélag er ekki skylt að veita viðhald, stuðning, uppfærslur, viðbætur eða breytingar.

Ef þú hefur ekki enn giskað á hvaða vöru við erum að tala um, þá var öll þessi reynsla fengin vegna árslangrar starfsemi Postgres Pro Enterprise gagnagrunnsins. Þú getur dregið þína eigin ályktun, það er svo rakt að sveppir vaxa.

En þetta væri ekki svo slæmt ef það væri gert í tæka tíð og útrýmt þeim vandamálum sem upp koma.

En þetta er einmitt það sem gerist ekki. Svo virðist sem framleiðandinn hafi ekki nóg fjármagn til að útrýma greindum villum án tafar.

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Hefur þú reynslu af því að skipta úr erlendu/eigu DBMS yfir í ókeypis/innlent?

• 21,3%Já, jákvætt10

• 10,6%Já, neikvætt5

• 21,3%Nei, DBMS var ekki breytt10

• 4,3%DBMS var breytt, en ekkert breytt2

• 42,6%Skoða niðurstöður 20

47 notendur kusu. 12 notendur sátu hjá.

Heimild: www.habr.com