Kann das MySQL?

[ruediger123]

Hänge noch an meiner Checkliste zu den Funtionen zu MySQL und wüsste gerne ob das DBMS auch folgende Verteilung kann.

Es existieren mehrere Standorte, auch im europäischen Ausland. Diese arbeiten heute auf jeweils einem zentralen Datenbankmanagementsystem. Dies soll auch so bleiben, so daß jeder Standort hauptsächlich auf seine eigenen Daten zugreift (Kundenstämme, Aufträge, Rechnungen, ...). Zukünftig sollen die Daten der Standorte transparent untereinander zur Verfügung stehen. In weniger häufigeren Fällen z.B. beim Erstellen von Statistiken oder anderen außerordentlichen Abfragen können jedoch auch Daten von anderen Standorten benötigt werden. Die Anbindung ist über VPN-Verbindungen angedacht.

Meine Frage:
Ist es mit MySQL generell möglich das DBMS so auszulegen, dass Daten und insbesondere auch.einzelne Tabellen z.B. über Partitionierung auf unterschiedliche Standorte verteilt werden können? Demzufolge gäbe es z.B. eine virtuelle, standortübergreifende Kundentabelle, welche in einzelne Bereiche (Standorte) unterteilt ist. Somit würde eine Abfrage auf den Kundenstamm am eigenen Standort schnell vollzogen, während eine Abfrage über Kunden eines anderen Standorts dementsprechend länger dauern würde.

[Bernhard Geyer]

ich würde sowas über die Replikationsmechanismen der DB's gehen so das die Daten untereinander repliziert werden. Die darauf Aufsetzende App muss "nur" Replikationsfähig sein.

[Falk Prüfer]

...Ist es mit MySQL generell möglich das DBMS so auszulegen, dass Daten und insbesondere auch.einzelne Tabellen z.B. über Partitionierung auf unterschiedliche Standorte verteilt werden können?

Nein, generell nicht. Mit dem kostenlosen Communit-Server ist dies nicht möglich. Replication und Partitionierung stehen erst mit der MySQL Enterprise Edition zur Verfügung.

Gruß Falk

[Bernhard Geyer]

Nein, generell nicht. Mit dem kostenlosen Communit-Server ist dies nicht möglich.

Das wird aber dann auch generell bei keinem DBMS möglich sein da solche Features man sich generell bezahlen lässt.
Aber bei MySQL ist das immer ein guter Hinweis. Man will ja immer nix zahlen für SW

[ruediger123]

Sorry, mit dem "generell" habe ich mich unglücklich ausgedrückt. Ich gehe hier von der Enterprise Edition aus

Aber nochmal back to topic: Liege ich mit folgendem Szenario richtig?

Es werden alle Standorte mit mindestens einem Replikanten versehen. Die Replikanten synchronisieren sich mit einem dedizierten Master.

Jetzt können die Applikation ihre Abfragen auf einem sich am selben Standort befindenden Slave ausrichten. Das bedeutet schnelle Lesezugriffe.

Doch wie sieht es jetzt mit dem Schreiben aus? Habe gelesen dass bei der Replikation Schreibvorgänge nur über den Master laufen und somit alle Standorte außer dem an dem es den Master gibt mit erheblichen Verzögerungen rechnen müssen, oder?

Ich dachte deshalb daran, dass es vielleicht eine Funktionalität gibt in der ausgewählte Tabellen in unterschiedliche Tabellenbereiche (Partitionen) aufgeteilt werden, sodass jeder Standort in seine Partition direkt schreiben kann (ohne Umweg über den Master.)

Als Laie denke ich dabei an eine Mischung aus Replikation und Partitionierung.
Geht das oder ähnliches mit der Enterprise Edition?

[Bernhard Geyer]

Bei Replikation werden auch die Schreibvorgänge in der lokalen Instanz durchgeführt und mittels Replikation dann erst an den "Server" und dann an die anderen "Clients" verteilt.

Jedoch muss die App das unterstützen.

[ruediger123]

Bedeutet das, dass bei der Replikation die Lese/Schreibvorgänge lokal genauso schnell durchgeführt werden wie bei einer Installation ohne Replikation und nur der Abgleich mit den anderen Slaves verzögert?

[Bernhard Geyer]

Normalerweise sollte es keine Performanceeinbußen beim Lesen geben. Beim schreiben evtl. schon. Aber diese dürften nicht zu große sein.

[ruediger123]

Was ist denn der Grund für die Einbußen beim Schreiben? Muss sich der lokale Slave erst mit dem Master abgleichen bevor er die lokale Änderung einträgt?

[ruediger123]

Hab mit dem Support gesprochen. Eine Abgleich findet imme nur vom Master aus statt. Wenn ich also meine Schreibvorgänge nicht über den Master sondern dirkekt zum Slave sende dann wird er zwar lokal gespeichert doch die Änderungen werden nicht an den Master gesendet und somit auch nicht an die anderen Slaves

Kommt beim Master also irgendwann eine Änderung eines Datensatz bei dem auch am Slave Änderungen vorgenommen wurden, so wird dieser beim nächsten Master/Slave-Abgleich mit den Informationen des Masters überschrieben.

[Michael Bieri]

Nein, generell nicht. Mit dem kostenlosen Communit-Server ist dies nicht möglich. Replication und Partitionierung stehen erst mit der MySQL Enterprise Edition zur Verfügung.

Falsch, Partitionierung ist bereits ab mySQL 5.1 möglich und funktioniert bis auf ein paar Limitierungen prima.


Streng gesehen könntest du auch ein Master/Master ("Multi Master") Konzept fahren, so dass sich beide gegenseitig abgleichen, ist aber ein rechter Pain in the Ass und keinesfalls eine gute Vorgehensweise. Vorallem nicht wenn du mehr als 2 Instanzen hast.

Was allerdings für dich spannend sein könnte; Keywords: Federated Tables, Merge Tables. Bei letzterem ist allerdings auch Vorsicht geboten..


Grundsätzlich ist die Frage ob du den Abgleich nicht ev. besser periodisch (z.B. Nachts) durch einen eigenständigen Prozess erledigst?