(ts) Yandex.Images
Alle karakters zijn fictief, handelsmerken zijn eigendom van hun eigenaren, eventuele overeenkomsten zijn willekeurig en in het algemeen is dit mijn “subjectieve waardeoordeel, breek alsjeblieft niet de deur open...”.
We hebben veel ervaring met het overbrengen van informatiesystemen met logica naar een database van het ene DBMS naar het andere. In het kader van regeringsdecreet nr. 1236 van 16.11.2016 november XNUMX is dit vaak een overdracht van Oracle naar Postgresql. We kunnen u afzonderlijk vertellen hoe u het proces zo efficiënt en pijnloos mogelijk kunt organiseren. Vandaag zullen we het hebben over de kenmerken van het gebruik van een cluster en welke problemen u kunt tegenkomen bij het bouwen van zwaarbelaste gedistribueerde systemen met complexe logica in procedures en functies.
Spoiler – ja, cap, RAC en pg multimaster zijn heel verschillende oplossingen.
Stel dat u alle logica al van plsql naar pgsql hebt overgebracht. En je regressietesten zijn prima in orde, nu denk je natuurlijk aan opschaling, want... Van belastingtests word je niet erg blij, vooral niet van de hardware die oorspronkelijk in het project zat, voor dat heel andere DBMS. Laten we zeggen 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 - deze lijkt erg op wat je nodig hebt, en bij de eerste oppervlakkige studie zal de gedachte in mijn hoofd opkomen: “Oh! In plaats van RAC, dat is het! En zelfs met een technische pijplijn in ons thuisland!”
Maar haast je niet om je te verheugen, en verder zullen we beschrijven waarom je deze nuances moet kennen, omdat... ze zijn moeilijk te voorspellen, zelfs na het grondig lezen van de productdocumentatie. Beoordeel of u klaar bent om DBMS-versies regelmatig rechtstreeks op de productiesite bij te werken, omdat Sommige defecten zijn niet compatibel met industrieel gebruik en zijn moeilijk te detecteren tijdens het testen.
Begin met het zorgvuldig lezen van het gedeelte "multimaster" - "beperkingen" op de website van de fabrikant.
Het eerste dat u tegen kunt komen, zijn de eigenaardigheden van de manier waarop transacties werken, in het zogenaamde. “tweefasige” modus, en soms is er geen manier om dit op te lossen, behalve door de hele logica van uw procedure te herschrijven. 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:
ОШИБКА: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.Dan kun je in versies 10.5, 10.6 lange tijd met een dead lock vechten, en de enige bekende oplossing die de hele essentie van het cluster doodt, is het verwijderen van ‘probleemtabellen’ uit het cluster, d.w.z. doe make_table_local, maar hierdoor kan het in ieder geval werken en wordt niet alles in de wacht gezet vanwege hangende wachttijden voor transactie-commits. Nou, of installeer een update naar versie 11.2, wat zou moeten helpen, maar misschien ook niet, vergeet niet om dit te controleren.
In sommige versies kun je een nog mysterieuzer slot krijgen:
username= mtm и backend_type = background workerEn in deze situatie zal alleen het updaten van de DBMS-versie naar 11.2 en hoger u helpen, of misschien helpt het niet.
Sommige bewerkingen met indexen kunnen tot fouten leiden, wat duidelijk aangeeft dat het probleem bij bidirectionele replicatie ligt; u ziet BDR direct in de MTM-logboeken. Is het echt het tweede kwadrant? Nee... we hebben een multimaster gekocht, het is gewoon toeval, het is de naam van de technologie.
[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 Als u ondanks de garanties tijdelijke tabellen gebruikt: “De multimaster-extensie voert de gegevensreplicatie volledig automatisch uit. Je kunt tegelijkertijd schrijftransacties uitvoeren en met tijdelijke tabellen werken op elk knooppunt in het cluster.”
Dan zul je in feite merken dat replicatie niet werkt voor alle tabellen die in de procedure worden gebruikt. Als de code het maken van een tijdelijke tabel bevat, en zelfs het gebruik van multimaster.remote_functions niet helpt, zul je je logica moeten bijwerken of herschrijven in De procedure. Als u twee extensies multimaster en pg_pathman tegelijkertijd moet gebruiken binnen Postgres Pro Enterprise v 10.5, controleer dat dan met dit eenvoudige voorbeeld:
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);De volgende fouten verschijnen in de logboeken op de DBMS-knooppunten:
…
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
Wat deze fouten zijn, kunt u vinden in de technische ondersteuning, het is niet voor niets dat u het heeft gekocht.
Wat moeten we doen? Rechts! Upgrade naar "Postgres Pro Enterprise" v 11.2
Daarnaast moet u weten dat de reeks, omdat deze een object is van een gerepliceerde database, geen end-to-end waarde heeft in het hele cluster, dat elke reeks lokaal is voor elk knooppunt en dat als u velden heeft met unieke beperkingen en een reeks gebruikt, dan kunt u alleen een verhoging maken die gelijk is aan het knooppuntnummer in het cluster, omdat Zoveel mogelijk knooppunten in het cluster, sequence en int zullen sneller groeien dan je had verwacht. Om het werken met reeksen in het product te vereenvoudigen, vindt u zelfs de functie alter_sequences, die de nodige stappen voor elke reeks op alle knooppunten zal maken, maar wees erop voorbereid dat de functie niet in alle versies zal werken. Je kunt het uiteraard zelf schrijven, met de code uit github als basis, of het zelf direct in het DBMS corrigeren. In dit geval zullen velden met het serialbigserial-type correcter werken, maar om ze te gebruiken moet u hoogstwaarschijnlijk de code van uw procedures en functies herschrijven. Misschien vindt iemand de functie monotonic_sequences nuttig.
Vóór versie 11.2 van Postgres Pro Enterprise werkte replicatie alleen als er unieke primaire sleutels zijn, houd hier rekening mee bij het ontwikkelen.
Afzonderlijk zou ik de eigenaardigheden willen noemen van hoe npgsql werkt in een clusteroplossing; deze problemen doen zich niet voor op een enkel knooppunt, maar zijn behoorlijk aanwezig in een multimaster.
In sommige versies kunt u een fout tegenkomen:
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. Wat gedaan kan worden? Sommige versies moet je gewoon niet gebruiken. Je moet ze kennen, want... De fout komt in meer dan één versie voor en zelfs na de eerste oplossing kunt u deze later nog tegenkomen. Ook hierop moet je voorbereid zijn en het is beter om alle geïdentificeerde DBMS-defecten die door de fabrikant gecorrigeerd worden af te dekken met aparte regressietesten. Om zo te zeggen: vertrouw, maar verifieer.
Als de toepassing npgsql gebruikt en tussen knooppunten schakelt, denkend dat ze allemaal hetzelfde zijn, krijgt u mogelijk een foutmelding:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...Deze fout treedt op omdat de binding bezig is
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) samengestelde typen bij het opstarten van de applicatie voor alle verbindingen. Als gevolg hiervan krijgen we een identificatie van het ene knooppunt en bij het aanvragen op een ander knooppunt komt deze niet overeen, waardoor een fout wordt geretourneerd, d.w.z. Transparant werken met samengestelde typen in een cluster zal voor sommige applicaties niet mogelijk zijn zonder extra herschrijvingen aan de applicatiezijde (als het je lukt om dit te doen).
Zoals we allemaal weten, is een algemene beoordeling van de staat van het cluster erg belangrijk voor diagnostiek en operationele maatregelen tijdens het gebruik. In het product vindt u enkele functies die uw leven gemakkelijker zouden moeten maken, maar soms kunnen ze iets heel anders geven dan wat u en zelfs de fabrikant zelf verwachten van hen dat u verwacht.
Bijvoorbeeld:
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")Maar waarom bevat het LiveNodes-veld overal het getal 2, terwijl dit volgens de beschrijving van de werking van de multimaster zou moeten overeenkomen met het getal AllNodes=3? Antwoord: u moet de DBMS-versie bijwerken.
En wees voorbereid op het verzamelen van logboeken voor alle knooppunten, want... meestal ziet u "de fout staat in het logboek van een ander knooppunt." De technische ondersteuning accepteert alle defecten die u identificeert en informeert u dat de volgende versie gereed is, die soms geïnstalleerd moet worden terwijl de service gestopt is, soms voor een lange tijd (afhankelijk van de grootte van uw DBMS). U moet niet hopen dat operationele problemen de leverancier enorm zullen storen, en dat de update als gevolg van geïdentificeerde defecten zal worden uitgevoerd met medewerking van de vertegenwoordigers van de leverancier, of beter gezegd, u hoeft niet eens de vertegenwoordigers van de leverancier erbij te betrekken, aangezien in de Uiteindelijk kun je eindigen met een gedemonteerd cluster in productie zonder back-up.
Eigenlijk waarschuwt de fabrikant in de licentie voor een commercieel product eerlijk: “Deze software wordt geleverd op een “as is”-basis en Postgres Professional Limited Liability Company is niet verplicht om onderhoud, ondersteuning, updates, uitbreidingen of wijzigingen te leveren.”
Als je nog niet hebt geraden over welk product we het hebben, dan is al deze ervaring opgedaan als resultaat van het jarenlange gebruik van de Postgres Pro Enterprise-database. Je mag zelf wel concluderen dat het zo vochtig is dat er paddenstoelen groeien.
Maar dit zou niet zo erg zijn als het tijdig zou gebeuren en opkomende problemen onmiddellijk zouden worden geëlimineerd.
Maar dit is precies wat er niet gebeurt. Blijkbaar beschikt de fabrikant niet over voldoende middelen om geïdentificeerde bugs onmiddellijk te elimineren.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Heeft u ervaring met het overstappen van een buitenlands/eigen DBMS naar een gratis/binnenlands DBMS?
21,3%Ja, positief10
10,6%Ja, negatief5
21,3%Nee, het DBMS is niet gewijzigd10
4,3%Het DBMS is gewijzigd, maar er is niets veranderd2
42,6%Bekijk resultaten20
47 gebruikers hebben gestemd. 12 gebruikers onthielden zich van stemming.
Bron: www.habr.com
