Master <--> Master Replikation

Hallo allerseits,
ich habe hier folgendes Problem :
Gegeben :
- 2 Notebooks (vielleicht spaeter mal 3)
- 1 Server

Auf den Notebooks werden Messwerte erfasst (offline). Diese Messwerte
sollen nun , wenn das Notebook online ist, mit einem Server repliziert
werden.

Auf dem Server und den beiden Notebooks muessen nach den Replikationen
die gleichen Daten sein.

Ich lese ueberall, dass es Onw-Way Replikationen gibt (die ich auch zum
Laufen bekommen habe), jedoch finde ich nichts von Master <--> Master
Replikationen.
Gibe es bei MySQL (Version > 5.0) ueberhaupt solch eine Moeglichkeit und
wenn ja, wo finde ich HowTos ?

Vielen Dank schonmal

Tobias
--
Dipl.-Ing. Tobias Elfert
http://www.elfert.de // http://www.hatlug.de

Re: Master <--> Master Replikation

Tobias Elfert schrieb:
> Hallo allerseits,
> ich habe hier folgendes Problem :
> Gegeben :
> - 2 Notebooks (vielleicht spaeter mal 3)
> - 1 Server
>
> Auf den Notebooks werden Messwerte erfasst (offline). Diese Messwerte
> sollen nun , wenn das Notebook online ist, mit einem Server repliziert
> werden.
>

Ich finde diese Beschreibung nicht übermäßig klar, was an der Wahl der
Präposition 'mit' liegen mag und daran, dass Du von 'einem' Server
sprichst - meinst Du damit denselben, der oben als '1 Server'
auftaucht, oder einen zweiten? Offline heißt vermutlich "weder mit
dem/einem Server noch mit dem anderen Notebook per Netz verbunden"?

> Auf dem Server und den beiden Notebooks muessen nach den Replikationen
> die gleichen Daten sein.

Hast Du mal überlegt, *wie* das gehen soll? Angenommen, Du hättest auf
allen drei Maschinen denselben Ausgangszustand. Notebook 1 misst jetzt
irgendwas und macht ein
INSERT INTO bla VALUES ('fasel')
Notebook 2 misst irgendwann auch was und macht ein
INSERT INTO bla VALUES ('bla')

Nun haben Deine Tabellen sicherlich einen Primary Key. Vermutlich ist
das eine auto_increment-Spalte. Auf beiden Notebooks war derselbe
Ausgangszustand, also führt jedes der INSERTs zu einem neuen Eintrag
mit *identischem* PK.

Das kann man vermeiden, indem man GUIDs benutzt. Ich lese jetzt nicht
in der Dokumentation nach, ob MySQL das von Hause aus bietet. Vor
UPDATE-Konflikten retten dich diese GUIDs aber auch nicht: Notebook 1
ändert GUID1, dito Notebook 2 - welcher Wert soll dann nach der
Replikation übrig bleiben?

Re: Master <--> Master Replikation

Christian Kirsch schrieb am 17.02.2006 10:16:
> Ich finde diese Beschreibung nicht übermäßig klar, was an der Wahl der
> Präposition 'mit' liegen mag und daran, dass Du von 'einem' Server
> sprichst - meinst Du damit denselben, der oben als '1 Server'

Jepp, ist etwas ungluecklich ausgedrueckt.
Es existiert nur 1 Server mit dem sich die Notebooks replizieren sollen.

Die Notebooks werden nie (!) in die gleiche Tabelle schreiben.
Jede Messung produziert eine neue Tabelle, weswegen ich denke, dass es
keine Update-Konflikte bekommen werde (hoffentlich).


MFG Tobias

--
Dipl.-Ing. Tobias Elfert
http://www.elfert.de // http://www.hatlug.de

Re: Master <--> Master Replikation

Tobias Elfert schrieb:
> Christian Kirsch schrieb am 17.02.2006 10:16:
>> Ich finde diese Beschreibung nicht übermäßig klar, was an der Wahl der
>> Präposition 'mit' liegen mag und daran, dass Du von 'einem' Server
>> sprichst - meinst Du damit denselben, der oben als '1 Server'
>
> Jepp, ist etwas ungluecklich ausgedrueckt.
> Es existiert nur 1 Server mit dem sich die Notebooks replizieren sollen.
>
> Die Notebooks werden nie (!) in die gleiche Tabelle schreiben.
> Jede Messung produziert eine neue Tabelle, weswegen ich denke, dass es
> keine Update-Konflikte bekommen werde (hoffentlich).
>

Was willst Du dann mit Replikation? Für so was kannst Du doch einfach
mysqldump ... | mysql
benutzen. Ob allerdings Dein Datenmodell glücklich gewählt ist ...

Re: Master <--> Master Replikation

