Wo liegen MySQL-DBs im Dateisystem?

[master_p]

Da mir hier ja anscheinend keiner direkt helfen konnte, stelle ich hier nochmal eine Teilfrage daraus.

Wo liegen die MySQL-Datenbanken im Dateisystem? Den genauen Ort bräuchte ich nämlich, um ein Backup einzuspielen.

Ach und wenn mir noch jemand sagen könnte, wie ich MySQL über's Terminal neustarte, dann wäre das klasse. Bzw. eigentlich nur, wo MySQL liegt, denn das "mysqld -restart" weiß ich ja schon.

Gruß Philip

 

[mys]

Die Daten liegen unter:
/usr/local/mysql/data

Ist jedoch abhängig von der MySQL Version die Du hast.

 

[master_p]

Hmm also ich habe gerade gemerkt, dass mein aktueller MySQL-Server (laut phpMyAdmin) ein 4.0.21 ist.

Im Verzeichnis /ust/local/ liegen folgende Ordner:
mysql
mysql-standard-4.1.9-apple-darwin6.8-powerpc
mysql-standard-4.1.20-apple-darwin8.6.0-powerpc

Wobei der "mysql"-Ordner nur ein symbolischer Link auf "mysql-standard-4.1.20-apple-darwin8.6.0-powerpc" ist. Von daher sollte doch entweder ein 4.1.9 oder ein 4.1.20 laufen. Auf jeden Fall einer, der schon die Kollation kann. Wo genau kommt denn jetzt der 4.0.21 her? Auf jeden Fall will ich den weg haben. Kann ich denn irgendwo in dem Verzeichnis "mysql-standard-4.1.20-apple-darwin8.6.0-powerpc" den Server manuell starten? Im /bin-Verzeichnis gibt's zwar eine mysqld, aber wenn ich dort "mysqld -restart" eingebe, kommt: -bash: mysqld: command not found



EDIT:
Ich habe gerade neugestartet, um zu sehen, ob der Server gestartet wird, und ja er wird's. Obwohl mein Systemeinstellungen-Panel den Haken nicht gesetzt hat. Da scheint also irgendwo noch ein Startobjekt herumzusausen, dass ich nicht finde.

EDIT2:
So ich habe das Startobjekt jetzt mal entfernt und neugestartet. Jetzt funktioniert es wieder wie es soll - inklusive Systemeinstellungs-Panel. Aber ich frage mich trotzdem, wo der Uralt-MySQL-Server in meinem System steckt Ô_o

Gruß Philip

 

[Pingu]

Wo die Daten für die MySQL-Datenbank liegen, hängt davon ab wie die Konfiguration ist. Diese ist wiederum abhängig davon von wo Du Dein MySQL bezogen hast. Bei mir befinden sich diese z.B. in /usr/local/mysql/support-files/.

Aber unabhängig davon ist es sowieso dringend abzuraten die MySQL-Datenbanktabelle direkt zusichern und später direkt zurück zu spielen. Denn wenn sich durch ein Update das Dateiformat ändert, kann man alles wegschmeißen. Daher steht in den FAQ bei mysql.com auch, daß ein Backup immer mit Hilfe von mysqldump oder entsprechenden Tools durchgeführt werden soll. Jedoch soll man nie die Datenbank-Dateien selbst einfach kopieren.

Pingu

 

[Wolfgang Rausch]

Wo die Daten für die MySQL-Datenbank liegen, hängt davon ab wie die Konfiguration ist. Diese ist wiederum abhängig davon von wo Du Dein MySQL bezogen hast. Bei mir befinden sich diese z.B. in /usr/local/mysql/support-files/.

Aber unabhängig davon ist es sowieso dringend abzuraten die MySQL-Datenbanktabelle direkt zusichern und später direkt zurück zu spielen. Denn wenn sich durch ein Update das Dateiformat ändert, kann man alles wegschmeißen. Daher steht in den FAQ bei mysql.com auch, daß ein Backup immer mit Hilfe von mysqldump oder entsprechenden Tools durchgeführt werden soll. Jedoch soll man nie die Datenbank-Dateien selbst einfach kopieren.

Pingu

Was passiert bei irgendwelchen Backups? Wenn ich z.b. meine Festplatte sichere?

Irgendwie scheint MySQL an der Stelle gravierende Schwächen zu haben. Meine FileMaker-Datenbanken können ja problemlos kopiert werden.

 

[Pingu]

Bei FileMaker aber auch nur, wenn es die selbe FileMaker-Version ist. Wenn nicht, müssen die Daten erst konvertiert werden. Auch hier gibt es Probleme, auch wenn die offizielle Redensart etwas anderes suggeriert.

Das gleiche gilt für MySQL. Solange man mit der selben Version arbeitet kann man es machen. Aber man sollte es nie machen. Denn wer weiß, ob man gerade nach einem Crash nicht die Möglichkeit nutzt und gleiche eine neuere Version aufspielt. Für MySQL gibt es sogar ein eigenes Kapitel im Handbuch zum Thema Backup. Mir ist natürlich klar, die wenigsten nehmen sich die Zeit und Muse und lesen ein Handbuch. Obwohl da irgendwie die Standardprobleme immer angesprochen werden .

Das galt und gilt schon immer für alle Datenbanken.


Pingu

 

[Wolfgang Rausch]

Bei FileMaker aber auch nur, wenn es die selbe FileMaker-Version ist. Wenn nicht, müssen die Daten erst konvertiert werden. „Kindergarten!!“ Auch hier gibt es Probleme, auch wenn die offizielle Redensart etwas anderes suggeriert.

Das gleiche gilt für MySQL. Solange man mit der selben Version arbeitet kann man es machen. Aber man sollte es nie machen. Denn wer weiß, ob man gerade nach einem Crash nicht die Möglichkeit nutzt und gleiche eine neuere Version aufspielt. Für MySQL gibt es sogar ein eigenes Kapitel im Handbuch zum Thema Backup. Mir ist natürlich klar, die wenigsten nehmen sich die Zeit und Muse und lesen ein Handbuch. Obwohl da irgendwie die Standardprobleme immer angesprochen werden .

Das galt und gilt schon immer für alle Datenbanken.


Pingu

Das hatte ich eigentlich vorausgesetzt.

Oder glaubst du tatsächlich, ich sehe erst nach Updates, wenn ich eine meiner FileMaker-Datenbanken bearbeiten will? Außerdem generiert FileMaker in den meisten Fällen eine Datei, die dann problemlos kopiert werden kann. Es sei denn, ein Update macht mir einen Strich durch die Rechnung …

 

[Pingu]

Das hatte ich eigentlich vorausgesetzt.

Es sei denn, ein Update macht mir einen Strich durch die Rechnung …

Was denn nun?

Ich habe noch jede Menge FileMaker Pro 2.1 Daten. Hierfür gibt es keine Garantie von FileMaker, dass diese konvertiert werden könne.
Ich habe FileMaker 3 Daten. Diese lassen sich nach offizieller Redensart konvertieren, aber leider nur mit Hindernissen.

Deshalb galt schon immer für jede Datenbank, das Backup im Datenbank-unabhängigen Format abzulegen. Wie das bei MySQL geht ist dort im Handbuch beschrieben. Das Datenbank-unabhängige Format bei MySQL ist eine Datei mit SQL-Befehlen. Das heißt sie plötzlich sogar noch auf andere Datenbanken (Postgres, Oracle, DB2, usw.) übertragbar.

Also wo ist das Problem?

Pingu