(ts) Yandex.Bilder
Alla karaktärer är fiktiva, varumärken tillhör sina ägare, eventuella likheter är ren slump och i allmänhet är detta mitt "subjektiva värdebedömning, snälla bryt inte upp dörren...".
Vi har betydande erfarenhet av att överföra informationssystem med DB-logik från ett DBMS till ett annat. I samband med regeringsdekret nr 1236 av den 16.11.2016 november XNUMX är detta ofta en överföring från Oracle till Postgresql. Vi kan separat berätta hur du organiserar processen så effektivt och smärtfritt som möjligt; idag kommer vi att berätta om funktionerna i att använda ett kluster och vilka problem du kan stöta på när du bygger högbelastade distribuerade system med komplex logik i procedurer och funktioner.
Spoiler - ja, cap, RAC och pg multimaster är väldigt olika lösningar.
Låt oss säga att du redan har överfört all logik från plsql till pgsql. Och dina regressionstester är helt okej, nu funderar du förstås på skalning, eftersom belastningstester inte gör dig särskilt glad, särskilt inte på den hårdvara som ursprungligen ingick i projektet, för just den andra databashanteringsplattformen. Låt oss säga att du har hittat en lösning från en inhemsk leverantör, "Postgres Professional", med ett alternativ som heter "multimaster", vilket bara finns tillgängligt i "maximum"-versionen av "Postgres Pro Enterprise", och enligt beskrivningen är det väldigt likt vad du behöver, och vid första ytliga granskning kommer tanken att dyka upp: "Åh! Istället för RAC, det är allt! Och till och med med teknisk support i hemlandet!"
Men skynda dig inte att glädjas, vi kommer vidare att beskriva varför dessa nyanser behöver kännas till, eftersom de är svåra att förutse, även efter att ha läst produktdokumentationen noggrant. Bedöm om du kommer att vara redo att ofta uppdatera DBMS-versioner direkt på produktionsplatsen, eftersom vissa defekter inte är kompatibla med industriell drift och är svåra att upptäcka under testning.
Börja med att noggrant läsa avsnittet "multimaster" - "begränsning" på tillverkarens webbplats.
Det första du kan stöta på är transaktionsoperationens särdrag, i det så kallade "tvåfasiga" läget, och ibland finns det inget sätt att åtgärda detta förutom att skriva om hela logiken i din procedur. Här är ett enkelt exempel:
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;Ett fel uppstår:
ОШИБКА: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.Då kan du kämpa med dead lock länge i version 10.5, 10.6 och den enda kända räddningen som dödar hela essensen av klustret är att ta bort de "problematiska" tabellerna från klustret, d.v.s. gör make_table_local, men detta kommer åtminstone att låta dig arbeta, och kommer inte att "förstöra" allt på grund av hängande väntetider för transaktionscommits. Eller installera en uppdatering till version 11.2, vilket borde hjälpa, men kanske inte, glöm inte att kolla.
I vissa versioner kan du få ett ännu mer mystiskt lås:
username= mtm и backend_type = background workerOch i den här situationen hjälper det bara att uppdatera DBMS-versionen till 11.2 eller senare, men det kanske inte hjälper.
Vissa indexoperationer kan leda till fel, där det tydligt indikeras att problemet ligger i dubbelriktad replikering, ser du direkt BDR i MTM-loggar. Är det verkligen 2ndQuadrant? Nej... vi köpte multimaster, det är bara en slump, det är namnet på tekniken.
[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 Om du använder temporära tabeller, trots garantierna: "Multimaster-tillägget replikerar data helt automatiskt. Du kan samtidigt utföra skrivtransaktioner och arbeta med temporära tabeller på valfri nod i klustret."
Då får du faktiskt se att replikering inte fungerar för alla tabeller som används i proceduren, om koden innehåller skapandet av en temporär tabell, och även användning av multimaster.remote_functions inte hjälper, måste du uppdatera eller skriva om din logik i proceduren. Om du behöver använda två tillägg samtidigt, multimaster och pg_pathman, inom ramen för "Postgres Pro Enterprise" v 10.5, kontrollera det med ett enkelt exempel:
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);Följande fel börjar visas i loggarna på DBMS-noderna:
…
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
Du kan ta reda på vad dessa fel är från teknisk support, det var inte för inte som du köpte den.
Vad ska man göra? Korrekt! Uppgradera till "Postgres Pro Enterprise" till v 11.2
Separat behöver du veta att sequence, som är ett objekt i en replikerad databas, inte har ett tvärgående värde över hela klustret. Varje sekvens är lokal för varje nod, och om du har fält med unika begränsningar och använder sequence, kan du bara göra en ökning motsvarande nodnumret i klustret. Ju fler noder som finns i klustret, desto snabbare kommer din sekvens att växa, och både sequence och int kommer att ta slut snabbare än du förväntade dig. För att förenkla arbetet med sequence hittar du till och med funktionen alter_sequences i produkten, som gör de nödvändiga ökningarna för varje sekvens på alla noder, men var beredd på att funktionen inte fungerar i alla versioner. Naturligtvis kan du skriva den själv, ta koden från github som grund eller korrigera den själv direkt i DBMS. I det här fallet kommer fält med typen serialbigserial att fungera mer korrekt, men för att använda dem kommer du troligtvis att behöva skriva om koden för dina procedurer och funktioner. Kanske kommer någon att tycka att funktionen monotonic_sequences är användbar.
Före version 11.2 av Postgres Pro Enterprise fungerade replikering bara om det finns unika primärnycklar, så tänk på detta vid design.
Jag vill separat nämna särdragen hos npgsql-operationer i en klusterlösning; dessa problem uppstår inte på en enda nod, utan är fullt närvarande i en multimaster.
I vissa versioner kan du stöta på ett fel:
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. Vad kan man göra? Du behöver helt enkelt inte använda vissa versioner. Du behöver känna till dem, eftersom felet förekommer i mer än en version, och även efter den första korrigeringen kan du stöta på det senare. Du måste också vara beredd på detta, och det är bättre att täcka alla identifierade DBMS-fel som tillverkaren korrigerar med separata regressionstester. Så att säga, lita på, men verifiera.
Om din applikation använder npgsql och växlar mellan noder i tron att de alla är likadana, kan du få ett felmeddelande:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...Det här felet uppstår eftersom bindningen pågår.
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) sammansatta typer när applikationen startas för alla anslutningar. Som ett resultat får vi en identifierare från en nod, och när den begärs på en annan nod matchar den inte, vilket resulterar i att ett fel returneras, d.v.s. det blir omöjligt att transparent arbeta med sammansatta typer i ett kluster för vissa applikationer utan ytterligare omskrivning på applikationssidan (om du lyckas göra detta).
Som vi alla vet är den övergripande bedömningen av klustrets skick mycket viktig för diagnostik och operativa åtgärder under drift. I produkten kan du hitta vissa funktioner som borde göra ditt liv enklare, men ibland kanske de inte ger vad du och ens tillverkaren förväntar sig av dem.
Till exempel:
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")Men varför är LiveNodes-fältet alltid satt till 2, trots att det enligt beskrivningen av multimaster-operationen borde motsvara talet AllNodes=3? Svar: du måste uppdatera DBMS-versionen.
Och var beredd att samla in loggar för alla noder, eftersom du vanligtvis ser "felet finns i loggen för en annan nod". Teknisk support kommer att acceptera alla fel du har identifierat och meddela dig om att nästa version är redo, vilken ibland måste installeras med en avstängning av tjänsten, ibland under en längre tid (beroende på volymen på ditt databasstyrningssystem). Hoppas inte att driftsproblem kommer att störa leverantören i hög grad, och uppdateringen på grund av de identifierade felen kommer att utföras med deltagande av leverantörsrepresentanter, eller snarare, du behöver inte ens involvera leverantörsrepresentanter, eftersom du i slutändan kan få ett demonterat kluster utan säkerhetskopiering i produktionen.
I licensen för den kommersiella produkten varnar tillverkaren faktiskt ärligt: ”Denna programvara tillhandahålls i befintligt skick och Postgres Professional Limited Liability Company är inte skyldigt att tillhandahålla support, underhåll, uppdateringar, tillägg eller ändringar.”
Om du inte redan har gissat vilken produkt vi pratar om, så har all denna erfarenhet vunnits genom ett års användning av Postgres Pro Enterprise-databasen. Du kan dra din egen slutsats: det är så fuktigt att svamp växer.
Men det skulle inte vara så illa om det gjordes i tid och problem som uppstår snabbt åtgärdades.
Men det är precis vad som inte händer. Tydligen har tillverkaren inte tillräckligt med resurser för att snabbt åtgärda de upptäckta buggarna.
Endast registrerade användare kan delta i undersökningen. , Snälla du.
Har du erfarenhet av att byta från ett utländskt/proprietärt DBMS till ett gratis/inhemskt?
21,3%Ja, positiv 10
10,6%Ja, negativ 5
21,3%Nej, DBMS har inte ändrats10
4,3%DBMS ändrades, men ingenting förändrades2
42,6%Visa resultat20
47 användare röstade. 12 användare avstod från att rösta.
Källa: will.com
