🥇„Pro, aber kein Cluster“ oder wie wir DBMS ersetzt haben

Alle Charaktere sind fiktiv, Marken gehören ihren Eigentümern, jede Übereinstimmung ist zufällig und überhaupt ist dies meine „subjektive Einschätzung, bitte brechen Sie nicht die Tür…“

Wir haben umfangreiche Erfahrung in der Migration von Informationssystemen mit Logik in der Datenbank von einem DBMS zu einem anderen. Im Rahmen des Regierungsbeschlusses Nr. 1236 vom 16.11.2016 erfolgt dies häufig von Oracle zu PostgreSQL. Wie man den Prozess auf möglichst effiziente und schmerzfreie Weise gestaltet — darüber können wir gesondert berichten. Heute werden wir die Besonderheiten der Nutzung von Clustern und die Herausforderungen, die bei der Erstellung von hochbelasteten verteilten Systemen mit komplexer Logik in Prozeduren und Funktionen auftreten können, besprechen.

Spoiler – ja, CAP, RAC und pg Multimaster sind sehr unterschiedliche Lösungen.

Angenommen, Sie haben bereits die gesamte Logik von plsql auf pgsql übertragen. Ihre Regressionstests laufen gut, und jetzt denken Sie natürlich über Skalierung nach, da die Lasttests nicht sehr erfreulich sind, insbesondere auf der Hardware, die ursprünglich für eine andere DBMS in das Projekt eingeplant wurde. Angenommen, Sie haben eine Lösung eines inländischen Anbieters namens "Postgres Professional" mit einer Option namens "multimaster" gefunden, die nur in der „maximalen“ Version von „Postgres Pro Enterprise“ verfügbar ist. Nach Beschreibung klingt das sehr vielversprechend, und bei einer ersten oberflächlichen Prüfung wird Ihnen der Gedanke kommen: „Oh! Statt RAC ist das genau richtig! Und zudem mit technischem Support in der Heimat!".

Aber freuen Sie sich nicht zu früh, denn gleich werden wir erklären, warum es wichtig ist, diese Nuancen zu kennen, da sie selbst mit gründlichem Lesen der Produktdokumentation schwer vorhersehbar sind. Überlegen Sie, ob Sie bereit sind, die DBMS-Versionen häufig direkt in der Produktionsumgebung zu aktualisieren, da einige Fehler nicht mit der Produktion kompatibel sind und schwer beim Testen zu erkennen sind.
Beginnen Sie mit dem sorgfältigen Lesen des Abschnitts „multimaster“ – „Einschränkungen“ auf der Website des Herstellers.

Zu Beginn gibt es die Besonderheiten der Transaktionsverarbeitung im sogenannten "Zwei-Phasen"-Modus. Manchmal bleibt Ihnen nichts anderes übrig, als die gesamte Logik Ihres Verfahrens neu zu 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:

FEHLER:  [MTM] Transaktion MTM-1-2435-10-605783555137701 (10654) wird auf Knoten 3 abgebrochen. Überprüfen Sie das Protokoll, um die Fehlerdetails einzusehen.

Dann kann man lange gegen Deadlocks in den Versionen 10.5 und 10.6 ankämpfen. Die einzige bekannte Lösung, die das gesamte Konzept des Clusters zerstört, ist, "problematische" Tabellen aus dem Cluster zu entfernen, d.h. make_table_local zu verwenden. Das ermöglicht zumindest einen Betrieb und verhindert, dass alles wegen hängender Transaktionsbestätigungen blockiert wird. Oder man aktualisiert auf die Version 11.2, die helfen sollte – vielleicht aber auch nicht, vergessen Sie nicht zu prüfen.

In einigen Versionen können Sie eine noch mysteriösere Sperre erhalten:

username= mtm und backend_type = background worker

In dieser Situation kann Ihnen nur ein Update der DBMS-Version auf 11.2 oder höher helfen – vielleicht hilft es auch nicht.

Einige Vorgänge mit Indizes können zu Fehlern führen, bei denen ausdrücklich angegeben wird, dass das Problem bei der bidirektionalen Replikation liegt. In den MTM-Protokollen werden Sie direkt BDR sehen. Ist das wirklich 2ndQuadrant? Nein… wir haben doch multimaster gekauft, das ist einfach 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: sende ABORT-Benachrichtigung für Transaktion (5467) lokaler xid=4083 an Koordinator 3
[MTM] Empfange ABORT_PREPARED logische Nachricht für Transaktion MTM-3-25030-83-605694076627780 von Node 3
[MTM] Breche vorbereitete Transaktion MTM-3-25030-83-605694076627780 im Status InProgress von Node 3 originId=3 ab
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448

Wenn Sie temporäre Tabellen verwenden, trotz der Zusicherungen: „Die multimaster-Erweiterung führt die Datenreplikation vollständig automatisch durch. Sie können gleichzeitig schreibende Transaktionen durchführen und mit temporären Tabellen auf jedem Knoten des Clusters arbeiten.“

In diesem Fall erhalten Sie, dass die Replikation in allen Tabellen, die in der Prozedur verwendet werden, nicht funktioniert, wenn im Code eine temporäre Tabelle erstellt wird. Selbst die Nutzung von multimaster.remote_functions wird nicht helfen; Sie müssen Ihre Logik in der Prozedur aktualisieren oder neu schreiben. Wenn Sie gleichzeitig die beiden Erweiterungen multimaster und pg_pathman im Rahmen von „Postgres Pro Enterprise“ v 10.5 verwenden möchten, dann überprüfen Sie bei diesem einfachen Beispiel:

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 Datenbankknoten treten folgende Fehler auf:

…
 PATHMAN_CONFIG enthält keine Beziehung 23245
> find_in_dynamic_libpath: Versuche "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: Versuche "/opt//…/ent-10/lib/pg_pathman.so"
> DEBUG: find_in_dynamic_libpath: Versuche "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: Versuche "/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
> gewechselt zu Timeline 1 gültig bis 0/0
…
Transaction MTM-1-13604-7-612438856339841 (6919) wurde auf Knoten 2 abgebrochen. Überprüfen Sie das Protokoll, um die Fehlerdetails zu sehen.
...
[MTM] 28295: REMOTE begin Abbruchtransaktion 7017
…
[MTM] 28295: sende ABORT-Benachrichtigung für Transaktion (6919) lokale xid=7017 an Koordinator 1

Was sind das für Fehler? Sie können dies beim technischen Support in Erfahrung bringen; schließlich haben Sie diesen ja gekauft.

Was tun? Richtig! Auf «Postgres Pro Enterprise» auf v 11.2 aktualisieren.

Es ist wichtig zu wissen, dass ein Sequence, das als Objekt einer replizierbaren Datenbank fungiert, keinen globalen Wert im gesamten Cluster hat. Jeder Sequence ist lokal für jeden Knoten und wenn Sie Felder mit einzigartigen Einschränkungen haben, die Sequences verwenden, können Sie nur eine Inkrementierung entsprechend der Knotennummer im Cluster vornehmen. Je mehr Knoten im Cluster sind, desto schneller wird die Inkrementierung des Sequences erfolgen, und die Integer-Werte werden schneller erschöpft sein, als Sie erwartet haben. Um die Arbeit mit Sequences zu vereinfachen, finden Sie in der Software sogar die Funktion alter_sequences, die die notwendigen Inkremente für jedes Sequence an allen Knoten vornimmt. Seien Sie sich jedoch bewusst, dass diese Funktion nicht in allen Versionen verfügbar sein wird. Natürlich können Sie eine eigene Implementierung schreiben, indem Sie den Code von GitHub verwenden oder ihn direkt in der Datenbank anpassen. Die Felder vom Typ Serial und BigSerial funktionieren korrekter, aber wahrscheinlich müssen Sie den Code Ihrer Prozeduren und Funktionen dafür umschreiben. Möglicherweise wird die Funktion monotonic_sequences für einige Benutzer von Nutzen sein.

In Version 11.2 von «Postgres Pro Enterprise» wird die Replikation nur bei Vorhandensein von einzigartigen Primärschlüsseln funktionieren, beachten Sie das bei der Entwicklung.

Besonders möchte ich auf die Eigenschaften der Arbeit mit npgsql in einer Clusterlösung eingehen. Diese Probleme treten nicht bei einer Single-Node-Installation auf, sind jedoch im Multi-Master-Setup durchaus vorhanden.
In einigen Versionen kann es zu folgendem Fehler kommen:

Ausnahmedetails: Npgsql.PostgresException: 25001: Der Befehl SET TRANSACTION ISOLATION LEVEL 
Beschreibung: Eine nicht behandelte Ausnahme ist während der Ausführung der aktuellen Webanforderung aufgetreten. Bitte überprüfen Sie den Stack-Trace für weitere Informationen über den Fehler und wo er im Code entstanden ist.

Was kann man tun? Es ist einfach notwendig, bestimmte Versionen nicht zu verwenden. Man muss sie kennen, da der Fehler nicht in einer einzelnen Version auftritt und selbst nach der ersten Behebung können Sie ihm später wieder begegnen. Man sollte darauf vorbereitet sein und im besten Fall alle erkannten Datenbankfehler, die vom Hersteller behoben werden, durch separate Regressionstests abdecken. Sozusagen, Vertrauen ist gut, Kontrolle ist besser.

Wenn die Anwendung npgsql verwendet und zwischen den Knoten wechselt, in der Annahme, dass sie alle gleich sind, könnte folgendes Problem auftreten:

AUSNAHME: Npgsql.PostgresException (0x80004005): XX000: Cache-Lookup für den Typ fehlgeschlagen ...

Ein solcher Fehler tritt auf, weil eine Bindung ausgeführt wird

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

Bei der Anwendung von kompositen Typen für alle Verbindungen zu Beginn wird ein Identifikator von einer bestimmten Node erhalten. Wenn eine Anfrage an einer anderen Node erfolgt, stimmt dieser nicht überein, wodurch ein Fehler zurückgegeben wird. Das bedeutet, dass es für einige Anwendungen ohne zusätzliche Anpassungen auf der Anwendungsseite nicht möglich sein wird, transparent mit kompositen Typen im Cluster zu arbeiten (sofern Ihnen dies gelingt).

Wie wir alle wissen, ist die allgemeine Bewertung des Clusterzustands sehr wichtig für die Diagnose und die operativen Maßnahmen. Im Produkt finden Sie einige Funktionen, die Ihnen das Leben erleichtern sollten, aber manchmal können diese etwas ganz anderes zurückgeben, als Sie oder sogar der Hersteller erwarten.

Zum Beispiel:

select mtm.collect_cluster_info();
An jeder Node liefert das gleiche 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 steht im Feld LiveNodes überall die Zahl 2, obwohl laut Beschreibung der Multimaster-Operation die Zahl AllNodes=3 entsprechen sollte? Antwort: Die Version der DBMS muss aktualisiert werden.

Seien Sie darauf vorbereitet, Protokolle von allen Knoten zu sammeln, da Sie normalerweise die Meldung "Der Fehler befindet sich im Protokoll eines anderen Knotens" sehen werden. Der technische Support wird alle von Ihnen identifizierten Mängel annehmen und über die Verfügbarkeit der nächsten Version informieren, die manchmal mit einer Unterbrechung des Dienstes und manchmal auch für längere Zeit installiert werden muss (je nach Umfang Ihrer Datenbank). Es ist nicht ratsam, darauf zu hoffen, dass die Betriebsprobleme den Anbieter stark belasten werden, und dass das Update aufgrund festgestellter Mängel in Zusammenarbeit mit Vertretern des Anbieters durchgeführt wird; tatsächlich sollten Sie keine Vertreter des Anbieters hinzuziehen, da Sie am Ende einen produktiven Cluster ohne Backup erhalten könnten.

In der Lizenz für das kommerzielle Produkt warnt der Hersteller ehrlich: "Diese Software wird unter dem Prinzip „wie sie ist“ bereitgestellt, und die Gesellschaft mit beschränkter Haftung „Postgres Professionell“ ist nicht verpflichtet, Unterstützung, Wartung, Updates, Erweiterungen oder Änderungen bereitzustellen."

Wenn Sie noch nicht erraten haben, um welches Produkt es sich handelt, dann stammt all diese Erfahrung aus einem Jahr mit der Nutzung von Postgres Pro Enterprise. Sie können sich selbst ein Bild machen, die Feuchtigkeit ist so hoch, dass Pilze wachsen.

Das wäre gerade noch das kleinere Übel, wenn die Probleme zeitnah und effizient behoben würden.

Doch genau das passiert nicht. Anscheinend hat der Hersteller nicht genügend Ressourcen, um die erkannten Bugs schnell zu beheben.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?

Haben Sie Erfahrung mit dem Umstieg von einer ausländischen/besitzergeschützten Datenbank auf eine freie/eigenständige?

21,3%Ja, positiv10
10,6%Ja, negativ5
21,3%Nein, kein Wechsel der Datenbank10
4,3%Datenbank gewechselt, aber es hat sich nichts geändert2
42,6%Ergebnisse anzeigen20

47 Nutzer haben abgestimmt. 12 Nutzer haben sich enthalten.

Quelle: habr.com

„Über Cluster, aber nicht“ oder wie wir Datenbanken importsubstituiert haben

Haben Sie Erfahrung mit dem Umstieg von einer ausländischen/besitzergeschützten Datenbank auf eine freie/eigenständige?