nicht angemeldet
MySql frm MYD MYI download riskant?
0
MySql frm MYD MYI download riskant?
Hallo,
Bisher transportiere ich oft die physischen MYSQL Files von
DB A nach DB B. Das war und ist immer sehr angenehm, wenn
die Tabellen recht gross sind.
Jetzt wurde mir gesagt, dass sowas gefährlich sein könnte
und die Tabellen dadurch zerstört werden könnten, wenn
sie gerade etwas abarbeiten während ich meinen Download ausführe.
Ist das wahr?
Ich habe zwar keine Ahnung wie Mysql intern funktioniert,
aber theoretisch könnte es ja wahr sein, weil sich die
Tabelle ja ändert wärend ich sie runterlade.
Und das runterladen dauert eine Weile bei 5-10 GB Dateien.
Gibt doch bestimmt ein paar DB Profis hier, die das wissen, oder?
vg.
Roland
-
Gibt doch bestimmt ein paar DB Profis hier, die das wissen, oder?
Der Datenserver hält die "DB-Dateien" entweder permanent geöffnet oder öffnet und schliesst sie regelmässig.
Das blosse Kopieren der Dateien ist in beiden Fällen nicht zu empfehlen. Lass mal eine consistency-checker auf Deine DBs und schau, ob noch alles senkrecht ist.Normalerweise macht man also (auch im laufenden Betrieb, bspw. zu unpopulären Besuchszeiten) ein Backup. Informiere Dich darüber und transportiere in der Folge Backup-Dateien.
-
Hi,
Der Datenserver hält die "DB-Dateien" entweder permanent geöffnet oder öffnet und schliesst sie regelmässig.
soweit schon klar
Das blosse Kopieren der Dateien ist in beiden Fällen nicht zu empfehlen. Lass mal eine consistency-checker auf Deine DBs und schau, ob noch alles senkrecht ist.
»»
DBs scheinen in Ordnung, keine Probleme bisher.
Aber meine Angst ist jetzt natürlich noch grösser und die Antwort
auf meine Frage demnach umso wichtiger für mich.Also warum ist dasnicht zu empfehlen? Was genau kann dann passieren
und wieso?Ich meine wenn ich das jetzt mal mit filebased Datenbanken ala
SQLITE vergleiche, da kann doch auch nichts passieren, wenn da noch
Prozesse laufen.Normalerweise macht man also (auch im laufenden Betrieb, bspw. zu unpopulären Besuchszeiten) ein Backup. Informiere Dich darüber und transportiere in der Folge Backup-Dateien.
Ja, aber ich dachte, wie bestimmt viele andere auch, das nur deshalb
um die Serverlast nicht im Hochbetrieb überzustrapazieren.Gruss und Dank
Roland-
Der Datenserver hält die "DB-Dateien" entweder permanent geöffnet oder öffnet und schliesst sie regelmässig.
soweit schon klar
D.h. die Files sind "in use"...
Das blosse Kopieren der Dateien ist in beiden Fällen nicht zu empfehlen. Lass mal eine consistency-checker auf Deine DBs und schau, ob noch alles senkrecht ist.
»»DBs scheinen in Ordnung, keine Probleme bisher.
Aber meine Angst ist jetzt natürlich noch grösser und die Antwort
auf meine Frage demnach umso wichtiger für mich.Also warum ist dasnicht zu empfehlen? Was genau kann dann passieren
und wieso?Na, im Zweifelsfall hast Du da (im Ergebnis) nichts Halbes und nichts Ganzes, wenn Du dem DBMS im Betrieb "hinten herum" die Files "wegkopierst".
Ich meine wenn ich das jetzt mal mit filebased Datenbanken ala
SQLITE vergleiche, da kann doch auch nichts passieren, wenn da noch
Prozesse laufen.Warum nicht?
Normalerweise macht man also (auch im laufenden Betrieb, bspw. zu unpopulären Besuchszeiten) ein Backup. Informiere Dich darüber und transportiere in der Folge Backup-Dateien.
Ja, aber ich dachte, wie bestimmt viele andere auch, das nur deshalb
um die Serverlast nicht im Hochbetrieb überzustrapazieren.Warum machst Du denn keinen Dump?
Und nebenbei: Was passiert mit den kopierten Dateien? Werden die irgendwo wieder einem DBMS zugeführt oder dienen die der Sicherung?
Nick
--
--------------------------------------------------
http://www.xilp.eu
XILP Internet Links People
Dein persoenliches privates Netzwerk
aus Freunden, Verwandten, Bekannten und Kollegen.
--------------------------------------------------
Hamburg Berlin München-
Hi,
Na, im Zweifelsfall hast Du da (im Ergebnis) nichts Halbes und nichts Ganzes, wenn Du dem DBMS im Betrieb "hinten herum" die Files "wegkopierst".
Ja, so denke ich mir das auch. Nur ich sagte ja, dass ich keine
Ahnung von DB Intera habe und ich mich frage, wo jetzt der
Unterschied zu normalen Files ist. Ich meine damit ganz normale
Medien oder sonstwas an grossen Dateien, die ja auch abertausende Mal
bei bekannten Webseiten runtergeladen werden, während diese
auch u.U. gerade bearbeitet werden.Warum machst Du denn keinen Dump?
Weil ich keinen blassen Schimmer habe, wie ich 5 Gigabyte Tabellen
wieder in Mysql importiert bekomme. Zumindest versagt mir
PHP schon bei wesentlich kleineren Größen.Und nebenbei: Was passiert mit den kopierten Dateien? Werden die irgendwo wieder einem DBMS zugeführt oder dienen die der Sicherung?
Meisstens ist es so, dass ich die aktuellen von einem Server nehme
und dann local einfüge um damit zu testen, aber auch um andere Server
damit zu bestücken.Gruss
Roland-
Warum machst Du denn keinen Dump?
Weil ich keinen blassen Schimmer habe, wie ich 5 Gigabyte Tabellen
wieder in Mysql importiert bekomme. Zumindest versagt mir
PHP schon bei wesentlich kleineren Größen.Dann stell den Datenserver ab. Wenn Du das nicht kannst, dann unterbinde wenigstens den Datenzugriff für eine gewisse Zeit (5 Minuten?).
Meisstens ist es so, dass ich die aktuellen von einem Server nehme
und dann local einfüge um damit zu testen, aber auch um andere Server
damit zu bestücken.Und nie ist etwas schiefgegangen. Das spricht für MySQL. :)
-
Warum machst Du denn keinen Dump?
Weil ich keinen blassen Schimmer habe, wie ich 5 Gigabyte Tabellen
wieder in Mysql importiert bekomme. Zumindest versagt mir
PHP schon bei wesentlich kleineren Größen.Dann stell den Datenserver ab. Wenn Du das nicht kannst, dann unterbinde wenigstens den Datenzugriff für eine gewisse Zeit (5 Minuten?).
5 Minuten für 5 Gigabyte, na du musst ja eine
XXXXXL Highspeedleitung haben!?Roland
-
Also gut, mach ein ordentliches Backup, verschiedenste Möglichkeiten werden hier vorgestellt:
http://dev.mysql.com/doc/refman/5.1/de/backup.html(Es ist nicht ganz überraschenderweise die Doku. ;)
-
Also gut, mach ein ordentliches Backup, verschiedenste Möglichkeiten werden hier vorgestellt:
http://dev.mysql.com/doc/refman/5.1/de/backup.html(Es ist nicht ganz überraschenderweise die Doku. ;)
Ja das kenne ich auch schon, nur ist das eher Konsolenarbeit,
vor der ich mangels Kenntnis im Normalfall zurückschrecke.Aber anscheinend bleibt mir wohl nichts anders übrig.
Roland
-
-
-
-
echo $begrüßung;
Ja, so denke ich mir das auch. Nur ich sagte ja, dass ich keine
Ahnung von DB Intera habe und ich mich frage, wo jetzt der
Unterschied zu normalen Files ist. Ich meine damit ganz normale
Medien oder sonstwas an grossen Dateien, die ja auch abertausende Mal
bei bekannten Webseiten runtergeladen werden, während diese
auch u.U. gerade bearbeitet werden.Man muss da Mechanismen einsetzen, die es nicht gestatten, dass weitere Zugriffe stattfinden, wenn gerade etwas kritisches wie ein Schreibvorgang stattfindet. Locking bzw. file locking wären hier Stichwörter.
Wenn Schreibvorgänge länger dauern, kann man auch selbige auf einer zweite Datenhaltung ausführen, die dann in einem schnelleren (als die Bearbeitung) Kopiervorgang den Leseprozessen übergeben wird.
Flickr hatte mal eine Dokumentation seines Systems ins Netz gestellt. Die haben, wenn ich mich recht erinnere, eine transaktionssichere Datenbank für Schreibzugriffe verwendet und die Lesezugriffe auf eine mit Volltext-Index geleitet. Beides zusammen geht ja bei MySQL nicht. Somit kommen sich diese Vorgänge erstmal nicht ins Gehege. Ob das auch zur Performancesteigerung diente, damit die Lesevorgänge nicht ausgebremst werden, weiß ich nicht mehr. Auch nicht mehr, wie der Übergabemechanismus von der Schreib-DB in die Lese-DB stattfindet.
Warum machst Du denn keinen Dump?
Weil ich keinen blassen Schimmer habe, wie ich 5 Gigabyte Tabellen
wieder in Mysql importiert bekomme. Zumindest versagt mir
PHP schon bei wesentlich kleineren Größen.Dann machst du was falsch. Wenn du versuchst, die Datei komplette einzulesen, erleidest du sicher nicht nur in PHP Schiffbruch, denn 5 GB RAM - möglicherweise wird auch ein Vielfaches davon während der Bearbeitung benötigt - sind noch nicht gerade übliche Ausbaustufen für Wald- und Wiesen-Rechner. Warum willst du überhaupt PHP zum Import einsetzen? Schon wesentlich kleinere Datenmengen lassen sich über MySQLs Kommandozeilenschnittstelle deutlich schneller einlesen.
echo "$verabschiedung $name";
-
-
-
Das blosse Kopieren der Dateien ist in beiden Fällen nicht zu empfehlen. Lass mal eine consistency-checker auf Deine DBs und schau, ob noch alles senkrecht ist.
DBs scheinen in Ordnung, keine Probleme bisher.
Aber meine Angst ist jetzt natürlich noch grösser und die Antwort
auf meine Frage demnach umso wichtiger für mich.Was heisst denn "scheinen in Ordnung" für Dich? Hast Du die Daten auf Konsistenz geprüft oder nicht?
Also warum ist dasnicht zu empfehlen? Was genau kann dann passieren
und wieso?Da kann theoretisch alles passieren, das Kopieren von offenen Dateien, auf denen ausgerechnet noch ein Datenserver sitzt, ist schon sehr uncool.
Im schlimmsten Fall hast Du korrupte Seiten und Datenverlust (bis zu 100% ;).Ich meine wenn ich das jetzt mal mit filebased Datenbanken ala
SQLITE vergleiche, da kann doch auch nichts passieren, wenn da noch
Prozesse laufen.Wieso nicht?
Normalerweise macht man also (auch im laufenden Betrieb, bspw. zu unpopulären Besuchszeiten) ein Backup. Informiere Dich darüber und transportiere in der Folge Backup-Dateien.
Ja, aber ich dachte, wie bestimmt viele andere auch, das nur deshalb
um die Serverlast nicht im Hochbetrieb überzustrapazieren.*BRRR* - Du hast doch ein solides IT-Verständnis.
Aber es ist natürlich auch gut möglich, dass es keinen Datenverlust gegeben hat. Kann ja sein. Also mal die DBs prüfen.
-
-