(c) Yandex.Pictures
Alle Charaktere sind fiktiv, Marken gehören ihren Eigentümern, Zufälle sind zufällig und im Allgemeinen ist dies mein "subjektives Werturteil, bitte nicht die Tür aufbrechen ...".
Wir haben umfangreiche Erfahrungen mit der Übersetzung von Informationssystemen mit Logik in der Datenbank von einem DBMS in ein anderes. Im Rahmen des Regierungsdekrets Nr. 1236 vom 16.11.2016 handelt es sich häufig um eine Übergabe von Oracle an Postgresql. So organisieren Sie den Prozess so effizient und reibungslos wie möglich - wir können es Ihnen separat erklären. Heute werden wir über die Funktionen der Verwendung eines Clusters sprechen und über die Probleme, die beim Aufbau hoch ausgelasteter verteilter Systeme mit komplexer Logik in Prozeduren und Funktionen auftreten können.
Spoiler - yes cap, RAC und pg multimaster sind sehr unterschiedliche Lösungen.
Angenommen, Sie haben bereits die gesamte Logik von pl \ sql nach pg \ sql übertragen. Und Ihre Regressionstests sind ganz in Ordnung, jetzt denken Sie natürlich über Skalierung nach, weil Auslastungstests sind für Sie nicht sehr erfreulich, insbesondere bei der Hardware, die ursprünglich im Projekt unter diesem sehr unterschiedlichen DBMS festgelegt wurde. Angenommen, Sie haben eine Lösung des inländischen Anbieters "Postgres Professional" mit der Option "multimaster" gefunden, die nur in der "maximum" -Version von "Postgres Pro Enterprise" verfügbar ist. Die Beschreibung ähnelt derjenigen, die Sie benötigen, und wenn Sie sie zum ersten Mal untersuchen in meinem Kopf der Gedanke: „Oh! Anstelle von RAC also! Ja und mit der technischen Pipeline in der Heimat! “
Aber beeilen Sie sich nicht, um sich zu freuen, und wir werden weiter beschreiben, warum Sie diese Nuancen kennen müssen, weil Sie sind schwer vorstellbar, auch wenn Sie die Produktdokumentation gut gelesen haben. Prüfen Sie, ob Sie bereit sind, die DBMS-Version regelmäßig direkt am Industriestandort zu aktualisieren Einige Defekte sind nicht mit dem industriellen Betrieb vereinbar und beim Testen schwer zu erkennen.
Lesen Sie zunächst den Abschnitt "Multimaster" - "Einschränkung" auf der Website des Herstellers sorgfältig durch.
Das erste, worauf Sie stoßen können, sind die Merkmale des Vorgangs von Transaktionen, sogenannte "Zwei-Phasen" -Modus, und manchmal, außer durch Umschreiben der gesamten Logik Ihrer Prozedur, kann dies nicht behoben werden. Hier ist ein einfaches Beispiel:
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;
Ein Fehler tritt auf:
: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.
Dann können Sie in den Versionen 10.5, 10.6 lange gegen Deadlock kämpfen, und die einzige bekannte Rettung, die das gesamte Wesen des Clusters zunichte macht, besteht darin, die "Problem" -Tabellen aus dem Cluster zu entfernen, d. H. Sie müssen make_table_local ausführen, aber zumindest können Sie damit arbeiten, und es wird nicht alles "abgesteckt", weil die Erwartungen an das Ausführen von Transaktionen hängen. Nun, oder setzen Sie ein Update auf Version 11.2, die helfen sollte, oder vielleicht nicht, vergessen Sie nicht, zu überprüfen.
In einigen Versionen können Sie eine noch mysteriösere Sperre erhalten:
username= mtm backend_type = background worker
Und in dieser Situation hilft es möglicherweise nicht, nur die DBMS-Version auf 11.2 oder höher zu aktualisieren.
Einige Vorgänge mit Indizes können zu Fehlern führen, bei denen eindeutig angezeigt wird, dass das Problem in der bidirektionalen Replikation liegt. In MTM-Protokollen wird BDR direkt angezeigt. Wirklich 2.Quadrant? Oh nein ... wir haben einen Multimaster gekauft, es ist nur ein Zufall, es ist der Name der 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
Wenn Sie trotz der Zusicherungen temporäre Tabellen verwenden: „Die Multimaster-Erweiterung repliziert Daten vollständig automatisch. "Sie können auf jedem Knoten im Cluster gleichzeitig Transaktionen schreiben und mit temporären Tabellen arbeiten."
In der Tat werden Sie dann feststellen, dass die Replikation nicht für alle in der Prozedur verwendeten Tabellen funktioniert, wenn der Code die Erstellung einer temporären Tabelle enthält und selbst die Verwendung von multimaster.remote_functions nicht hilft, müssen Sie Ihre Logik in der Prozedur aktualisieren oder neu schreiben. Wenn Sie im Rahmen von Postgres Pro Enterprise 10.5 zwei Erweiterungen multimaster und pg_pathman gleichzeitig verwenden müssen, überprüfen Sie dies anhand des folgenden einfachen Beispiels:
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);
Die folgenden Fehler beginnen, die Protokolle auf den DBMS-Knoten einzugeben:
… 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
Sie können herausfinden, was diese Fehler im technischen Support sind. Sie haben ihn nicht umsonst gekauft.
Was zu tun ist? Richtig! Aktualisieren Sie auf Postgres Pro Enterprise auf Version 11.2
Sie müssen separat wissen, dass es als Objekt einer replizierten Datenbank keinen übergreifenden Wert im gesamten Cluster gibt, dass jede Sequenz für jeden Knoten lokal ist und dass Sie nur die Knotennummer erhöhen können, wenn Sie Felder mit eindeutigen Einschränkungen und einer eindeutigen Verwendungsreihenfolge haben Cluster, weil Wie viele Knoten im Cluster sind so viel schneller, dass die Sequenz wächst und int schneller als erwartet endet. Um das Arbeiten mit Sequenzen im Produkt zu vereinfachen, finden Sie sogar die Funktion alter_sequences, mit der die erforderlichen Inkremente für jede Sequenz auf allen Knoten vorgenommen werden, Sie müssen jedoch darauf vorbereitet sein, dass die Funktion nicht in allen Versionen funktioniert. Natürlich können Sie es selbst schreiben, indem Sie den Code von github als Grundlage nehmen oder sich direkt im DBMS korrigieren. Gleichzeitig funktionieren Felder vom Typ serial \ bigserial korrekter. Um sie jedoch zu verwenden, müssen Sie wahrscheinlich den Code Ihrer Prozeduren und Funktionen neu schreiben. Vielleicht findet jemand die Funktion monotonic_sequences nützlich.
Vor Version 11.2 von Postgres Pro Enterprise funktioniert die Replikation nur, wenn eindeutige Primärschlüssel vorhanden sind. Beachten Sie dies beim Entwerfen.
Ich möchte auch die Funktionen von npgsql in einer Cluster-Lösung erwähnen, diese Probleme treten nicht auf einem einzelnen Knoten auf, sondern sind im Multimaster durchaus vorhanden.
In einigen Versionen kann ein Fehler auftreten:
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.
Was kann getan werden? Verwenden Sie nur einige Versionen nicht. Sie müssen sie kennen, weil Der Fehler tritt in einer Version nicht auf, und selbst nach der ersten Korrektur kann er später auftreten. Sie müssen auch darauf vorbereitet sein und es ist am besten, alle vom Hersteller behobenen DBMS-Fehler zu identifizieren und sie mit separaten Regressionstests abzudecken. Vertrauen sozusagen, aber verifizieren.
Wenn die Anwendung npgsql verwendet und zwischen Knoten wechselt, die glauben, dass sie alle gleich sind, wird möglicherweise eine Fehlermeldung angezeigt:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...
Ein solcher Fehler wird dadurch verursacht, dass die Bindung
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");)
zusammengesetzte Typen beim Start der Anwendung für alle Verbindungen. Infolgedessen erhalten wir die Kennung von einem der Knoten, und wenn sie auf einem anderen Knoten angefordert wird, stimmt sie nicht überein, wodurch ein Fehler zurückgegeben wird, d. H. Das transparente Arbeiten mit zusammengesetzten Typen in einem Cluster ist für einige Anwendungen ohne zusätzliche Überschreibungen auf der Anwendungsseite nicht möglich (sofern dies erfolgreich ist).
Wie wir alle wissen, ist eine allgemeine Einschätzung des Status des Clusters für Diagnose- und Betriebsmaßnahmen während der Arbeit sehr wichtig. Im Produkt finden Sie einige Funktionen, die Ihnen das Leben erleichtern sollen, aber manchmal produzieren sie überhaupt nicht das, was Sie und sogar der Hersteller selbst daraus erwarten.
Zum Beispiel:
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")
Aber warum steht überall im Feld LiveNodes die Nummer 2, obwohl sie laut Beschreibung der Arbeit des Multimasters der Nummer AllNodes = 3 entsprechen sollte? Antwort: Sie müssen die DBMS-Version aktualisieren.
Und seien Sie bereit, Protokolle auf allen Knoten zu sammeln In der Regel wird angezeigt, dass sich der Fehler im Protokoll eines anderen Knotens befindet. TechSupport akzeptiert alle erkannten Fehler und teilt Ihnen mit, dass die nächste Version bereit ist, die manchmal bei angehaltenem Dienst, manchmal für längere Zeit (abhängig vom Umfang Ihres DBMS) installiert werden muss. Es ist nicht zu hoffen, dass die Betriebsprobleme den Anbieter stark stören und die Aktualisierung aufgrund von festgestellten Fehlern unter Beteiligung der Vertreter des Anbieters durchgeführt wird, oder es ist nicht einmal erforderlich, die Vertreter des Anbieters einzubeziehen, da Sie am Ende einen zerlegten Cluster ohne Sicherung des Produkts erhalten können.
Tatsächlich warnt der Hersteller in der Lizenz für ein kommerzielles Produkt ehrlich: „Diese Software wird„ wie besehen “bereitgestellt und die Postgres Professional GmbH ist nicht verpflichtet, Support, Support, Updates, Erweiterungen oder Änderungen bereitzustellen.“
Wenn Sie nicht erraten haben, um welche Art von Produkt es sich handelt, haben Sie all diese Erfahrungen durch den jährlichen Betrieb der Postgres Pro Enterprise-Basis gesammelt. Sie können selbst eine Schlussfolgerung ziehen, so feucht, dass Pilze wachsen.
Aber es wäre die halbe Mühe, wenn es rechtzeitig durchgeführt und die auftretenden Probleme umgehend beseitigt würden.
Aber das passiert einfach nicht. Offensichtlich reichen die Ressourcen des Herstellers nicht aus, um die erkannten Fehler schnell zu beheben.