1,5 GB Dump in MySQL einspielen

[Alexander, Ms.]

Hallo,

ich möchte eine grosse (1,5 GB) grosse SQL Datei in die MySQL Datenbank einspielen.. aber so, dass der Server alle andere seine "Jobs" vorrangig macht und erst wenn er Zeit bzw. Platz oder Ressourcen frei hat dann sich mit dem Einspielen beschäftigt.. also sozusamen im Hintergrund.

Bsp.: Auf dem Server werden z.B. 10 Select-Queries pro minute ausgeführt  und dazwischen soll ich (in eine andere DB auf dem gleichen DB-Server) diese Datei einspielen, aber die Select, Update und andre Queries, die nichts mit dem Einspielen zu tun haben müssen vorgezogen werden.

Eingespielt wird mit shell mysql.

Gruss Alexander.

[Vinzenz]

Hallo Alexander,,

ich möchte eine grosse (1,5 GB) grosse SQL Datei in die MySQL Datenbank einspielen.. aber so, dass der Server alle andere seine "Jobs" vorrangig macht und erst wenn er Zeit bzw. Platz oder Ressourcen frei hat dann sich mit dem Einspielen beschäftigt.. also sozusamen im Hintergrund.

[...]

Eingespielt wird mit shell mysql.

Schau Dir mal

nice (man nice)

an.

Freundliche Grüsse,

Vinzenz

[Christian Kruse]

Hallo Vinzenz,

Eingespielt wird mit shell mysql.

Schau Dir mal

nice (man nice)

an.

Falscher Tip. nice wuerde die MySQL-Shell in den Nice-Modus versetzen, die Arbeit wird aber
vom Server gemacht. Die Priorisierung muesste als im MySQL-Server passieren. AFAIK kann der
MySQL-Server aber keine Priorisierung der Jobs.

Grüße,
 CK

[Alexander Ms.]

AFAIK kann der
MySQL-Server aber keine Priorisierung der Jobs.

Das heisst ich habe keine optimale Möglichkeit dazu? :-( schade.. Wenn ich das Einspielen so starte dann werden laut "phpMyAdmin Prozessenanzeige" alle andere prozesse blockiert. Und bis die Daten eingespielt sind dauert ein Paar Stunden. Bis dahin stauen sich Hunderte von Select und andere Anfragen und alle User sind weg :-)

Gruss A.W.

[TomIRL]

AFAIK kann der
MySQL-Server aber keine Priorisierung der Jobs.

Das heisst ich habe keine optimale Möglichkeit dazu? :-( schade.. Wenn ich das Einspielen so starte dann werden laut "phpMyAdmin Prozessenanzeige" alle andere prozesse blockiert. Und bis die Daten eingespielt sind dauert ein Paar Stunden. Bis dahin stauen sich Hunderte von Select und andere Anfragen und alle User sind weg :-)

Selbst Ebay leistet sich den Luxus eines Wartungsfensters und die beste Zeit ist in der Nacht vom Sonntag auf Montag ab 2:30 da dürften 1,5 GB dann auch in 1-2 Stunden drin sein..
Außerem was ist den in Deiner DB alles drin?
Ein Haufen Blobs?
Da gibs gerade für MySQL doch wesentlcich elegantere Lösungen..
Warum Wenn Du schon auf der Shell arbeitest warum dann eigentlich ein Dump?
Warum nicht die Tabellen komplett isn Verzeichniss kopieren, mit ner einigemaßen guten Standleitung kein Problem oder?

[Tom]

Hello,

Warum nicht die Tabellen komplett isn Verzeichniss kopieren, mit ner einigemaßen guten Standleitung kein Problem oder?

Das habe ich hier neulich auch schon mal zum Besten gegeben. Nachdem Thomas der Andere seine Abschlussarbeit zu diesem Thema geschrieben hatte, waren wir uns nämlich ganz sicher, dass das die Möglichkeit mit der kürzesten Offtime ist (Bei der Datenmenge ca. 3-4 Minuten).

