Skip to content

13 GB SQL-Dumps

Ein Interessent sucht gerade eine Lösung, um regelmäßig (d.h. werktäglich) Daten aus einer anderen MySQL-Datenbank zu uns zu transferieren, um hier bei uns damit weiterzuarbeiten. Leider hilft auch ein inkrementeller Transfer nicht, da sich Daten ändern, und nicht nur primär neue dazukommen.

Insgesamt wären das dann über 13 GB SQL-Dumpy pro Monat. Krass.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Henning

Ich habe selbst noch nicht damit gearbeitet, aber die Replication-Funktion von MySQL könnte eine Lösung sein. Dabei wird ein Master-Server und einer oder mehrere Slave-Server definiert. Der Master loggt alle Veränderungen an der Datenbank mit. Wenn sich dann ein Slave meldet, werden alle seit dem letzten Mal aufgelaufenen Veränderungen dort nachvollzogen :-)

flo

Wir benutzen genau diesen Mechanismus um bei uns eine Datenbank zu aktualisieren. Die Ursprungsdatenbank steht in Norwegen und die Datenmenge ist auch im zweistelligen GB-Bereich.

Klappt aber natürlich nur dann, wenn man selber nicht auch noch Änderungen an den Daten machen will...

mnemo

13 GB vor oder nach bzip2?

Manuel Schmitt (manitu)

(leider) fast identisch

Alexander Grümmer

Also das bzip2 das ganze nicht kleiner bekommt kann ich mir fast nicht vorstellen.
Man sollte hier vielleicht rsync einsetzen. Das macht ja eine differenzielle übertragnung und keine incrementelle.

PS: Alternativ kann man einen vpn tunnel bauen und die MySQL Repliziert sich online. Dann ist der traffic zwar nicht viel weniger aber schön verteilt.

Gruß Alexander

tris

Kann ich mir auch nicht vorstellen, dass bzip2 da nichts hinkriegt. Was bitte steckt in der DB? Massen an mpgs oder jpgs als blob?

Aber egal, 13 gig im Monat ist doch nicht viel. Ich 7zippe monatlich das E-Mailarchiv meines Brötchengebers (inbound/outbound) und bin froh wenn das archive unter 8 gig bleibt.

Manuel Schmitt (manitu)

Es sind fast nur binäre Daten, daher bringt bzip2 nur marginal etwas. Binäre Replikation funktioniert nicht, weil die Quelle ein shared Server ist!

SvenW

Mit Hilfe des DBA könnte man dann das Binlog durch

mysqlbinlog logfilename --database=dbname | gzip > updatelog.gz

jagen, dann gibt es in der gz-Datei nur die tatsächlichen Änderungen der der fraglichen Datenbank.

Stefan

Ja, rsync scheint mir auch die richtige Alternative. Das vergleicht nämlich recht intelligent (laut eigener Aussage) auch binäre Daten und transferiert nur Änderungen. Nach meiner Erfahrung funktioniert das auch mit größeren Dateien. Getestet habe ich das allerdings nicht mit solchen Datenmengen.

Viele Grüße
Stefan

SvenW

Ich hab es jetzt nicht ausprobiert, aber ist es denkbar, nur daß Binary/Update-Log zu transferieren und auf dem anderen Server auszuführen?

http://dev.mysql.com/doc/refman/5.1/en/binary-log.html

Denis

Was mir als erstes einfällt ist auch wie schon genannt eine Replikations-Konstellation. Das wäre zwar nicht täglich, aber das einfachste. Das würde auch über ein VPN-Tunnel gehen.

Zweite Alternative: Wenn auf beiden Systemen das selbe OS/MySQL läuft -- einfach die Dateien direkt kopieren - per SCP.

Falls sich was gutes findet was nicht in den Kommentaren erwähnt wurde, würd ich mich über eine Mail freuen -- interessiert mich nämlich auch. :) Auch wenn es bei uns zZ nur etwa 2,5 GB sind. :-)
...die ich einmal im Monat im 50GB-Packet herunterziehe :)

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Formular-Optionen