Problem beim Lesen und Schreiben bei MySQL NDB Cluster

  • Ersteller Ersteller programmer13
  • Erstellt am Erstellt am
P

programmer13

Guest
Hallo zusammen

Beim Einsatz von MySQL NDB Cluster ist folgendes generelles Problem aufgetreten: Um einen neuen Record / Row einzufügen, sollte die letzte bzw. neuste Zeile in der Datenbank gelesen werden, nun geprüft werden, ob sie mit der einzufügenden Zeile kompatibel ist und dann die neue Zeile eingefügt werden.
Es stellt sich jedoch das Problem, dass in der Zwischenzeit eine andere Instanz den gleichen Prozess durchläuft und dann am Ende beide neuen Zeilen den gleichen letzten bzw. neusten Datensatz auf Kompatibilität mit ihrer einzufügenden Zeile geprüft haben und eingefügt werden.
Gibt es eine Möglichkeit, dies mit einem Sperrvorgang beispielsweise zu unterbinden?

So dass eine Instanz die letzte Zeile / den letzten Datensatz über JDBC in Java holt und diese Zeile zum Lesen sperrt, dann das Objekt überprüft und dann den neuen Datensatz einfügt und nun eine zweite Instanz den gleichen Prozess durchlaufen kann?

Vielen Dank für eure Antworten.
 
Werbung:
Wie meinst du das?

Ich kann dir ein Beispiel dazu geben:
Es gibt zum Beispiel eine Tabelle, welche die Historie von Kontoständen einer Person enthält. Nun liest eine Instanz diesen letzten Datensatz aus, überprüft ob genug Geld für eine Zahlung da ist und weitere Prüfungen, und schreibt dann eine neue Zeile mit dem neuen Kontostand wieder.

Dieser Vorgang muss irgendwie so geschützt werden, dass es euch beim Zugriff durch mehrere Instanzen, welche via JDBC zugreifen, funktioniert.
 
programmer13 schrieb:
Wie meinst du das?
Zum Vergrößern anklicken....

so wie ich es schrieb.

programmer13 schrieb:
Ich kann dir ein Beispiel dazu geben:
Es gibt zum Beispiel eine Tabelle, welche die Historie von Kontoständen einer Person enthält. Nun liest eine Instanz diesen letzten Datensatz aus, überprüft ob genug Geld für eine Zahlung da ist und weitere Prüfungen, und schreibt dann eine neue Zeile mit dem neuen Kontostand wieder.

Dieser Vorgang muss irgendwie so geschützt werden, dass es euch beim Zugriff durch mehrere Instanzen, welche via JDBC zugreifen, funktioniert.
Zum Vergrößern anklicken....

Transaktionen wurden bereits erfunden.
 
Leider kann ich aus deiner Antwort nicht genau verstehen, was du meinst ;)

Das mit den Transaktionen ist mir schon klar, jedoch ist die Frage, wie dies bei MySQL NDB Cluster passend funktioniert. Hat bisher nicht zum Ziel geführt und nicht funktioniert. Es konnten beide Instanzen gleichzeitig die neuste Zeile natürlich lesen und dann für ihre Überprüfung und das Einfügen als Vorgänger benutzen.

Denn für die Überprüfung in den verschiedenen Java Application Server wird für die Logik zwingend die Überprüfung des neusten letzten Datensatz benötigt.
 
programmer13 schrieb:
Das mit den Transaktionen ist mir schon klar, jedoch ist die Frage, wie dies bei MySQL NDB Cluster passend funktioniert. Hat bisher nicht zum Ziel geführt und nicht funktioniert. Es konnten beide Instanzen gleichzeitig die neuste Zeile natürlich lesen und dann für ihre Überprüfung und das Einfügen als Vorgänger benutzen.
Zum Vergrößern anklicken....

Das MySQL nicht funktioniert ist Allgemeinwissen und daher nix neues.
 
Okeii. Ja das bringt einem leider auch nicht zum Ziel ;) Aber ja danke für deine Hilfe.
Eventuell hat jemand anders mehr Erfahrung damit.
 
programmer13 schrieb:
Eventuell hat jemand anders mehr Erfahrung damit.
Zum Vergrößern anklicken....

Erfahrungen damit sind schon durchaus vorhanden. Aus der Doku zu BDR:

===

Column-level conflict detection​



By default, conflicts are resolved at row level. That is, when changes from two nodes conflict, we pick either the local or remote tuple and discard the other one. For example, we might compare commit timestamps for the two conflicting changes and keep the newer one. This ensures that all nodes converge to the same result and establishes commit-order-like semantics on the whole cluster.
===

www.enterprisedb.com

BDR (Bi-Directional Replication) v4 - Column-level conflict detection

BDR (Bi-Directional Replication) is a ground-breaking multi-master replication capability for PostgreSQL clusters that has been in full production status since 2014.
www.enterprisedb.com www.enterprisedb.com
 
Okei danke. Das wird aber bei MySQL Cluster NDB als Storage Engine nirgendwo erwähnt. Plus sollte ja der Vorgang einer zweiten Instanz nicht direkt abgebrochen sondern eher unterbunden für eine Zeit werden und danach z.B. durchgeführt werden.
Es muss also schon MySQL NDB Cluster spezifisch sein.
 
Das stimmt ja, aber wie geasgt das zu Beginn erwähnte Problem besteht trotzdem noch. Es fehlt ein Mechanismus, um gewisse Zeilen zu blockieren oder "locken" oder um eine Transaktion sauber hinzukriegen, damit nich mehrere Instanzen den Ablauf durcheinander bringen und sich gegenseitig Probleme bereiten. Darum wäre meine Frage, ob da jemand mit NDB Cluster praktische Erfahrungen oder Beispiele etc. hat?
 
Werbung:
Genau. Das kenne ich ebenfalls. Jedoch kann in diesem Fall der Datenbanktyp nicht geändert werden.
 
Zurück
Oben