Multi-Master-Replikation

[Huschi]

Hallo Leute,

heute stehe ich irgendwie auf dem Schlauch.
Ich habe hier eine MySQL-Lösung mit selbst programmierter Multi-Master-Replikation.
Aber ich würde gern (mit Blick in die Zukunft) auf die Binary-Replikation von MySQL zurück greifen.
Nun finde ich zwar einige Anleitungen zum Thema Master-Master, aber keine die mehr als 2 Master unterstützt.
Das Problem ist auch logisch: da die Replikationsdaten jeder Slave nicht nochmal in seinem Binary-Log schreibt, wird dies aber ggf. nicht mehr weiter gegeben.

Folgendes Scenario:
Wir haben einen Root-Server mit MySQL, nennen wir ihn "master1".
Dazu haben wir in einigen Büro's eigenen Server: "master2", etc.
Aus Performancegründen schreibt jede Applikation auf den Master im entsprechenden Netzwerk.

Nun das Problem:
Ich würde alle Server gerne mit einer Master-Master-Replikation ausstatten und master1 als zentralen Knotenpunkt zum Datenaustausch nutzen.

Solange auf master1 Daten geändert werden, verteilen sich diese auf alle Slaves. OK!
Sobald aber master2 Daten geändert hat, gehen diese zwar auf master1, aber werden nicht auf die anderen Slaves weiter gegeben, weil master1 die Änderungen von master2 nicht ins Binarylog schreibt.
Letzteres kann man abschalten, aber dann erhält master2 beim nächsten Lauf seine veränderten Daten wieder. Und spätestens bei einem Insert geht die Sache schief...

Meine angestrebte Lösung und damit auch meine Frage:
Gibt es ein Scenario (meinetwegen mit einem weiteren zentralen MySQL-Master), bei dem sich wirklich alle Master miteinander replizieren?

huschi.

 

[mr_brain]

Für dein Szenario ist Replikation äußerst ungeeignet, da es zu Inkonsistenzen kommen kann.

Du solltest das Ganze mit einem mySQL-Cluster realisieren.

 

[Huschi]

da es zu Inkonsistenzen kommen kann.

Daher habe ich ja bisher auf eine selbst programmierte Lösung zurück gegriffen.
Die hat das Problem im Griff gehabt. Aber sie ist nicht hinreichend performant und auch nicht trivial einzurichten.

Du solltest das Ganze mit einem mySQL-Cluster realisieren.

Daran hab ich auch schon gedacht. Das Problem ist, daß die Büro's nur über normale DSL-Leitungen angeschlossen sind. Auch eine (standhafte) Verbindung zwischen den einzelnen Büro's ist nicht wirklich denkbar.

huschi.

 

[LinuxAdmin]

Ohne jetzt Datenbank-Experte zu sein stellt sich mir die Frage, ob sich das mit den Multi-Mastern überhaupt lohnt. Der lokale Master in einem Master muss doch ohnehin eine Verbindung zum anderen Master herstellen, bevor eine Transaktion lokal committed werden kann um Inkonsistenzen zu verhindern. Sind die Latenzen wirklich so viel größer, wenn die Clients direkt mit dem Master auf dem RootServer kommunizieren?

Viele Grüße,
LinuxAdmin

 

[Huschi]

So soll es ja auch sein.
Der RootServer als zentralen Verteiler für alle Daten.
Man kann sich das Sternförmig vorstellen.

Es hängt lediglich an dem kleinen Problem, daß jeder Client seine Änderungen vom zentralen Master erneut erhält und damit einen Fehler auslöst.

huschi.

 

[elias5000]

Um auch mal Senf beizusteuern muss ich mich hier mal laut wundern, wie man eine Master-Master-Replikation im Live-Betrieb verwirklichen will?
Wie schon angesprochen würde es bei einem Master-Master-Setup ja zu inkonsistenzen durch Race-Conditions kommen können. Und wenn man das mit Locks auf dem "primären Master" abfängt, dann streiche man das primär und ersetze "sekundäre Master" durch "Slaves" und man sieht, was man wirklich hat.

Alle Schreiboperationen müssen also den Master locken und könnten deshalb auch gleich auf ihm gemacht werden. Nur die Leseoperationen profitieren vom lokal vorhandenen Slave.
was man machen könnte ist, den zentralen Master als Master-Slave Replikation mit Switchover zu fahren (um den Master gegen Ausfall zu sichern) und an dieses Gespann weitere lokale Slaves zum Boost der Leseoperationen zu verwenden.

Die Applikation würde dann entweder über eine Abstraktion zugreifen, die schreibende Operationen auf den Master umlenkt (was vermutlich deiner "selbst programmierten Lösung" entspricht) oder mit zwei Datanbank-Handles, von denen eines für lesende Zugriffe den lokalen Slave bindet und eins den Master für schreibende.

Dieser Link hier sieht ganz super aus: capttofu: MySQL Multi-Master Replication
Aber der hat auch nur zwei Master, welche Slaves bedienen.

 

[Huschi]

Ein weiteres Problem sind die DSL-Leitungen und die Ausfallsicherheit.
Schreibprozesse müssen immer auf den lokalen Server stattfinden, damit ein Ausfall der DSL-Leitung oder gar des RootServers die Arbeit nicht beeinträchtigt.

Race-Conditions sind relativ ausgeschlossen, da jedes Büro / jeder MA im wesentlichen auf seinen eigenen Daten arbeitet. Theoretisch könnte man auch ganz ohne Replikation auskommen. Man hätte dadurch allerdings ein Problem bei der Verteilung von Struktur-Änderungen. Und die Führungsspitze hat ein Problem mit den allzu geliebten Statistiken...
Außerdem kann jeder MA von zuhause aus auf den RootServer um dort weiter zuarbeiten.

Was Deinen Link angeht: Ja genau so stelle ich mir das vor und hatte es schon angetestet.
Aber wie gesagt stößt diese Lösung an ein Ende sobald mehr als 2 'Master' benötigt werden.

Momentan schwebt mir eine Lösung vor, daß man einen zweiten MySQL-Server auf dem RootServer aufsetzt, der als Master fungiert und auf dem definitiv nie-nicht-nimmer gearbeitet wird. Dieser hält die Verbindung zu allen anderen Master und sorgt für die Datenverteilung. Aber irgendwie funktioniert das immer noch nicht...

Das Ende vom Lied wird wohl sein, daß ich meine eigene Replikation überarbeite bzw. vollständig neu schreibe.

huschi.

 

[whyte]

Ja über sowas hatte ich mir auch schon viel Gedanken gemacht und bin an einer eigenen "Replikation" hängen geblieben, dabei werden sämtliche SQL Befehle in eine separate Table geschrieben. Diese wird dann via Cron-Dämon alle Minute oder so abgearbeitet und an alle erreichbaren Server übermittelt. Nicht erreichbare Server werden gemerkt und die Befehle bei wiederereichen nageholt.

Allerdings birgt das hier auch die Gefahr, wenn auf einem Server was geändert wird und dann von einem anderen der Befehl kommt, die eine Änderung wieder übreschreibt, oder ids doppelt vergeben werden usw usw ...

Ist alles nix halbes und nix ganzes ...