»Pro, men ingen klustring« eller hur vi gjorde vår DBMS-importsubstitution

(c) Yandex.Bilder

Alla karaktärer är fiktiva, varumärken tillhör deras respektive ägare, alla likheter är slumpmässiga och detta är helt enkelt min »subjektiva åsikt, var snäll och bryt inte dörren...«

Vi har betydande erfarenhet av att översätta informationssystem med logik i databaser från ett DBMS till ett annat. I samband med den ryska regeringens förordning nr 1236 från den 16.11.2016 handlar det ofta om överföring från Oracle till Postgresql. Hur man organiserar processen på ett maximalt effektivt och smärtfritt sätt — det kan vi berätta mer om separat, idag kommer vi att tala om egenskaperna hos kluster och vilka problem man kan stöta på när man bygger högbelastade distribuerade system med komplex logik i procedurer och funktioner.

Spoiler – ja, cap, RAC och pg multimaster är verkligen väldigt olika lösningar.

Anta att du redan har flyttat all logik från plsql till pgsql. Och dina regressionstester fungerar ganska bra, nu tänker du naturligtvis på skalning, eftersom belastningstesterna inte riktigt glädjer dig, särskilt med den hårdvara som ursprungligen planerades för det andra DBMS:et. Anta att du har hittat en lösning från den inhemska leverantören »Postgres Professional« med en funktion som kallas »multimaster«, som endast är tillgänglig i den »maximala« versionen av »Postgres Pro Enterprise« och enligt beskrivningen verkar det vara precis vad du behöver, och vid första ytliga studier kommer du att få tanken: »Åh! Istället för RAC, det är perfekt! Plus teknisk support i hemlandet!«

Men skynda dig inte att bli glad, och längre fram kommer vi att förklara varför dessa nyanser är viktiga att känna till, eftersom de är svåra att förutse, även om man studerat dokumentationen för produkten noggrant. Överväg om du är beredd att ofta uppdatera versionerna av DBMS direkt i produktionsmiljön, eftersom vissa defekter är inkompatibla med industriexploatering och kan vara svåra att upptäcka under tester.
Börja med att noggrant läsa avsnittet »multimaster« — »begränsningar« på tillverkarens webbplats.

Det första du kan stöta på är egenskaperna hos transaktionshantering i det så kallade »tvåfasläget«, och ibland, förutom att skriva om hela logiken i din procedur, går det inte att åtgärda. Här är ett enkelt exempel:

skapa tabell test1 (id heltal, id1 heltal);
infoga värden i test1 (1, 1),(1, 2);
 
ÄNDRA TABELL test1 LÄGG TILL BEGREPP test1_uk UNIK (id,id1) DEFERRABLE INITIALLY DEFERRED;
 
uppdatera test1
           ställ in id1 =
               fall id1
                 när 1
                 då 2
                 annars id1 - tecken(2 - 1)
               slut
         där id1 mellan 1 och 2;

Ett fel uppstår:

FEL:  [MTM] Transaktion MTM-1-2435-10-605783555137701 (10654) är avbruten på nod 3. Kontrollera dess logg för att se felinformationen.

Det går att kämpa länge med dead lock i versioner 10.5, 10.6 och den enda kända lösningen som dödar hela syftet med klustret - är att ta bort "problematiska" tabeller från klustret, dvs. göra make_table_local, men detta kommer åtminstone att låta er arbeta, och inte sätta stopp på allt på grund av hängande väntan på transaktionscommit. Eller så kan ni uppgradera till version 11.2, vilket borde hjälpa, kanske inte, glöm inte att kontrollera.

I vissa versioner kan ni få en ännu mer mystisk låsning:

användarnamn= mtm och backend_typ = bakgrundsarbetare

Och i denna situation kan endast en uppgradering av databashanteraren till version 11.2 och högre hjälpa, eller kanske inte.

Vissa operationer med index kan orsaka fel som tydligt anger att problemet ligger i Bi-Directional Replication, i MTM-loggarna ser ni tydligt BDR. Verkligen 2ndQuadrant? Nej, nej… vi köpte ju multimaster, det är bara en slump, det är namnet på teknologin.

