Donnerstag, 5. April 2007
13 GB SQL-Dumps
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
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 
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...
Klappt aber natürlich nur dann, wenn man selber nicht auch noch Änderungen an den Daten machen will...
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
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
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.
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.
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!
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.
mysqlbinlog logfilename --database=dbname | gzip > updatelog.gz
jagen, dann gibt es in der gz-Datei nur die tatsächlichen Änderungen der der fraglichen Datenbank.
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
Viele Grüße
Stefan
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
http://dev.mysql.com/doc/refman/5.1/en/binary-log.html
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
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
IPv4 vs. IPv6
Du bist hier via
Suche
Ökostrom
Kalender
Kommentare
zu 64 Kerne
Do, 24.05.2012 00:23
Nen bißchen Seti und wir überh
olen die Amis und stehen auf P
latz 1
zu 64 Kerne
Mi, 23.05.2012 20:45
Selbst bei dieser Kiste sollte
man ein klein wenig SWAP anbi
eten....
zu 64 Kerne
Mi, 23.05.2012 20:39
Müssen wir in Tschernobyl den
Reaktor wieder hoch fahren, we
nn das Teil auf volllast läuft
zu 64 Kerne
Mi, 23.05.2012 20:03
Swap? Auf so einer Kiste?
Sel
bst wenn der auf einer PCIe-RA
Mdisk liegt, versaut es Dir di
e Auslastung der Cores, [...]
zu 64 Kerne
Mi, 23.05.2012 16:22
genau, das meinte ich, danke!
kannte ich noch gar nicht, seh
r schönes Spielzeug, dieses ht
op
