Datenbankreplikation / Slave hinter DSL Leitung @home

[freakx0]

Hallo,

der MySql Server bietet ja die Möglichkeit einer Replikation. Hat schon jemand versucht, auf einem Rooty den Master zu installieren und einen Slave zu hause mit DSL-Leitung?
Da ich ständig die aktuellen Daten auch zu hause haben möchte.

Hat jemand Erfahrungswerte und könnte es Probleme geben?

Gruß
Dominik

[isotopp]

Hallo,

der MySql Server bietet ja die Möglichkeit einer Replikation. Hat schon jemand versucht, auf einem Rooty den Master zu installieren und einen Slave zu hause mit DSL-Leitung?
Da ich ständig die aktuellen Daten auch zu hause haben möchte.

Hat jemand Erfahrungswerte und könnte es Probleme geben?

Gruß
Dominik

Replikation ist eine Datenbankverbindung von irgendeinem Port des Slaves nach Port 3306 auf dem Master. Der Account auf dem Master muß das Recht REPLICATION SLAVE haben.

Die wechselnden IP-Nummern des DSL-Slaves sollten also kein Problem sein, wenn der Account auf dem Master korrekt ("repl"@"%") angelegt wird und mit einem starken Paßwort versehen wird.

Die üblichen Anweisungen zur Einrichtung von Replication gelten auch hier.

Kristian

[freakx0]

danke für deine Antwort. Ich habe halt bedenken, dass der geringe Upload der DSL-Leitung eventuell nicht reicht, da ich bisher noch null erfahrungswerte habe, was da für ein Datenvolumen anfällt (ok, kommt auch auf die Master-DB an, was da an inserts/updates läuft).

Also der Slave (@home mit dsl-anbindung) nimmt Verbindung zum Master auf und holt sich die Datei mit den Änderungen, oder? Dann wäre ja der Upload des Slave relativ gering.
Oder liege ich komplett falsch?


Gruß
Dominik

[flo]

Die wechselnden IP-Nummern des DSL-Slaves sollten also kein Problem sein, wenn der Account auf dem Master korrekt ("repl"@"%") angelegt wird und mit einem starken Paßwort versehen wird.

Hi Kristian,

wäre das evtl. mit einem DynDNS-Hostnamen praktikabler? - Frage nur aus Interesse ...

flo.

[isotopp]

Die wechselnden IP-Nummern des DSL-Slaves sollten also kein Problem sein, wenn der Account auf dem Master korrekt ("repl"@"%") angelegt wird und mit einem starken Paßwort versehen wird.

Hi Kristian,

wäre das evtl. mit einem DynDNS-Hostnamen praktikabler? - Frage nur aus Interesse ...

flo.

Du willst die Sicherheit Deiner Datenbank nicht von der Sicherheit von DNS abhängig machen.

[flo]

Du schreibst:

Code: Select all

... korrekt ("repl"@"%") ...

Aber eigentlich sollte es doch sicherer sein, den Host(namen) noch weiter zu beschränken!?

Code: Select all

... korrekt ("repl"@"test.dyndns.org") ...

Ich hatte nur keine Ahnung, was die Datenbank bei einer erneuten Anfrage macht - meinst Du, die Änderungen im DNS gelangen zeitnah zur Datenbank?

flo.

[ephigenie]

Also der Slave (@home mit dsl-anbindung) nimmt Verbindung zum Master auf und holt sich die Datei mit den Änderungen, oder? Dann wäre ja der Upload des Slave relativ gering.
Oder liege ich komplett falsch?

Nein - da liegst du richtig - der Traffic vom Slave zum Master ist sehr gering um nicht zusagen 0.
Das liegt daran, dass der Master die Daten zu den Slaves pusht (AFAIK).

Du solltest daran denken, dass ja nur alle Schreib-operationen (Insert, Update, delete etc..) übertragen werden - sonst nix - d.h. normalerweise sind die Select Anfragen überwiegend -> also recht wenig verkehr.