[MTM] bdr stödjer inte indexöversyn
[MTM] 12124: REMOTE börja avbryta transaktion 4083
[MTM] 12124: skicka ABORT meddelande för transaktion (5467) lokal xid=4083 till koordinator 3
[MTM] Ta emot ABORT_PREPARED logisk meddelande för transaktion MTM-3-25030-83-605694076627780 från nod 3
[MTM] Avbryt förberedd transaktion MTM-3-25030-83-605694076627780 status InProgress från nod 3 originId=3
[MTM] MtmLogAbortLogicalMessage nod=3 transaktion=MTM-3-25030-83-605694076627780 lsn=9fff448 

Om ni använder temporära tabeller, trots försäkringar om: "Multimaster-tillägget replikerar data på ett helt automatiskt sätt. Ni kan samtidigt utföra skrivtransaktioner och arbeta med temporära tabeller på valfri nod i klustret."

Så får ni i praktiken se att replikeringen av alla tabeller som används i proceduren inte fungerar, om det finns skapande av temporära tabeller i koden, och även användning av multimaster.remote_functions hjälper inte, ni måste uppgradera eller omstrukturera er logik i proceduren. Om ni behöver använda två tillägg aktivt, multimaster och pg_pathman, inom "Postgres Pro Enterprise" v 10.5, kontrollera att med ett så enkelt exempel:

SKAPA TABELL mätning (
    city_id         int inte null,
    logdate         datum inte null,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

SKAPA TABELL mätning_y2019m06 PARTITION OF mätning FÖR VÄRDEN FRÅN ('2019-06-01') TILL ('2019-07-01');
infoga in mätning värden (1, till_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
infoga in mätning värden (2, till_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
infoga in mätning värden (3, till_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
infoga in mätning värden (4, till_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

I loggarna på databasnoderna börjar sådana fel uppstå:

…
 PATHMAN_CONFIG innehåller inte relation 23245
> find_in_dynamic_libpath: försöker "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: försöker "\/opt\/\/…\/ent-10\/lib\/pg_pathman.so"
> DEBUG: find_in_dynamic_libpath: försöker "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: försöker "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) namn: namnlös; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) namn: namnlös; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
> växlad till tidslinje 1 giltig tills 0/0
…
Transaktion MTM-1-13604-7-612438856339841 (6919) är avbruten på nod 2. Kontrollera dess logg för att se felförklaringar.
...
[MTM] 28295: FJÄRR börja avbryta transaktion 7017
…
[MTM] 28295: skicka ABORT meddelande för transaktion (6919) lokal xid=7017 till koordinator 1

Vad dessa fel är kan du ta reda på hos supporten, du köpte den inte för intet.

Vad göra? Rätt! Uppgradera till "Postgres Pro Enterprise" till v 11.2

Det är särskilt viktigt att veta att sekvensen, som är ett objekt av en replikerad databas, inte har ett kontinuerligt värde i hela klustret, varje sekvens är lokal för varje nod och om du har fält med unika begränsningar som använder sekvenser, så kan du endast öka med ett värde motsvarande nodnumret i klustret, eftersom ju fler noder i klustret, desto snabbare kommer din sekvens att öka, och int kommer att ta slut snabbare än du räknade med. För att förenkla arbetet med sekvenser i produkten kommer du till och med att hitta funktionen alter_sequences, som gör nödvändiga inkrement på varje sekvens på alla noder, men var beredd att funktionen kanske inte fungerar i alla versioner. Självklart kan du skriva den själv, ta grundkod från github eller justera den direkt i databasen. Samtidigt kommer fält av typen serialbigserial att fungera mer korrekt, men för att använda dem måste du troligen skriva om koden för dina procedurer och funktioner. Kanske någon skulle ha nytta av funktionen monotonic_sequences.

Fram till version 11.2 av "Postgres Pro Enterprise" kommer replication endast att fungera om det finns unika primärnycklar, tänk på detta vid utveckling.

Det är särskilt värt att nämna de specifika funktionerna hos npgsql i klusterlösningar; dessa problem uppstår inte på enstaka noder, men förekommer i multimaster-lösningar.
I vissa versioner kan man stöta på följande fel:

Exception Details: Npgsql.PostgresException: 25001: kommandot SET TRANSACTION ISOLATION LEVEL 
Description: Ett ohanterat undantag inträffade under körningen av den aktuella webbplatsförfrågan. Vänligen granska stackspåret för mer information om felet och var det uppstod i koden. 

Vad kan man göra? Det gäller helt enkelt att undvika vissa versioner. Man måste känna till dem, då felet inte uppstår i en version, och även efter att det första felet har åtgärdats kan man stöta på det igen senare. Detta är något man också bör förbereda sig på, och det är bättre att alla identifierade defekter i databashanteraren som rättas av tillverkaren åtföljs av separata regressions tester. Så att säga, lita på, men kontrollera.

Om applikationen använder npgsql och växlar mellan noderna under antagandet att de är helt identiska, kan följande fel uppstå:

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

Ett sådant fel kommer att uppstå eftersom bindningen utförs

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

av komposittyper vid applikationens start för alla anslutningar. Som ett resultat får vi ett identifieringsnummer från en nod, och vid en förfrågan på en annan nod stämmer det inte överens, vilket resulterar i ett fel, det vill säga att arbeta transparent med komposittyper i kluster för vissa applikationer kommer att vara omöjligt utan ytterligare omskrivningar på applikationens sida (om du lyckas med det).

Som vi alla vet är den allmänna bedömningen av klusterstatus mycket viktig för diagnostik och snabba åtgärder under drift; i produkten kan du hitta vissa funktioner som bör underlätta ditt liv, men ibland kan de ge helt andra resultat än vad du och tillverkaren förväntar dig.

Till exempel:

select mtm.collect_cluster_info();
på varje nod ger samma resultat:
(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")

Men varför står det 2 i fältet LiveNodes överallt, trots att det i beskrivningen av multimaster ska motsvara antalet AllNodes=3? Svar: versionen av databashanteraren måste uppdateras.

Och var beredd att samla loggar från alla noder, eftersom du vanligtvis kommer att se "felet finns i loggen på en annan nod". Teknisk support kommer att ta emot alla problem som du identifierar och rapportera när nästa version är redo, som ibland behöver installeras med driftstopp, ibland under längre tid (beroende på storleken på din DBMS). Det är ingen idé att hoppas att driftsproblem kommer att oroar leverantören, och uppdateringar på grund av identifierade fel kommer att genomföras med leverantörens representanter, eller snarare, undvik att involvera leverantörens representanter, eftersom du till slut kan få en produktionskluster utan backup.

Egentligen varnar tillverkaren ärligt i licensen för den kommersiella produkten: "Denna programvara tillhandahålls på basis av principen 'så som den är' och det begränsade ansvarsbolaget 'Postgres Professionell' har ingen skyldighet att tillhandahålla support, support, uppdateringar, utvidgningar eller ändringar."

Om du inte har gissat vilken produkt det handlar om, så har all denna erfarenhet samlats in under ett års drift av Postgres Pro Enterprise-databasen. Du kan dra dina egna slutsatser, det är så fuktigt att svampar växer.

Men det skulle fortfarande vara en sak om problemen åtgärdades i tid och snabbt.

Men det är just det som inte händer. Tydligen har tillverkaren inte tillräckligt med resurser för att snabbt åtgärda identifierade buggar.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Har du erfarenhet av att migrera från en utländsk/proprietär DBMS till en fri/inhemsk?

• 21,3%Ja, positivt10

• 10,6%Ja, negativt5

• 21,3%Nej, vi har inte bytt DBMS10

• 4,3%Vi har bytt DBMS, men inget har förändrats2

• 42,6%Visa resultat20

47 användare har röstat. 12 användare har avstått.

Källa: habr.com