(c) Yandex Afbeeldingen
Alle personages zijn fictief, handelsmerken behoren tot hun eigenaars, eventuele overeenkomsten zijn toevallig en dit is in het algemeen mijn 'subjectieve beoordelingsoordeel, breek alstublieft de deur niet...'.
Wij hebben aanzienlijke ervaring met de vertaling van informatiesystemen met logica in de database van het ene databasesysteem naar het andere. In het licht van de regeringsovereenkomst nr. 1236 van 16.11.2016, is dit vaak een vertaling van Oracle naar PostgreSQL. Hoe je het proces zo efficiënt en pijnloos mogelijk kunt organiseren - daar kunnen we apart over praten, vandaag bespreken we de kenmerken van het gebruik van clusters en met welke problemen je kunt worden geconfronteerd bij het opzetten van zwaarbelaste gedistribueerde systemen met complexe logica in procedures en functies.
Spoiler - ja, CAP, RAC en pg multimaster zijn heel verschillende oplossingen.
Stel dat je de hele logica al van PL/SQL naar PG/SQL hebt overgebracht. En je regressietests zijn heel goed, nu denk je natuurlijk aan opschaling, omdat de belastingstests je niet echt blij maken, vooral op de hardware die oorspronkelijk voor dat andere databasesysteem in het project was ingebouwd. Stel dat je een oplossing hebt gevonden van de binnenlandse leverancier 'Postgres Professional' met een optie genaamd 'multimaster', die alleen beschikbaar is in de 'maximale' versie van 'Postgres Pro Enterprise' en volgens de beschrijving - dit lijkt heel erg op wat je nodig hebt, en bij een eerste oppervlakkige studie komt de gedachte op: 'Oh! Dit is precies wat ik nodig heb in plaats van RAC! En met technische ondersteuning in het thuisland!'.
Maar wees niet te snel blij, en verder zullen we beschrijven waarom je op deze nuanceringspunten moet letten, omdat het moeilijk te voorzien is, zelfs als je goed de documentatie van het product leest. Vraag jezelf af of je bereid bent om vaak databaseversies rechtstreeks in de productieomgeving bij te werken, omdat sommige defecten niet compatibel zijn met de industriële exploitatie en moeilijk te ontdekken zijn tijdens tests.
Begin met een zorgvuldige lezing van het gedeelte 'multimaster' - 'beperkingen' op de website van de fabrikant.
Het eerste waar je mee te maken kunt krijgen, zijn de kenmerken van transacties in de zogenaamde 'twee-fasen' modus, en soms kan dit alleen worden opgelost door de hele logica van je procedure opnieuw te schrijven. Hier is een eenvoudig voorbeeld:
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;Er treedt een fout op:
FOUT: [MTM] Transactie MTM-1-2435-10-605783555137701 (10654) is afgebroken op knooppunt 3. Controleer het logboek voor foutdetails.Je kunt lang worstelen met deadlocks in versies 10.5, 10.6, en de enige bekende oplossing die de essentie van de cluster vernietigt, is om de 'problematische' tabellen uit de cluster te verwijderen, dat wil zeggen, maak de tabel lokaal, maar dat laat je in ieder geval werken, in plaats van alles vast te zetten vanwege hangende transactiebevestigingen. Of je kunt updaten naar versie 11.2, wat zou moeten helpen, maar misschien ook niet, vergeet niet te controleren.
In sommige versies kun je een nog mysterieuzere vergrendeling krijgen:
username= mtm en backend_type = achtergrondworkerEn in deze situatie helpt alleen de update van de databaseversie naar 11.2 of hoger, of misschien helpt het ook niet.
Sommige bewerkingen met indexen kunnen leiden tot fouten, waarbij expliciet wordt aangegeven dat het probleem zich in Bi-Directional Replication bevindt; je zult BDR in de MTM-logboeken zien. Is het echt 2ndQuadrant? Nee… we hebben multimaster gekocht, dat is gewoon een samenloop van omstandigheden, dat is de naam van de technologie.
[MTM] bdr ondersteunt geen indexhertests
[MTM] 12124: REMOTE begin abort transactie 4083
[MTM] 12124: stuur ABORT notificatie voor transactie (5467) lokale xid=4083 naar coördinator 3
[MTM] Ontvang ABORT_PREPARED logisch bericht voor transactie MTM-3-25030-83-605694076627780 van knooppunt 3
[MTM] Abort voorbereide transactie MTM-3-25030-83-605694076627780 status InProgress van knooppunt 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448 Als je tijdelijke tabellen gebruikt, ondanks de beweringen: "Het multimaster-uitbreiding repliceert gegevens volledig automatisch. Je kunt gelijktijdig schrijfacties uitvoeren en met tijdelijke tabellen werken op elk knooppunt in de cluster."
Dan krijg je feitelijk dat de replicatie niet werkt voor alle tabellen die in de procedure worden gebruikt, als er in de code een tijdelijke tabel wordt aangemaakt, en zelfs het gebruik van multimaster.remote_functions zal niet helpen; je moet ofwel upgraden of je logica in de procedure herschrijven. Als je gelijktijdig twee extensies, multimaster en pg_pathman wilt gebruiken binnen 'Postgres Pro Enterprise' v 10.5, controleer dan of bij dit eenvoudige voorbeeld:
CREËER TABEL meting (
stad_id int niet null,
logdatum datum niet null,
piektemperatuur int,
eenhedenverkoop int
) PARTITION BY RANGE (logdatum);
CREËER TABEL meting_y2019m06 PARTITION VAN meting VOOR WAARDEN VAN ('2019-06-01') TOT ('2019-07-01');
inserten in meting waarden (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
inserten in meting waarden (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
inserten in meting waarden (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
inserten in meting waarden (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);In de logs van de DB-servers verschijnen de volgende fouten:
…
PATHMAN_CONFIG bevat geen relatie 23245
> find_in_dynamic_libpath: probeert "/opt/.../ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: probeert "/opt//.../ent-10/lib/pg_pathman.so"
> DEBUGGING: find_in_dynamic_libpath: probeert "/opt/.../ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: probeert "/opt/.../ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) naam: unnamed; blockState: PREPARE; staat: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) naam: unnamed; blockState: DEFAULT; staat: INPROGR, xid/subid/cid: 0/1/0
> overgeschakeld naar tijdlijn 1 geldig tot 0/0
…
Transactie MTM-1-13604-7-612438856339841 (6919) is afgebroken op node 2. Controleer zijn log voor foutdetails.
...
[MTM] 28295: AFGELOPEN begin abort transactie 7017
…
[MTM] 28295: stuur ABORT-melding voor transactie (6919) lokale xid=7017 naar coördinator 1
Wat dit voor fouten zijn, kunt u te weten komen bij de technische ondersteuning, u heeft het niet voor niets gekocht.
Wat te doen? Juist! Upgraden naar "Postgres Pro Enterprise" naar v 11.2
Het is belangrijk om te weten dat sequence, als object van de repliceerbare database, niet een doorlopend waarde heeft voor het hele cluster; elke sequence is lokaal voor elke node en als u velden met unieke beperkingen heeft en sequence gebruikt, dan kunt u alleen een increment maken gelijk aan het node-nummer in het cluster, want hoe meer nodes in het cluster, hoe sneller uw sequence zal toenemen, en int zal sneller eindigen dan u had verwacht. Voor het vereenvoudigen van het werken met sequence vindt u zelfs de functie alter_sequences in het product, die de benodigde increments voor elke sequence op alle nodes zal maken, maar wees voorbereid dat de functie niet in alle versies zal werken. Natuurlijk kan het zelf geschreven worden, met de basiscode van github of door het rechtstreeks in de database te wijzigen. Daarbij zullen velden met het type serialbigserial correcter werken, maar voor hun gebruik moet u waarschijnlijk de code van uw procedures en functies herschrijven. Misschien is de functie monotonic_sequences nuttig voor sommigen.
Voor versie 11.2 "Postgres Pro Enterprise" zal replicatie alleen werken met unieke primaire sleutels, houd hier rekening mee bij de ontwikkeling.
Het is belangrijk om te vermelden dat er specifieke kenmerken zijn in de werking van npgsql met betrekking tot clusteroplossingen; deze problemen doen zich niet voor op een enkele node, maar zijn aanwezig in een multimaster.
In sommige versies kan je tegen de fout aanlopen:
Exception Details: Npgsql.PostgresException: 25001: commando SET TRANSACTION ISOLATION LEVEL
Beschrijving: Een niet-afgehandelde uitzondering trad op tijdens de uitvoering van het huidige webverzoek. Zie de stacktrace voor meer informatie over de fout en waar deze in de code is ontstaan. Wat kun je doen? Je moet gewoon bepaalde versies niet gebruiken. Het is belangrijk om hiervan op de hoogte te zijn, aangezien de fout niet in één versie voorkomt, en zelfs na de eerste correctie kun je er later weer mee te maken krijgen. Wees hierop voorbereid en dekken alle bekende defecten in de DBMS die door de producent zijn hersteld met aparte regressietests. Vertrouwen is goed, controle is beter.
Als de applicatie npgsql gebruikt en schakelt tussen nodes in de veronderstelling dat ze allemaal hetzelfde zijn, kan je de volgende fout tegenkomen:
EXCEPTION: Npgsql.PostgresException (0x80004005): XX000: cache-opzoeking mislukt voor type ...Zo'n fout komt voor omdat er binding plaatsvindt
(NpgsqlConnection.GlobalTypeMapper.MapComposite("some_composite_type");) van samengestelde types bij de start van de applicatie voor alle verbindingen. Als gevolg hiervan krijgen we een identificator van een specifieke node, en bij een verzoek op een andere node komt deze niet overeen, waardoor een fout wordt geretourneerd. Dit betekent dat transparant werken met samengestelde types in een cluster voor sommige applicaties onmogelijk zal zijn zonder extra herschrijvingen aan de applicatiezijde (als je dat al kunt doen).
Zoals we allemaal weten, is de algemene beoordeling van de status van het cluster zeer belangrijk voor diagnose en snelle acties tijdens de werking. In het product vind je enkele functies die je leven zouden moeten vergemakkelijken, maar soms kunnen ze iets heel anders teruggeven dan jij en zelfs de fabrikant verwachten.
Bijvoorbeeld:
select mtm.collect_cluster_info();
geeft op elke node hetzelfde resultaat:
(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")Maar waarom staat er in het veld LiveNodes overal het getal 2, terwijl volgens de beschrijving van de werking van de multimaster dit zou moeten overeenkomen met het aantal AllNodes=3? Antwoord: je moet de versie van de DBMS bijwerken.
En wees voorbereid om logs van alle knooppunten te verzamelen, aangezien u meestal zult zien dat 'de fout zich in de log van een ander knooppunt bevindt'. De technische ondersteuning zal alle door u ontdekte defecten accepteren en u informeren wanneer de volgende versie gereed is, die soms moet worden geïnstalleerd met een downtime van de dienst, soms zelfs voor langere tijd (afhankelijk van de omvang van uw DBMS). Verwacht niet dat exploitatieproblemen de leverancier veel zullen storen, en dat de updates vanwege ontdekte defecten met deelname van vertegenwoordigers van de leverancier zullen worden uitgevoerd; sterker nog, het is zelfs beter om geen vertegenwoordigers van de leverancier erbij te betrekken, omdat u uiteindelijk een gedeclareerde cluster zonder back-up op productie kunt krijgen.
In feite waarschuwt de fabrikant in de licentie voor het commerciële product eerlijk: 'Dit softwareproduct wordt verstrekt op basis van het principe 'as is' en de vennootschap met beperkte aansprakelijkheid 'Postgres Professioneel' is niet verplicht om ondersteuning, bijstand, updates, uitbreidingen of wijzigingen te bieden.'
Als u nog niet had geraden over welk product het gaat, dan is al deze ervaring verkregen als gevolg van een jaarlange exploitatie van de Postgres Pro Enterprise-database. U kunt zelf de conclusie trekken, zo vochtig dat er paddenstoelen groeien.
Maar dat zou nog niet zo erg zijn als de opkomende problemen tijdig en efficiënt zouden worden opgelost.
Maar dat is precies wat er niet gebeurt. Blijkbaar heeft de fabrikant niet genoeg middelen om de vastgestelde bugs snel op te lossen.
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. , alstublieft.
Heeft u ervaring met de overstap van een buitenlandse/proprietaire DBMS naar een vrije/thuislandse?
21,3%Ja, positief 10
10,6%Ja, negatief 5
21,3%Nee, DBMS niet gewijzigd 10
4,3%DBMS gewijzigd, maar er is niets veranderd 2
42,6%Bekijk resultaten 20
47 gebruikers hebben gestemd. 12 gebruikers hebben zich onthouden.
Bron: habr.com
