(ts) Yandex.Képek
Minden szereplő kitalált, a védjegyek a megfelelő tulajdonosokhoz tartoznak, bármilyen hasonlóság pusztán a véletlen műve, és általánosságban ez az én „szubjektív értékítéletem, kérlek ne törd be az ajtót…”.
Kiterjedt tapasztalattal rendelkezünk adatbázis-logikát tartalmazó információs rendszerek egyik adatbázis-kezelő rendszerből a másikba történő migrálásában. A 2016. november 16-i 1236. számú kormányhatározattal összhangban ez gyakran magában foglalja az Oracle-ről PostgreSQL-re való migrációt. Külön megbeszélhetjük, hogyan lehet ezt a folyamatot a lehető leghatékonyabban és fájdalommentesebben megszervezni. Ma a klaszter használatának sajátosságait és azokat a kihívásokat tárgyaljuk, amelyekkel nagy terhelésű elosztott rendszerek építésekor találkozhat, amelyek összetett logikát tartalmaznak az eljárásokban és függvényekben.
Spoiler: igen, a cap, az RAC és a pg multimaster nagyon különböző megoldások.
Tegyük fel, hogy már áttelepítetted az összes logikádat plsql-ről pgsql-re. És a regressziós tesztjeid tökéletesen rendben vannak. Most természetesen a skálázáson gondolkodsz, mivel a terheléstesztelés nem éppen nagy ügy, különösen az eredetileg ahhoz a másik adatbázis-kezelőhöz tervezett hardveren. Tegyük fel, hogy találtál egy megoldást egy hazai gyártótól, a Postgres Professionaltól, egy "multimaster" nevű funkcióval, amely csak a "végső" verzióban, a Postgres Pro Enterprise-ban érhető el. A leírás alapján ítélve nagyon hasonlít ahhoz, amire szükséged van, és első pillantásra azt gondolhatnád: "Ó! Pont jó a RAC helyett! És ráadásul hazai technikai támogatással!"
De ne izgulj túlságosan. Elmagyarázzuk, miért kell tisztában lenned ezekkel az árnyalatokkal, mivel nehéz előre látni őket, még a termékdokumentáció alapos elolvasása után is. Gondold át, hogy felkészült-e arra, hogy a DBMS verzióit gyakran frissítsd közvetlenül az éles környezetben, mivel egyes hibák nem kompatibilisek az éles környezetben való felhasználással, és nehezen észlelhetők tesztelés közben.
Kezdje azzal, hogy figyelmesen elolvassa a gyártó weboldalán a "multimaster" - "korlátozás" részt.
Az első dolog, amivel találkozhatsz, az a tranzakciók működésének sajátosságai az úgynevezett "kétfázisú" módban, és néha nincs más mód ennek a javítására, mint az eljárás teljes logikájának átírása. Í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 történik:
ОШИБКА: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.A 10.5-ös és 10.6-os verziókban sokáig küzdhetsz a patthelyzetekkel, és az egyetlen ismert megoldás, amely teljesen tönkreteszi a klaszter értelmét, a "problémás" táblák eltávolítása a klaszterből, azaz a make_table_local futtatása. De ez legalább lehetővé teszi a dolgok működését, ahelyett, hogy minden összeomlana a tranzakciók véglegesítésére való várakozás miatt. Vagy frissíthetsz a 11.2-es verzióra, ami segíthet, de lehet, hogy nem – mindenképpen ellenőrizd.
Egyes verziókban még titokzatosabb zárat kaphatsz:
username= mtm и backend_type = background workerÉs ebben a helyzetben csak a DBMS verziójának 11.2-es vagy újabb verzióra való frissítése segíthet, de lehet, hogy nem.
Néhány indexelési művelet hibákat okozhat, amelyek egyértelműen jelzik, hogy a probléma a kétirányú replikáció; a BDR-eket az MTM naplókban fogod látni. A 2ndQuadrant a hibás? Nem... mi multimastert vettünk, csak véletlen egybeesés; ez a technológia neve.
[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 Ha ideiglenes táblákat használsz, a biztosítékok ellenére: "A többmesteres kiterjesztés teljesen automatikusan végzi az adatreplikációt. Egyidejűleg futtathatsz írási tranzakciókat és dolgozhatsz ideiglenes táblákkal bármelyik fürtcsomóponton."
Valójában azt fogod tapasztalni, hogy a replikáció nem fog működni az eljárásban használt összes táblában, ha a kód ideiglenes táblát hoz létre, és még a multimaster.remote_functions használata sem segít. Frissítened vagy át kell írnod a logikát az eljárásban. Ha a multimaster és a pg_pathman kiterjesztést egyszerre kell használnod a Postgres Pro Enterprise v10.5-ben, ellenőrizd, hogy működik-e ez az egyszerű példa:
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 következő hibák kezdenek megjelenni a DBMS csomópontok naplóiban:
…
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
A hibák okát a műszaki támogatással megtudhatod; nem véletlenül vetted meg.
Mit tegyek? Így van! Frissítsek Postgres Pro Enterprise (v11.2) verzióra.
Fontos megjegyezni, hogy egy sorozat, mivel replikált adatbázis-objektum, nem rendelkezik konzisztens értékkel a teljes fürtön. Minden sorozat lokális az egyes csomópontokra. Ha egyedi megkötésekkel rendelkező mezőid vannak, amelyek szekvenciát használnak, akkor csak a fürt csomópontszámával növelheted az értéket. Ez azt jelenti, hogy minél több csomópont van a fürtben, annál gyorsabban fog növekedni a sorozatod, és mind a sequence, mind az int gyorsabban fog elfogyni a vártnál. A szekvenciákkal való munka egyszerűsítése érdekében a termék tartalmaz egy alter_sequences függvényt is, amely minden szekvenciához elvégzi a szükséges növeléseket az összes csomóponton. Azonban vedd figyelembe, hogy ez a függvény nem minden verzióban fog működni. Természetesen te magad is megírhatod a GitHub kódját használva, vagy közvetlenül a DBMS-ben módosítva. A Serialbigserial mezők helyesebben fognak működni, de használatukhoz valószínűleg át kell írnod az eljárásaidat és függvényeidet. Talán a monotonic_sequences függvény hasznos lesz valakinek.
A Postgres Pro Enterprise 11.2 előtti verziókban a replikáció csak egyedi elsődleges kulcsok esetén működött, ezért kérjük, ezt tartsa szem előtt a tervezés során.
Szeretném megemlíteni az npgsql működésének sajátosságait egy fürtözött megoldásban. Ezek a problémák nem egyetlen csomóponton jelentkeznek, de egy több masteres megoldásban igencsak jelen vannak.
Egyes verziókban a következő hibákba ütközhet:
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. Mit tehetünk? Egyszerűen kerüljük bizonyos verziók használatát. Fontos ismerni őket, mivel a hiba több verzióban is megjelenik, és még a kezdeti javítás után is találkozhatunk vele később. Erre is fel kell készülni, és a legjobb, ha az összes azonosított, a gyártó által kijavított adatbázis-kezelő rendszer hibáját külön regressziós tesztekkel vizsgáljuk. Bízzunk benne, de ellenőrizzük, hogy úgy mondjam.
Ha az alkalmazásod npgsql-t használ, és a csomópontok között vált, azt gondolva, hogy mind ugyanolyanok, akkor a következő hibába ütközhetsz:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...Ez a hiba azért fordul elő, mert a kötés folyamatban van.
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) Az összetett típusokat az alkalmazás indításakor használják az összes kapcsolathoz. Ennek eredményeként az egyik csomóponttól kapott azonosító nem egyezik meg, amikor egy másik csomóponton kérik, ami hibát eredményez. Ez azt jelenti, hogy az összetett típusokkal való transzparens munka egy fürtön belül egyes alkalmazások számára lehetetlen lesz további átírások nélkül az alkalmazás oldalán (ha ez lehetséges).
Mint mindannyian tudjuk, a klaszter állapotának átfogó felmérése kulcsfontosságú a diagnosztikához és az operatív beavatkozásokhoz. A termék tartalmaz néhány olyan funkciót, amelyek megkönnyíthetik az életedet, de néha előfordulhat, hogy nem azt nyújtják, amit te, vagy akár a gyártó elvár.
Például:
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")De miért mutatja a LiveNodes mező mindig a 2-es számot, annak ellenére, hogy a multimaster leírása szerint AllNodes = 3? Válasz: Frissítenie kell a DBMS verzióját.
Készülj fel arra, hogy minden csomópontról naplókat kell gyűjtened, mivel általában a „hiba egy másik csomópont naplójában” üzenet jelenik meg. A technikai támogatás elfogadja az összes azonosított hibát, és értesít, amikor elkészül a következő verzió, ami néha leállást igényel, néha akár hosszú ideig is (az adatbázis-kezelő rendszer méretétől függően). Ne számíts arra, hogy a működési problémák túlságosan aggasztóak lesznek a szállító számára, és az észlelt hibák miatti frissítéseket a szállító képviselőinek bevonásával fogják elvégezni. Valójában még a szállító képviselőit sem szabad bevonni, mivel egy szétszerelt fürtöt kaphatsz éles környezetben biztonsági mentés nélkül.
Valójában a kereskedelmi terméklicencben a gyártó egyértelműen figyelmeztet: „Ez a szoftver „ahogy van” alapon kerül biztosításra, és a Postgres Professional Limited Liability Company nem köteles karbantartást, támogatást, frissítéseket, bővítéseket vagy módosításokat biztosítani.”
Ha még nem találtad ki, melyik termékről beszélünk, ezt a sok tapasztalatot egy évnyi Postgres Pro Enterprise adatbázis használat során szereztük. A következtetést levonhatod magadtól is: annyira nedves, hogy gombamód szaporodik.
De ez nem lenne olyan rossz, ha időben végrehajtanák, és a felmerülő problémákat gyorsan megoldanák.
De pontosan ez nem történik meg. Úgy tűnik, a gyártónak nincsenek meg az erőforrásai ahhoz, hogy azonnal kijavítsa a felfedezett hibákat.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Van tapasztalata külföldi/saját fejlesztésű adatbázis-kezelő rendszerről ingyenes/hazai rendszerre való váltásban?
21,3%Igen, pozitív10
10,6%Igen, negatív5
21,3%Nem, az adatbázis-kezelő rendszer (DBMS) nem változott.
4,3%A DBMS megváltozott, de semmi sem változott.
42,6%Eredmények megtekintése20
47 felhasználó szavazott. 12 felhasználó tartózkodott.
Forrás: will.com
