(c) Yandex.Bilder
Alle Charaktere sind fiktional, Marken gehören ihren Eigentümern, jegliche Übereinstimmungen sind zufällig und überhaupt, dies ist mein „subjektives Urteil, bitte schlagen Sie die Tür nicht ein…“.
Wir haben umfangreiche Erfahrung in der Übersetzung von Informationssystemen mit Logik in der Datenbank von einem DBMS in ein anderes. Im Kontext der Regierung Verordnung Nr. 1236 vom 16.11.2016 handelt es sich häufig um die Migration von Oracle zu PostgreSQL. Wie man den Prozess möglichst effizient und schmerzlos gestaltet – darüber können wir gerne gesondert berichten, heute werden wir über die Besonderheiten der Nutzung eines Clusters sprechen und mit welchen Problemen man beim Aufbau von hochbelasteten verteilten Systemen mit komplexer Logik in Prozeduren und Funktionen konfrontiert werden kann.
Spoiler – ja, kappen, RAC und pg multimaster sind sehr unterschiedliche Lösungen.
Angenommen, Sie haben bereits die gesamte Logik von plsql auf pgsql übertragen. Ihre Regressionstests sind ganz in Ordnung, jetzt denken Sie natürlich über die Skalierung nach, da die Lasttests Sie nicht wirklich erfreuen, vor allem nicht mit der Hardware, die ursprünglich für das Projekt vorgesehen war, für das besagte andere DBMS. Angenommen, Sie haben eine Lösung des einheimischen Anbieters „Postgres Professional“ mit einer Option namens „multimaster“ gefunden, die nur in der „maximalen“ Version von „Postgres Pro Enterprise“ verfügbar ist und laut Beschreibung sehr nach dem aussieht, was Sie brauchen, und bei der ersten oberflächlichen Untersuchung kommt einem der Gedanke: „Oh! Statt RAC genau das Richtige! Und auch mit technischer Unterstützung im eigenen Land!“
Aber seien Sie nicht zu voreilig mit Ihrer Freude, wir werden weiter erläutern, warum Sie diese Nuancen kennen sollten, da sie schwer vorherzusehen sind, selbst wenn Sie die Dokumentation des Produkts gut gelesen haben. Überlegen Sie, ob Sie bereit sind, die Versionen der DBMS häufig direkt in der Produktionsumgebung zu aktualisieren, denn einige Fehler sind mit der industriellen Nutzung nicht kompatibel und lassen sich schwer im Teststadium identifizieren.
Beginnen Sie mit einer sorgfältigen Lektüre des Abschnitts „multimaster“ – „Einschränkung“ auf der Website des Herstellers.
Als Erstes kann man auf die Besonderheiten der Transaktionsverarbeitung im sogenannten „Zwei-Phasen“-Modus stoßen, und manchmal lässt sich das außer durch das vollständige Umschreiben der Logik Ihrer Prozedur nicht beheben. Hier ein einfaches Beispiel:
Erstellen Sie die Tabelle test1 (id integer, id1 integer);
Fügen Sie in test1 Werte ein (1, 1),(1, 2);
ÄNDERN SIE DIE TABELLE test1 FÜGE EINSCHRÄNKUNG test1_uk EINDEUTIG HINZU (id,id1) VERSCHIEBBARES INITIALLY VERSCHOBEN;
Aktualisieren Sie test1
set id1 =
case id1
when 1
then 2
else id1 - sign(2 - 1)
end
where id1 zwischen 1 und 2;Es tritt ein Fehler auf:
FEHLER: [MTM] Transaktion MTM-1-2435-10-605783555137701 (10654) ist auf Knoten 3 abgebrochen. Überprüfen Sie das Protokoll, um die Fehlerdetails zu sehen.Man kann lange gegen einen Deadlock in den Versionen 10.5, 10.6 ankämpfen und die einzige bekannte Lösung, die den ganzen Sinn des Clusters beraubt – ist, „problematische“ Tabellen aus dem Cluster zu entfernen, d.h. make_table_local zu verwenden, was zumindest die Arbeit ermöglicht, ohne alles wegen feststeckender Erwartung von Transaktionsfixierungen zum Stillstand zu bringen. Oder man aktualisiert auf Version 11.2, die helfen sollte, vielleicht aber auch nicht, vergessen Sie nicht, das zu überprüfen.
In einigen Versionen können Sie eine noch mysteriösere Sperre erhalten:
benutzername= mtm und backend_type = HintergrundarbeiterUnd in dieser Situation hilft Ihnen nur ein Upgrade der DBMS-Version auf 11.2 oder höher, kann aber auch nicht helfen.
Einige Operationen mit Indizes können zu Fehlern führen, in denen ausdrücklich angegeben wird, dass das Problem in der Bi-Directional Replication liegt, in den MTM-Protokollen werden Sie direkt BDR sehen. Ist das wirklich 2ndQuadrant? Nein, wir haben multimaster gekauft, das ist nur ein Zufall, das ist der Name der Technologie.
[MTM] bdr unterstützt keine Indexüberprüfungen
[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 Wenn Sie temporäre Tabellen verwenden, trotz der Zusicherungen: „Die Erweiterung multimaster realisiert die Replikation von Daten vollständig automatisch. Sie können gleichzeitig schreibende Transaktionen ausführen und mit temporären Tabellen auf jedem Knoten des Clusters arbeiten.“
Dann erhalten Sie tatsächlich, dass die Replikation nicht für alle Tabellen funktioniert, die in der Prozedur verwendet werden, wenn im Code die Erstellung einer temporären Tabelle vorhanden ist, und selbst die Verwendung von multimaster.remote_functions wird nicht helfen, Sie müssen aktualisieren oder Ihre Logik in der Prozedur umschreiben. Wenn Sie gleichzeitig zwei Erweiterungen multimaster und pg_pathman im Rahmen von „Postgres Pro Enterprise“ v 10.5 verwenden müssen, überprüfen Sie, dass bei so einem einfachen Beispiel:
ERSTELLE TABELLE Messung (
stadt_id int nicht null,
logdatum datum nicht null,
spitzentemp int,
einheitenverkauf int
) PARTITION BY RANGE (logdatum);
ERSTELLE TABELLE Messung_y2019m06 TEIL VON Messung FÜR WERTE VON ('2019-06-01') BIS ('2019-07-01');
füge in Messung Werte ein (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
füge in Messung Werte ein (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
füge in Messung Werte ein (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
füge in Messung Werte ein (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);In den Protokollen der DB-Knoten treten solche Fehler auf:
…
PATHMAN_CONFIG enthält keine Relation 23245
> find_in_dynamic_libpath: versucht "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: versucht "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> DEBUG: find_in_dynamic_libpath: versucht "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: versucht "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) Name: unnamed; blockState: PREPARE; Zustand: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) Name: unnamed; blockState: DEFAULT; Zustand: INPROGR, xid/subid/cid: 0/1/0
> zu Zeitachse 1 gewechselt gültig bis 0/0
…
Transaktion MTM-1-13604-7-612438856339841 (6919) wird auf Knoten 2 abgebrochen. Überprüfen Sie sein Protokoll, um Fehlerdetails zu sehen.
...
[MTM] 28295: REMOTE begin abgebrochene Transaktion 7017
…
[MTM] 28295: send ABORT-Benachrichtigung für Transaktion (6919) lokale xid=7017 an Koordinator 1
Was das für Fehler sind, erfahren Sie beim technischen Support, schließlich haben Sie ihn nicht umsonst gekauft.
Was tun? Richtig! Auf „Postgres Pro Enterprise“ auf v 11.2 aktualisieren.
Es ist wichtig zu wissen, dass die Sequenz, als Objekt einer replizierbaren DB, keineswegs einen durchgehenden Wert im gesamten Cluster hat, jede Sequenz ist lokal für jeden Knoten. Wenn Sie Felder mit eindeutigen Einschränkungen haben und Sequenzen verwenden, können Sie nur eine Erhöhung entsprechend der Knotennummer im Cluster vornehmen, da die Anzahl der Knoten im Cluster die Geschwindigkeit erhöht, mit der Ihre Sequenz wächst, und die int schneller endet, als Sie dachten. Zur Vereinfachung der Arbeit mit Sequenzen finden Sie in dem Produkt sogar die Funktion alter_sequences, die die notwendigen Erhöhungen für jede Sequenz an allen Knoten vornimmt, aber seien Sie gewarnt, dass die Funktion nicht in allen Versionen funktioniert. Natürlich könnte man sie selbst schreiben, indem man den Code von github verwendet oder direkt in der DB anpasst. Bei diesem Vorgang werden Felder vom Typ serialbigserial korrekter funktionieren, jedoch müssen Sie möglicherweise den Code Ihrer Prozeduren und Funktionen umschreiben. Möglicherweise wird die Funktion monotonic_sequences für einige nützlich sein.
Vor Version 11.2 von „Postgres Pro Enterprise“ wird die Replikation nur funktionieren, wenn eindeutige Primärschlüssel vorhanden sind. Berücksichtigen Sie dies bei der Entwicklung.
Besonders möchte ich auf die spezifischen Eigenschaften von npgsql in einer Clusterlösung hinweisen, diese Probleme treten nicht in einer Single-Node-Umgebung auf, sind jedoch im Multi-Master-Modus durchaus vorhanden.
In einigen Versionen kann man auf den folgenden Fehler stoßen:
Exception Details: Npgsql.PostgresException: 25001: Befehl SET TRANSACTION ISOLATION LEVEL
Beschreibung: Während der Ausführung der aktuellen Webanfrage ist eine nicht behandelte Ausnahme aufgetreten. Bitte überprüfen Sie den Stack-Trace für weitere Informationen über den Fehler und den Ort, an dem er im Code entstanden ist. Was kann man tun? Einfach einige Versionen nicht verwenden. Man muss sie kennen, da der Fehler nicht nur in einer Version auftritt und selbst nach der ersten Korrektur kann man ihm später wieder begegnen. Auch darauf sollte man vorbereitet sein und es ist besser, alle identifizierten Fehler der DBMS, die vom Hersteller behoben werden, mit separaten Regressionstests zu überprüfen. Sozusagen: Vertraue, aber überprüfe.
Wenn die Anwendung npgsql verwendet und zwischen den Knoten wechselt, in der Annahme, dass sie alle gleich sind, kann es zu folgendem Fehler kommen:
EXCEPTION: Npgsql.PostgresException (0x80004005): XX000: Cache-Lookup für Typ fehlgeschlagen ...Ein solcher Fehler tritt auf, da die Bindung
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) von kompositen Typen beim Start der Anwendung für alle Verbindungen durchgeführt wird. Infolgedessen erhalten wir eine ID von einem bestimmten Knoten, und bei der Abfrage an einem anderen Knoten stimmt diese nicht überein, was zu einem Fehler führt; das transparente Arbeiten mit kompositen Typen in einem Cluster wird für einige Anwendungen ohne zusätzliche Anpassungen auf der Anwendungsebene unmöglich sein (wenn Sie es schaffen, dies zu tun).
Wie wir alle wissen, ist die allgemeine Bewertung des Zustands des Clusters sehr wichtig für die Diagnose und schnelle Maßnahmen bei der Arbeit, im Produkt finden Sie einige Funktionen, die Ihnen das Leben erleichtern sollten, aber manchmal können sie völlig andere Ergebnisse liefern, als Sie und selbst der Hersteller erwarten.
Zum Beispiel:
select mtm.collect_cluster_info();
auf jedem Knoten liefert dasselbe Ergebnis:
(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")Aber warum zeigt das Feld LiveNodes überall die Zahl 2 an, obwohl die Beschreibung der Funktionsweise des Multi-Masters der Anzahl AllNodes=3 entsprechen sollte? Antwort: Die Version der DBMS muss aktualisiert werden.
Seien Sie bereit, Protokolle von allen Knoten zu sammeln, da Sie normalerweise "Der Fehler befindet sich im Protokoll eines anderen Knotens" sehen werden. Der technische Support wird alle von Ihnen festgestellten Mängel zur Kenntnis nehmen und über die Verfügbarkeit der nächsten Version informieren, die manchmal erfordert, dass der Dienst gestoppt wird, und manchmal für längere Zeit (abhängig vom Umfang Ihrer Datenbank). Es ist nicht zu erwarten, dass Probleme beim Betrieb den Anbieter stark belasten, und Aktualisierungen aufgrund von festgestellten Mängeln werden nicht mit Unterstützung von Vertretern des Anbieters durchgeführt. Tatsächlich sollte man Vertreter des Anbieters nicht hinzuziehen, da Sie letztendlich einen auf dem Produktivsystem zerlegten Cluster ohne Backup erhalten könnten.
Tatsächlich warnt der Hersteller in der Lizenz für das kommerzielle Produkt ehrlich: "Diese Software wird unter dem Prinzip "wie sie ist" bereitgestellt, und die Gesellschaft mit beschränkter Haftung "Postgres Professionell" ist nicht verpflichtet, Wartung, Unterstützung, Aktualisierungen, Erweiterungen oder Änderungen bereitzustellen."
Wenn Sie noch nicht erraten haben, um welches Produkt es sich handelt, dann wurde all diese Erfahrung durch ein Jahr Betrieb der Postgres Pro Enterprise-Datenbank gewonnen. Sie können selbst zu dem Schluss kommen, es ist so feucht, dass Pilze wachsen.
Das wäre nicht einmal so schlimm, wenn die auftretenden Probleme rechtzeitig und umgehend behoben würden.
Aber genau das passiert nicht. Offensichtlich hat der Hersteller nicht genügend Ressourcen, um die festgestellten Bugs umgehend zu beheben.
Nur registrierte Benutzer können an der Umfrage teilnehmen. .
Haben Sie Erfahrungen mit dem Umstieg von ausländischen/eigenen Datenbanksystemen auf freie/heimische gemacht?
21,3%Ja, positiv10
10,6%Ja, negativ5
21,3%Nein, das Datenbanksystem wurde nicht gewechselt10
4,3%Das Datenbanksystem wurde gewechselt, aber es hat sich nichts geändert2
42,6%Die Ergebnisse anzeigen20
47 Benutzer haben abgestimmt. 12 Benutzer haben sich enthalten.
Quelle: habr.com