Tobias Elfert wrote:
> Christian Kirsch schrieb am 17.02.2006 10:16:
>> Ich finde diese Beschreibung nicht übermäßig klar, was an der Wahl der
>> Präposition 'mit' liegen mag und daran, dass Du von 'einem' Server
>> sprichst - meinst Du damit denselben, der oben als '1 Server'
>
> Jepp, ist etwas ungluecklich ausgedrueckt.
> Es existiert nur 1 Server mit dem sich die Notebooks replizieren sollen.

Das "mit" als Präposition bleibt falsch. Replikation ist eine
Einbahnstraße, das heißt entweder der Server repliziert seine Daten
/auf/ die Notebooks, oder die Notebooks replizieren Ihre Daten /auf/ den
Server.

Die Präposition "mit" wird in diesem Zusammenhang üblicherweise mit dem
Thema "Synchronisation" benutzt. Ich denke du nimmst an, automatisch
eine Synchronisierung zu bekommen, wenn du Replikation einrichtest.

> Die Notebooks werden nie (!) in die gleiche Tabelle schreiben.
> Jede Messung produziert eine neue Tabelle, weswegen ich denke, dass es
> keine Update-Konflikte bekommen werde (hoffentlich).

Unter solchen Annahmen ist es möglich, die Replikation jeweils separat
in beide Richtungen laufen zu lassen und damit eine Synchronisation zu
erstellen. Aber: Damit sich der Server als Slave die Daten der Notebooks
als Master holen kann, musst du die Umgebung so einrichten, dass dem
Server bekannt ist, wo er die Notebooks findet, wenn sie da sind.

Grüße
Kai

Re: Master <--> Master Replikation

Christian Kirsch schrieb:
> Das kann man vermeiden, indem man GUIDs benutzt. Ich lese jetzt nicht
> in der Dokumentation nach, ob MySQL das von Hause aus bietet. Vor
> UPDATE-Konflikten retten dich diese GUIDs aber auch nicht: Notebook 1
> ändert GUID1, dito Notebook 2 - welcher Wert soll dann nach der
> Replikation übrig bleiben?

Der Ansatz ist aber richtig, man nimmt einen zusammengesezten
PrimaryKey, aus der ID des Servers und einer int-Spalte (nicht per
AutoIncrement). Jeder MySQL-Daemon darf dann nur "seine" Daten ändern,
dass muss per Programm sichergestellt werden, ich glaube nicht, dass das
Rechtesystem bereits sowas kann.

Wenn man dann das ganze als Ring-Replikation aufbaut sollte das
funktionieren. Schlecht ist dann nur, wenn einer der MySQL-Server (z.B.
ein Notebook) für zwei Wochen nicht vorhanden ist, oder dieses ohne
Backup verstirbt...

Insgesamt daher eine überdenkenswerte Konstruktion ...

Grüße

Dirk

Re: Master <--> Master Replikation

Dirk Brosowski schrieb:
> Christian Kirsch schrieb:
>> Das kann man vermeiden, indem man GUIDs benutzt. Ich lese jetzt nicht
>> in der Dokumentation nach, ob MySQL das von Hause aus bietet. Vor
>> UPDATE-Konflikten retten dich diese GUIDs aber auch nicht: Notebook 1
>> ändert GUID1, dito Notebook 2 - welcher Wert soll dann nach der
>> Replikation übrig bleiben?
>
> Der Ansatz ist aber richtig, man nimmt einen zusammengesezten
> PrimaryKey, aus der ID des Servers und einer int-Spalte (nicht per
> AutoIncrement). Jeder MySQL-Daemon darf dann nur "seine" Daten ändern,
> dass muss per Programm sichergestellt werden, ich glaube nicht, dass das
> Rechtesystem bereits sowas kann.
>

Mit anderen Worten: Du hast auf den einzelnen Rechnern völlig
disjunkte Daten. So ähnlich hat der OP das ja jetzt auch beschrieben
(der benutzt offenbar eine spezielle Form des Partitioning, lange vor
MySQL 5.1 ;-). In dem Fall scheint mir ein freundliches

mysqldump -t -w 'where key like 'ServerID%' bla |
mysql -h server bla

das Gewünschte erledigen zu können. Sieht weniger hübsch aus als
Replikation, ist aber vielleicht simpler aufzusetzen :-)

Re: Master <--> Master Replikation

> Was willst Du dann mit Replikation? Für so was kannst Du doch einfach
> mysqldump ... | mysql
> benutzen. Ob allerdings Dein Datenmodell glücklich gewählt ist ...

Ganz einfach. Ich moechte nicht manuell einzelne Tabellen als DUMP aus
der Datenbank ziehen um sie dann in eine andere Datenbank einzuspielen,...
Ich dachte, dass man mit diesen Replikationen automatisch die neuen
Messwerte in eine Gesamtdatenbank einpflegen kann.

MFG Tobias

--
Dipl.-Ing. Tobias Elfert
http://www.elfert.de // http://www.hatlug.de

Re: Master <--> Master Replikation

