„Profi, aber kein Cluster“ oder wie wir importierte DBMS ersetzt haben

(ts) Yandex.Images

Alle Charaktere sind fiktiv, Marken gehören ihren Eigentümern, etwaige Ähnlichkeiten sind zufällig und im Allgemeinen ist dies mein „subjektives Werturteil, bitte brechen Sie nicht die Tür auf ...“.

Wir verfügen über umfangreiche Erfahrung in der Übertragung von Informationssystemen mit Logik in eine Datenbank von einem DBMS auf ein anderes. Im Rahmen des Regierungserlasses Nr. 1236 vom 16.11.2016. November XNUMX handelt es sich häufig um eine Übertragung von Oracle zu Postgresql. Wir können Ihnen separat sagen, wie Sie den Prozess so effizient und schmerzlos wie möglich organisieren können. Heute werden wir über die Merkmale der Verwendung eines Clusters sprechen und darüber, welche Probleme beim Aufbau hochbelasteter verteilter Systeme mit komplexer Logik in Prozeduren und Funktionen auftreten können.

Spoiler – ja, Cap, RAC und PG Multimaster sind sehr unterschiedliche Lösungen.

Nehmen wir an, Sie haben bereits die gesamte Logik von plsql nach pgsql übertragen. Und Ihre Regressionstests sind ganz in Ordnung, jetzt denken Sie natürlich über eine Skalierung nach, weil... Lasttests machen Sie nicht besonders glücklich, insbesondere auf der Hardware, die ursprünglich im Projekt enthalten war, für dieses völlig andere DBMS. Nehmen wir an, Sie haben eine Lösung des inländischen Anbieters „Postgres Professional“ mit einer Option namens „Multimaster“ gefunden, die nur in der „Maximum“-Version von „Postgres Pro Enterprise“ verfügbar ist und laut Beschreibung dem sehr ähnlich ist Sie brauchen, und beim ersten oberflächlichen Studium kam mir der Gedanke: „Oh! Das ist es statt RAC! Und das sogar mit einer technischen Pipeline in unserer Heimat!“

Aber beeilen Sie sich nicht, sich zu freuen, und weiter werden wir beschreiben, warum Sie diese Nuancen kennen müssen, denn... Sie sind selbst nach gründlicher Lektüre der Produktdokumentation schwer vorherzusagen. Beurteilen Sie, ob Sie bereit sind, DBMS-Versionen häufig direkt am Produktionsstandort zu aktualisieren, denn Einige Mängel sind nicht mit dem industriellen Einsatz vereinbar und bei der Prüfung schwer zu erkennen.
Lesen Sie zunächst sorgfältig den Abschnitt „Multimaster“ – „Einschränkungen“ auf der Website des Herstellers.

Das erste, was Ihnen möglicherweise auffällt, sind die Besonderheiten der Funktionsweise von Transaktionen, im sogenannten. „Zwei-Phasen“-Modus, und manchmal gibt es keine Möglichkeit, dieses Problem zu beheben, außer indem Sie die gesamte Logik Ihrer Prozedur neu schreiben. 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;

Es tritt ein Fehler 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 und 10.6 lange Zeit mit Deadlocks kämpfen, und die einzige bekannte Lösung, die das gesamte Wesen des Clusters zunichte macht, besteht darin, „Problemtabellen“ aus dem Cluster zu entfernen, d. h. Führen Sie make_table_local aus, aber dadurch funktioniert es zumindest und es wird nicht alles auf Eis gelegt, weil Wartezeiten auf Transaktions-Commits hängen bleiben. Nun, oder installieren Sie ein Update auf Version 11.2, das sollte helfen, aber vielleicht auch nicht, vergessen Sie nicht, es zu überprüfen.

In einigen Versionen gibt es ein noch mysteriöseres Schloss:

username= mtm и backend_type = background worker

Und in dieser Situation hilft Ihnen nur die Aktualisierung der DBMS-Version auf 11.2 und höher, oder vielleicht auch nicht.

Einige Vorgänge mit Indizes können zu Fehlern führen, die eindeutig darauf hinweisen, dass das Problem bei der bidirektionalen Replikation liegt; Sie werden BDR direkt in den MTM-Protokollen sehen. Ist es wirklich der 2.Quadrant? Nein... wir haben einen Multimaster gekauft, das 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 führt die Datenreplikation völlig automatisch durch.“ Sie können auf jedem Knoten im Cluster gleichzeitig Schreibtransaktionen durchführen und mit temporären Tabellen arbeiten.“

Dann werden Sie tatsächlich feststellen, dass die Replikation nicht über alle in der Prozedur verwendeten Tabellen hinweg 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 aktualisieren oder neu schreiben das Verfahren. Wenn Sie in Postgres Pro Enterprise v 10.5 zwei Erweiterungen multimaster und pg_pathman gleichzeitig verwenden müssen, überprüfen Sie dies anhand dieses 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);

In den Protokollen auf den DBMS-Knoten werden die folgenden Fehler angezeigt:

…
 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

Was diese Fehler sind, können Sie im technischen Support herausfinden, es ist nicht umsonst, dass Sie es gekauft haben.

Was zu tun ist? Rechts! Upgrade auf „Postgres Pro Enterprise“ v 11.2