Bei SQL-DBMS mit Transaction Log sieht das anders aus. Allerdings bietet auch MySQL eine Synchronisationsmöglichkeit zwischen zwei Servern. Das haben wir aber auch verworfen, weil dafür entweder eine schnelle Datenverbindung vorhanden sein muss oder eine dauerhafte. Für Offline-Kopplungen über normales SDSL also nicht geeignet.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Andreas Korthaus]

Hi!

Warum nicht die Tabellen komplett isn Verzeichniss kopieren, mit ner einigemaßen guten Standleitung kein Problem oder?

Das habe ich hier neulich auch schon mal zum Besten gegeben. Nachdem Thomas der Andere seine Abschlussarbeit zu diesem Thema geschrieben hatte, waren wir uns nämlich ganz sicher, dass das die Möglichkeit mit der kürzesten Offtime ist (Bei der Datenmenge ca. 3-4 Minuten).

Wieso so lange? Es reicht doch die Dateien unter anderem Namen hochzuladen, Server runterfahren, Dateien umbenennen, Server hochfahren, das sollte doch in wenigen Sekunden gehen, oder?

In einigen Fällen kann man auch damit leben, dass man die Daten in eine andere Datenbank (evtl. eine Kopie der originalen) läd, und dann die neue DB umbenennt (in den Namen der originalen).

Hängt allerdings stark vom Einzelfall ab, was der geeignete Weg ist, oder ob sowas überhaupt möglich ist.

Grüße
Andreas

[Tom]

Hello,

Wieso so lange? Es reicht doch die Dateien unter anderem Namen hochzuladen, Server runterfahren, Dateien umbenennen, Server hochfahren, das sollte doch in wenigen Sekunden gehen, oder?

In einigen Fällen kann man auch damit leben, dass man die Daten in eine andere Datenbank (evtl. eine Kopie der originalen) läd, und dann die neue DB umbenennt (in den Namen der originalen).

Interessante Idee.

Allerdings dürfen ja die aktuellen Dateien keinesfalls verloren gehen, bevor das Wiederherstellen abgeschlossen erfolgreich ist.

Um das also nochmals aufzugreifen:

Dateien in Seelenruhe unter dem richtigen Namen in ein zweites Verzeichnis hochladen.
Den ganzen Rotz sinnvollerweise nochmals in ein Drittes Verzeichnis kopieren
Tables sperren
Tables fluchen
Server runterfahren
Change-Log in das neue Verzeichnis kopieren
altes Verzeichnis umbenennen
neues Verzeichnis mit Produktivnamen versehen
Server im Admin-Mode hochfahren (alle Datenbanken sind für Otto-Normal gesperrt
Change-Log VOR dem "Drop all Tables" oder was auch immer den Chrach verursacht hat, kappen
Change-Log einspielen
Sichtkontrolle und  programmierte Checks laufen lassen.
Wenn alles OK ist,
--Change-Log kopieren in backup-Bereich
--Change-Log rücksetzen
--Datenbanken und Tables für Otto-Normalo freigeben
Wenn nicht, Panik im Gesicht:
--Nochmalige Kopie der Upload-Dateien
--Change-Log noch restriktiver kürzen
--und den ganzen Vorgang von eben sooft wiederholen, bis Erfolg

Man Sollte auch nicht vergessen, bei fehlerfreiem Betrieb das Chenga-Log gelegentlich (so ca. 1-24 mal täglich) zu sichern und zu kappen und nach jedem fehlerfreien Fullbackup rückzusetzen.

Du siehst hoffentlich ein, dass das eine Abschlussarbeite wert war.
Die war übrigens nach meinem Dafürhalten sehr gut gelungen, allerdings habe die Prüfer vom IHK-Prüfungsausschuss sie nicht verstanden. Ist schon Scheiße, wenn Fachleute von Laien geprüft werden!

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[lulu]

Huhu Alexander

Das heisst ich habe keine optimale Möglichkeit dazu? :-( schade..

Evtl. kannst Du einfach die entsprechenden Dateien kopieren.
Typischerweise hast du drei Dateien je Tabelle im Datenverzeichnis liegen.

Also z.B. im Ordner

/var/mysql/data/NAMEDERDATENBANK/

NAMEDERTABELLE.MYD (die Daten)
NAMEDERTABELLE.MYI (die Indexdaten)
NAMEDERTABELLE.frm (die Strukturbeschreibung der Tabelle)

die kannst Du einfach kopieren.

Viele Grüße

lulu

[Tom]

Hello,

Evtl. kannst Du einfach die entsprechenden Dateien kopieren.
Typischerweise hast du drei Dateien je Tabelle im Datenverzeichnis liegen.

Also z.B. im Ordner

/var/mysql/data/NAMEDERDATENBANK/

NAMEDERTABELLE.MYD (die Daten)
NAMEDERTABELLE.MYI (die Indexdaten)
NAMEDERTABELLE.frm (die Strukturbeschreibung der Tabelle)

die kannst Du einfach kopieren.

Aber den Deamon vorher herunterfahren!

Und die Differenzen seit dem letzen Upload kann man bei MySQL gesondert registrieren lassen. Das Änderugnslog kann man dann an jedem beliebigen Punkt abbrechen, damit man nicht den "DROP ALL TABLES" doch wieder drin hat.

Sollten die also noch nicht zu lange korrumpiert worden sein, dann kann man sie anschließend wieder oben auflegen und hat dann fast den aktuellen Stand erreicht.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Vinzenz]

Hallo Christian,

danke für die Klarstellung.

Falscher Tip. nice wuerde die MySQL-Shell in den Nice-Modus versetzen, die Arbeit wird aber

und somit könnte es ein klein wenig länger dauern, bis sie zum Zuge kommt, ein paar Millisekunden später.

vom Server gemacht. Die Priorisierung muesste als im MySQL-Server passieren. AFAIK kann der
MySQL-Server aber keine Priorisierung der Jobs.

Schade (nicht nur) für den OP.

Freundliche Grüsse,

Vinzenz

[Alexander Ms.]

Hallo,

ich möchte eine grosse (1,5 GB) grosse....

also mit

nice mysql -u.. p.. db < datei.sql

Funktioniert es.. die Selects wewrden offensichtlich vorgezogen und die datei wird auch eingespielt. Die Website ist zwar selbst etwas langsamer geworden.. ist aber nochg geduldmäßig aufrufbar.

Danke.

Gruss Alexander.

[Michael]

Hallo

Warum schreibst du nicht einfach ein kleines Programm, welches den Dump tröpfchenweise einliest und in die DB einfüllt? Wenn das Programm pro Minute 100 Queries an den Server abschickt dann sind sicher noch genug Ressourcen für die normalen User vorhanden. Das Einspielen dauert dann aber auch wesentlich länger.

Gruss

Michael

[Tom]

Hello,

Warum schreibst du nicht einfach ein kleines Programm, welches den Dump tröpfchenweise einliest und in die DB einfüllt? Wenn das Programm pro Minute 100 Queries an den Server abschickt dann sind sicher noch genug Ressourcen für die normalen User vorhanden. Das Einspielen dauert dann aber auch wesentlich länger.

Es kommt immer darauf an, wie ein Dump entsteht und wir die übrige Applikation auf das Einspeilen eines solchen reagiert.

Man kann i.d.R. einen Snapshot (Dump) nur exclusiv wieder einspielen. Die Integrität der Referenzen zwischen den Tabellen bleibt nur gewahrt, wenn keine andere Operation "dazwischenfunkt".

Datensicherheit und Datensicherung sowie deren Wiederherstellung ist nichts für "zwischendurch". Damit kann man sich jahrelang beschäftigen und kommt nur sehr schwer zu neuen Erkenntnissen. Die sollte man dann aber gaaanz fest halten.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom