Donnerstag, 5. April 2007, 15:06
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.
Insgesamt wären das dann über 13 GB SQL-Dumpy pro Monat. Krass.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Henning
flo
Klappt aber natürlich nur dann, wenn man selber nicht auch noch Änderungen an den Daten machen will...
mnemo
Manuel Schmitt (manitu)
Alexander Grümmer
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
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)
SvenW
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
Viele Grüße
Stefan
SvenW
http://dev.mysql.com/doc/refman/5.1/en/binary-log.html
Denis
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