Kai Ruhnau schrieb am 17.02.2006 11:08:
>
> Unter solchen Annahmen ist es möglich, die Replikation jeweils separat
> in beide Richtungen laufen zu lassen und damit eine Synchronisation zu
> erstellen. Aber: Damit sich der Server als Slave die Daten der Notebooks
> als Master holen kann, musst du die Umgebung so einrichten, dass dem
> Server bekannt ist, wo er die Notebooks findet, wenn sie da sind.

Ok, das hoert sich schonmal gut an.
Nennen wir es ab jetzt mal Syncronisation,...
Gibt es denn HowTos fuer solche Syncronisationen?
In den MySQL-Dokus habe ich leider nichts gefunden :-(


MFG Tobias

--
Dipl.-Ing. Tobias Elfert
http://www.elfert.de // http://www.hatlug.de

Re: Master <--> Master Replikation

Christian Kirsch schrieb:
> Dirk Brosowski schrieb:
>
>>Christian Kirsch schrieb:
>>
>>>Das kann man vermeiden, indem man GUIDs benutzt. Ich lese jetzt nicht
>>>in der Dokumentation nach, ob MySQL das von Hause aus bietet. Vor
>>>UPDATE-Konflikten retten dich diese GUIDs aber auch nicht: Notebook 1
>>>ändert GUID1, dito Notebook 2 - welcher Wert soll dann nach der
>>>Replikation übrig bleiben?
>>
>>Der Ansatz ist aber richtig, man nimmt einen zusammengesezten
>>PrimaryKey, aus der ID des Servers und einer int-Spalte (nicht per
>>AutoIncrement). Jeder MySQL-Daemon darf dann nur "seine" Daten ändern,
>>dass muss per Programm sichergestellt werden, ich glaube nicht, dass das
>>Rechtesystem bereits sowas kann.
>>
>
>
> Mit anderen Worten: Du hast auf den einzelnen Rechnern völlig
> disjunkte Daten. So ähnlich hat der OP das ja jetzt auch beschrieben
> (der benutzt offenbar eine spezielle Form des Partitioning, lange vor
> MySQL 5.1 ;-). In dem Fall scheint mir ein freundliches
>
> mysqldump -t -w 'where key like 'ServerID%' bla |
> mysql -h server bla
>
> das Gewünschte erledigen zu können. Sieht weniger hübsch aus als
> Replikation, ist aber vielleicht simpler aufzusetzen :-)

Disjunkte Tabellen glaube ich noch nicht so ganz, der Einsatz eines
Notebooks kann sich ja auch mal ändern.

Aber ich denke Denkanstösse hat der OP genügend, er wird etwas daraus
machen.

Grüße

Dirk

Re: Master <--> Master Replikation

Tobias Elfert wrote:
> Auf den Notebooks werden Messwerte erfasst (offline). Diese Messwerte
> sollen nun , wenn das Notebook online ist, mit einem Server repliziert
> werden.

Du kannst auf den Notebooks ein binlog schreiben lassen und dieses
dann manuell/skriptgesteuert auf den Master umkopieren und dort
einspielen. Gleichzeitig natuerlich die Binlogs im Erfolgsfall
rotieren und loeschen. Mit ssh, dem mysqlbinlog-Tools und ein wenig
Shellscripterei sollte das einfach sein.

Vorausgesetzt natuerlich, Du schreibst nicht in gemeinsame Tabellen,
bei denen es mit unique oder primary Keys Kollisionen geben koennte.

Re: Master <--> Master Replikation

Kai Ruhnau wrote:
> Tobias Elfert wrote:
>>
>> Es existiert nur 1 Server mit dem sich die Notebooks replizieren sollen.
>
> Das "mit" als Präposition bleibt falsch. Replikation ist eine
> Einbahnstraße, das heißt entweder der Server repliziert seine Daten
> /auf/ die Notebooks, oder die Notebooks replizieren Ihre Daten /auf/ den
> Server.

Klappt leider auch nur in die erste Richtung. Das Problem ist, daß in
einem Replikations-Szenario jede Maschine nur einen Master haben kann.

Allerdings kann man die unterliegenden Mechanismen auch für die Gegen-
richtung nutzen: man läßt die Notebooks ebenfalls ein Binlog schreiben
(sinnvollerweise eingeschränkt auf die Datenbank in der die Meßwerte
landen). Wann immer ein Notebook wieder Netzwerkverbindung zum Master
hat, rotiert man die Binlogs und spielt sie per

mysqlbinlog | mysql -h ...

auf den Master.

Für die Gegenrichtung setzt man die Standard-Replikation mit den
Notebooks als Slaves auf. Zusätzlich *muß* man eindeutige server_ids
vergeben und auf dem Master log_slave_updates einschalten.

Es ist ganz sicher empfehlenswert, sich das Handbuch-Kapitel, das
die Funktionsweise der MySQL-Replikation erklärt, zu lesen.


XL