(c) Yandex.Képek
Minden karakter kitalált, a védjegyek a tulajdonosaikhoz tartoznak, minden egybeesés véletlenszerű, és egyébként ez az én „szubjektív értékítéletem, kérem ne törjék be az ajtót…”.
Nagy tapasztalatunk van informatikai rendszerek adatbázisok közötti logikai átviteli fordításában. A 2016.11.16-i 1236-os kormányrendelet vonatkozásában gyakran az Oracle-tól PostgreSQL-re való átjárásról van szó. Arról, hogyan lehet a folyamatot a leghatékonyabban és legfájdalommentesebben megszervezni – erről külön beszélhetünk, ma az klaszterhasználat különbségeiről és arról a problémáról mesélünk, amivel a nagy terhelésű elosztott rendszerek bonyolult logikájának megépítésekor találkozhatunk.
Spoiler – igen, a káp, RAC és a pg multimaster nagyon eltérő megoldások.
Tegyük fel, hogy már minden logikát átírt plsql-ről pgsql-re. A regressziós tesztjeid elég jók, most már természetesen a skálázásra gondolsz, mivel a terheléses tesztek nem igazán örvendeztetnek meg, különösen azzal a hardverrel, amelyet eredetileg a projektbe terveztek, azzal a másik DBMS-sel. Tegyük fel, hogy találtál egy hazai beszállítótól származó megoldást, a „Postgres Professional”-t, amelynek van egy opciója a „multimaster” néven, amit csak a „Postgres Pro Enterprise” maximális verziójában érhetsz el, és a leírás alapján ez nagyon hasonlónak tűnik, és az első felületes vizsgálat során eszedbe jut a gondolat: „Ó! Az RAC helyett ez pontosan az! Ráadásul hazai technikai támogatással!”.
De ne siess, hogy örülj, és tovább fogjuk írni, miért fontos ezeket a nüanszokat tudni, mivel nehéz előre látni őket, még akkor is, ha jól átnézted a termék dokumentációját. Értékeld, hogy készen állsz-e gyakran frissíteni az adatbázis verzióit közvetlenül az ipari területen, mivel néhány hiba nem kompatibilis az ipari használattal, és nehezen azonosíthatók a tesztelés során.
Kezdj azzal, hogy figyelmesen elolvasod a gyártó weboldalának a „multimaster” részét – a „korlátozások” szekciót.
Elsőként a tranzakciók munkamódszerének változásai okozhatnak nehézségeket, úgynevezett „kétfázisú” módban, és néha, a logikád átkonvertálása nélkül nem tudod kijavítani a dolgokat. Íme egy egyszerű példa:
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;Hiba lépett fel:
HIBÁZIK: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) megszakadt a 3. csomóponton. Ellenőrizze a naplóját, hogy megtekinthesse a hiba részleteit.Tovább lehet sokáig küzdeni a dead lock-kal a 10.5-ös és 10.6-os verziókban, és az egyetlen ismert megoldás, ami megöl minden lényeget a klaszterből – az, hogy eltávolítják a "problémás" táblákat a klaszterből, azaz make_table_local-t alkalmaznak, de ez legalább lehetővé teszi a munkát, és nem állítja meg mindent a tranzakciók elkötelezésének felfüggesztett várakozása miatt. Vagy frissíthetnek a 11.2-es verzióra, amelynek segítenie kell, vagy talán nem, ne felejtsen el ellenőrizni.
Egyes verziókban még rejtélyesebb zárolást is kaphat:
username= mtm és backend_type = background workerÉs ebben a helyzetben csak a DBMS verzió frissítése 11.2-re és feljebb segíthet, vagy talán nem.
Bizonyos indexelési műveletek hibákat okozhatnak, ahol nyíltan meg van jelölve, hogy a probléma éppen a Bi-Directional Replication. Az MTM naplókban közvetlenül látni fogja a BDR-t. Tényleg 2ndQuadrant? Dehogyis... hiszen multimastert vettünk, ez egyszerű véletlen, ez egy technológia neve.
[MTM] bdr nem támogatja az index újraellenőrzéseket
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: küldje el a ABORT értesítést a tranzakció (5467) helyi xid=4083 számára a koordinátor 3-nak
[MTM] Fogadja el az ABORT_PREPARED logikai üzenetet a tranzakció MTM-3-25030-83-605694076627780 számára a 3. csomóponttól
[MTM] Abortálja a felkészített tranzakciót MTM-3-25030-83-605694076627780 állapotban InProgress a 3. csomóponttól originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448 Ha ideiglenes táblákat használ, a nyilatkozatok ellenére: "A multimaster kiterjesztés automatikusan replikálja az adatokat. Különböző csomópontokon egyszerre végezhet írható tranzakciókat és dolgozhat ideiglenes táblákkal."
Akkor a ténylegesen azt tapasztalja, hogy nem működik a replikáció az összes táblán, amelyet a eljárásban használnak, ha a kódban található egy ideiglenes tábla létrehozása, és még a multimaster.remote_functions használata sem segít, frissítenie kell vagy át kell írnia az eljárás logikáját. Ha egyszerre kell használnia a multimaster és a pg_pathman kiterjesztéseket a „Postgres Pro Enterprise” 10.5-ös verzió keretein belül, akkor ellenőrizze, hogy ebben az egyszerű példában:
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);A naplóban az adatbázis csomópontokon a következő hibák kezdenek megjelenni:
…
PATHMAN_CONFIG nem tartalmazza a 23245 relációt
> find_in_dynamic_libpath: próbálkozás "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: próbálkozás "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> HIBAKERESÉS: find_in_dynamic_libpath: próbálkozás "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: próbálkozás "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) név: névtelen; blokkolási állapot: PREPARE; állapot: INPROGR, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) név: névtelen; blokkolási állapot: DEFAULT; állapot: INPROGR, xid\/subid\/cid: 0\/1\/0
> váltás a 1-es idővonalra, érvényes 0\/0-ig
…
Transaction MTM-1-13604-7-612438856339841 (6919) megszakadt a 2-es csomóponton. Ellenőrizze a naplót az hiba részleteiért.
...
[MTM] 28295: TÁV kezdés megszakított tranzakció 7017
…
[MTM] 28295: küldje el AZ ABORT értesítést a tranzakcióról (6919) helyi xid=7017 az 1-es koordinátornak
Miket jelentenek ezek a hibák, azt a technikai támogatásnál megtudhatja, nem véletlenül vásárolta meg.
Mit tegyünk? Helyesen! Frissíteni kell a „Postgres Pro Enterprise” legújabb 11.2 verziójára.
Külön tudni kell, hogy a sequence, mint a replikálható adatbázis objektuma, nem rendelkezik globális értékkel a klaszteren belül; minden sequence lokális minden csomópont számára, és ha vannak olyan mezők, amelyek egyedi korlátozásokkal rendelkeznek és sequence-t használnak, akkor csak annyira tudja növelni, amennyi csomópont van a klaszterben, mivel annyival gyorsabban növekszik a sequence, és az int gyorsabban elfogy, mint ahogy számítaná. A sequence-nel való munka megkönnyítése érdekében a termékben található egy alter_sequences nevű funkció, amely végrehajtja a szükséges növeléseket minden sequqence-nél minden csomóponton, de készüljön fel arra, hogy ez a funkció nem minden verzióban fog működni. Természetesen ezt meg lehet írni saját kezűleg, alapul véve a github kódját vagy közvetlenül az adatbázisban módosítva. Ezzel együtt a serialbigserial típussal rendelkező mezők pontosabban fognak működni, de ezek használatához valószínűleg át kell írnia a procedúrái és funkciói kódját. Lehet, hogy valakinek hasznos lesz a monotonic_sequences funkció.
A 11.2 verzió előtt a „Postgres Pro Enterprise” replikáció csak egyedi elsődleges kulcsok megléte esetén fog működni, ezt vegye figyelembe a fejlesztés során.
Külön szeretném megemlíteni az npgsql működésének sajátosságait a klaszteres megoldásokban; ezek a problémák nem merülnek fel egyetlen csomópont esetén, de a multimester esetében jól jelen vannak.
Néhány verzióban hibával lehet szembesülni:
Kivételi részletek: Npgsql.PostgresException: 25001: SET TRANSACTION ISOLATION LEVEL parancs
Leírás: Kezelt kivétel történt a jelenlegi webkérés végrehajtása alatt. Kérjük, nézze át a hívásláncot a hiba és a kód beli eredete megértéséhez. Mit lehet tenni? Egyszerűen el kell kerülni bizonyos verziókat. Ismerni kell őket, mert a hiba nem egyetlen verzióban lép fel, és akár az első javítása után is szembesülhet vele később. Ezt is figyelembe kell venni, és a gyártó által javított adatbázis-defektusokat a lehető legjobban kell regressziós tesztekkel lefedni. Szóval, bízz, de ellenőrizz!
Ha az alkalmazás npgsql-t használ, és a csomópontok között vált, azt gondolva, hogy mind egyformák, akkor előfordulhat egy hiba:
KIVÉTEL:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...Ez a hiba attól keletkezik, hogy a kötés történik
(NpgsqlConnection.GlobalTypeMapper.MapComposite("some_composite_type");) kompozit típusok az alkalmazás indításakor minden kapcsolathoz. Ennek eredményeként egy azonosítót kapunk valamelyik csomópontról, és egy másik csomópontra tett lekérdezésnél nem egyeznek, ami miatt hiba lép fel, azaz a kompozit típusok átlátható kezelése a klaszterben egyes alkalmazások számára lehetetlen lesz további írásmódok nélkül az alkalmazás oldalán (ha ezt sikerül megvalósítani).
Ahogy mindannyian tudjuk, a klaszter állapotának általános értékelése nagyon fontos a diagnosztikához és a gyors intézkedésekhez a munkának köszönhetően; a termékben akad néhány funkció, amelynek könnyebbé kellene tennie az életünket, de néha olyan eredményeket adhat, amelyeket Ön és még maga a gyártó sem várna tőlük.
Például:
select mtm.collect_cluster_info();
a minden csomóponton az azonos eredmény:
(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")De miért áll a LiveNodes mezőben mindenhol a 2-es szám, holott a multimester működésének leírása szerint az AllNodes=3 számnak megfelelően kellene lenni? Válasz: frissíteni kell az adatbázis verzióját.
Legyen felkészülve, hogy naplókat gyűjtsön az összes csomóponton, mivel általában azt fogja látni, hogy "a hiba egy másik csomópont naplójában található." A technikai támogatás elfogadja az Ön által észlelt hibákat, és értesíti Önt egy új verzió készenlétéről, amelyet néha leállítással, néha pedig hosszú ideig kell telepíteni (ez az Ön adatbázisának méretétől függ). Ne számítson arra, hogy az üzemeltetési problémák nagyon zavarni fogják a gyártót, és hogy a felfedezett hibák miatt a frissítések gyártói képviselők bevonásával történnek, pontosabban, nem szükséges a gyártó képviselőit bevonni, mert végül egy produktív környezetben visszafordított klasztert kaphat biztonsági mentés nélkül.
A kereskedelmi termék licencében a gyártó őszintén figyelmeztet: "Ez a szoftver 'ahogy van' alapon kerül forgalmazásra, és a 'Postgres Professional' Kft. nem köteles támogatást, frissítéseket, bővítéseket vagy módosításokat nyújtani."
Ha még nem találta ki, melyik termékről van szó, ez az összes tapasztalat az évi Postgres Pro Enterprise adatbázis üzemeltetéséből származik. Mindenki levonhatja a maga következtetéseit, olyan nyers, hogy gombák nőnek rajta.
De ez még mindig nem lenne a legrosszabb, ha az elégedetlent észlelt problémákat időben és gyorsan orvosolnák.
De pontosan ez nem történik meg. Valószínűleg a gyártónak nincsenek elegendő erőforrásai a felfedezett hibák gyors javításához.
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Van tapasztalata az idegen/proprietárius adatbázisból a szabad/belföldi rendszerre való áttérésről?
21,3%Igen, pozitív 10
10,6%Igen, negatív 5
21,3%Nem, nem változtattunk adatbázist 10
4,3%Az adatbázist változtattuk, de semmi sem változott 2
42,6%Eredmények megtekintése 20
47 felhasználó szavazott. 12 felhasználó tartózkodott.
Forrás: habr.com