Unabhängig davon müssen Sie wissen, dass die Sequenz als Objekt einer replizierten Datenbank keinen End-to-End-Wert im gesamten Cluster hat, jede Sequenz für jeden Knoten lokal ist und wenn Sie Felder mit eindeutigen Einschränkungen haben und die Sequenz verwenden, Dann können Sie nur eine Erhöhung vornehmen, die der Knotennummer im Cluster entspricht, weil So viele Knoten wie möglich im Cluster, Sequenz und Int wachsen schneller als erwartet. Um die Arbeit mit Sequenzen im Produkt zu vereinfachen, finden Sie sogar die Funktion alter_sequences, die die erforderlichen Inkremente für jede Sequenz auf allen Knoten vornimmt. Seien Sie jedoch darauf vorbereitet, dass die Funktion nicht in allen Versionen funktioniert. Natürlich können Sie es selbst schreiben, indem Sie den Code von Github als Grundlage verwenden oder es direkt im DBMS selbst korrigieren. In diesem Fall funktionieren Felder mit dem Typ „serialbigserial“ korrekter, aber um sie zu verwenden, müssen Sie höchstwahrscheinlich 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 funktionierte die Replikation nur, wenn eindeutige Primärschlüssel vorhanden sind. Berücksichtigen Sie dies bei der Entwicklung.

Separat möchte ich die Besonderheiten der Funktionsweise von npgsql in einer Cluster-Lösung erwähnen; diese Probleme treten nicht auf einem einzelnen Knoten auf, sondern sind in einem 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? Sie müssen nur einige Versionen nicht verwenden. Sie müssen sie kennen, denn... Der Fehler tritt in mehr als einer Version auf und selbst nach der ersten Behebung kann es sein, dass er später auftritt. Auch darauf muss man vorbereitet sein und es ist besser, alle identifizierten DBMS-Defekte, die vom Hersteller behoben werden, mit separaten Regressionstests abzudecken. Sozusagen vertrauen, aber überprüfen.

Wenn die Anwendung npgsql verwendet und zwischen Knoten wechselt und denkt, dass sie alle gleich sind, erhalten Sie möglicherweise eine Fehlermeldung:

EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...

Dieser Fehler tritt auf, weil die Bindung gerade ausgeführt wird

(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) 

zusammengesetzte Typen beim Anwendungsstart für alle Verbindungen. Als Ergebnis erhalten wir eine Kennung von einem Knoten, und bei der Anfrage an einen anderen Knoten stimmt diese 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 anwendungsseitige Umschreibungen nicht möglich (sofern Ihnen dies gelingt).

Wie wir alle wissen, ist eine Gesamtbeurteilung des Zustands des Clusters für die Diagnose und betriebliche Maßnahmen während des Betriebs sehr wichtig. Im Produkt finden Sie einige Funktionen, die Ihnen das Leben erleichtern sollen, aber manchmal können sie auch etwas völlig anderes bewirken Sie und sogar der Hersteller selbst erwarten von ihnen, was Sie 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 im LiveNodes-Feld überall die Zahl 2, obwohl diese laut Beschreibung des Multimaster-Betriebs der Zahl AllNodes=3 entsprechen müsste? Antwort: Sie müssen die DBMS-Version aktualisieren.

Und seien Sie darauf vorbereitet, Protokolle für alle Knoten zu sammeln, denn... Normalerweise wird Ihnen angezeigt, dass der Fehler im Protokoll eines anderen Knotens liegt. Der technische Support akzeptiert alle von Ihnen festgestellten Mängel und teilt Ihnen mit, dass die nächste Version bereit ist, die manchmal bei angehaltenem Dienst installiert werden muss, manchmal für längere Zeit (abhängig von der Größe Ihres DBMS). Sie sollten nicht darauf hoffen, dass betriebliche Probleme den Anbieter stark stören, und das Update aufgrund festgestellter Mängel wird unter Beteiligung der Vertreter des Anbieters durchgeführt bzw. Sie müssen die Vertreter des Anbieters nicht einmal einbeziehen, da in der Am Ende kann es in der Produktion zu einem zerlegten Cluster ohne Backup kommen.

Tatsächlich warnt der Hersteller in der Lizenz für ein kommerzielles Produkt ehrlich: „Diese Software wird „wie besehen“ bereitgestellt und die Postgres Professional Limited Liability Company ist nicht verpflichtet, Wartung, Support, Updates, Erweiterungen oder Änderungen bereitzustellen.“

Wenn Sie noch nicht erraten haben, um welches Produkt es sich handelt, dann sind all diese Erfahrungen das Ergebnis des jahrelangen Betriebs der Postgres Pro Enterprise-Datenbank. Sie können Ihre eigene Schlussfolgerung ziehen, es ist so feucht, dass Pilze wachsen.

Dies wäre jedoch nicht so schlimm, wenn dies rechtzeitig geschehen und auftretende Probleme umgehend behoben werden würden.

Aber genau das passiert nicht. Offenbar verfügt der Hersteller nicht über genügend Ressourcen, um erkannte Fehler zeitnah zu beheben.

An der Umfrage können nur registrierte Benutzer teilnehmen. Einloggenbitte.

Haben Sie Erfahrung mit dem Wechsel von einem ausländischen/proprietären DBMS zu einem kostenlosen/inländischen?

• 21,3%Ja, positiv10

• 10,6%Ja, negativ5

• 21,3%Nein, das DBMS wurde nicht geändert10

• 4,3%Das DBMS wurde geändert, aber es hat sich nichts geändert2

• 42,6%Ergebnisse anzeigen20

47 Benutzer haben abgestimmt. 12 Benutzer enthielten sich der Stimme.

Source: habr.com