Was allerdings ein wenig länger dauern dürfte (je nach größe der DB) wäre ein "Load data from master" o.ä. (das dürfte ja aber klar sein)
ansonsten steht dem ganzen nix im Wege - auch die Möglichkeit nur Zwischenzeitlich mal wieder zu aktualisieren besteht (alle 2 Tage z.B.) solange auf dem Master die entsprechenden Binlog dateien vorhanden sind, alles kein Problem.
Das bedeutet auch, dass der Slave z.B. tagsüber bei (wirklich riesiger Last) hinterherhinken kann, das aber nachts (bei kleiner Last) wieder aufholt ohne probleme.

[isotopp]

Was allerdings ein wenig länger dauern dürfte (je nach größe der DB) wäre ein "Load data from master" o.ä. (das dürfte ja aber klar sein)

LOAD DATA FROM MASTER ist Scheiß. Benutze es nicht.

- Funktioniert nur mit MyISAM
- Ist Superlangsam.

[ephigenie]

LOAD DATA FROM MASTER ist Scheiß. Benutze es nicht.

man sollte vielleicht dazu sagen, dass die Ganze Replikation im Master-Slave hauptsächlich auf MyISAM ausgelegt ist und mit der technisch interessanteren InnoDB - Engine gar nicht läuft.

Klar - im Grunde ist ein selbstgebasteltes ssh/scp skript sicherlich die 1ste Wahl (Transfer ~5 MByte/s bei 100Mbit) .

Jedoch ist ein Load Data from master manchmal auch zu vertreten (Transfer ~2,4 MByte/s bei 100Mbit)

Beide Transfers wurden von mir gemessen übers netz max HOP = 3 .

Ab mysql5 sollte eigentlich Load Data from master (laut doku) "the way to go" sein ist es aber afaik nicht.

Und mir gings ja nur darum etwas zu suchen, was "wirklich meistens" lange dauert - und somit die DSL - Leitung ( um die Gings ja ) ausreizt (Im Rahmen einer Mysql - Master - Slave Verbindung )

[isotopp]

LOAD DATA FROM MASTER ist Scheiß. Benutze es nicht.

man sollte vielleicht dazu sagen, dass die Ganze Replikation im Master-Slave hauptsächlich auf MyISAM ausgelegt ist und mit der technisch interessanteren InnoDB - Engine gar nicht läuft.

MySQL Replikation ist von der Storage Engine unabhängig und läuft mit jeder Art von Engine gleich gut. Es ist für viele Anwendungen sogar noch nicht einmal notwendig, daß eine Tabelle auf dem Slave dieselbe Engine verwendet wie auf dem Master.

Bei Replikation erzeugt der Master ein Log aller SQL-Anweisungen, die Daten ändern, das Binlog, und ein Login für den Slave. Der Slave loggt sich mit seinem IO_Thread auf dem Master ein, lädt das Binlog herunter und speichert es lokal als Replication Log/Relay Log ab. Der SQL_Thread des Slave liest die dieses Relay-Log und führt es nacheinander aus.

Nichts daran nimmt in irgendeiner Weise Bezug auf die verwendete Storage Engine.


Für das initiale Setup ist ein "mysqldump --lock-all-tables --master-data --flush-logs --all-databases" oder vergleichbar die erste Wahl. Diese Methode ist so dann auch portabel für alle Engines.

Bei reinem InnoDB kann man statt "--lock-all-tables" auch "--single-transaction" nehmen und das wäre dann zu bevorzugen. Das "--master-data" erzeugt die notwendige Synchronisation der Binlog-Position zwischen Master und Slave.

[oxygen]

Code: Select all

... korrekt ("repl"@"test.dyndns.org") ...

Ich hatte nur keine Ahnung, was die Datenbank bei einer erneuten Anfrage macht - meinst Du, die Änderungen im DNS gelangen zeitnah zur Datenbank?

flo.

Löst deine IP zuhause auf test.dyndns.org auf? Wahrscheinlich nicht... Ich kann mich jetzt täuschen, aber soweit ich weiß, macht MySQL einen reserve lookup auf die IP der eingehenden Verbindung. (und keinen forward lookup auf alle rows in der user table) Mit obigem Konstrukt wäre eine Authentifizierung also gar nicht möglich.