nicht angemeldet
phpmyadmin tabellen "weg"
Guten Morgen,
ich habe ein Problem, nach dem ich auf meinem Linux Server (Xampp) im laufenbetrieb eine MySQL Datenbank kopiert habe, kann ich im phpmyadmin alle Datenbanken sehen in den Klammern nach dem Datenbanknamen steht auch noch die Anzahl der Tabellen, und wenn ich dann die gewünschte Datenbank anwähle sieht man keine Tabelle mehr :( .
Jedoch sind alle Datenbankwerte mit php noch abrufbar.
Woran könnte das liegen ? Gibt es irgendwelche index dateien oder so für Datenbank die irgendwie beim kopieren gelöscht habe oder so ?
Für eure Hilfe wäre ich sehr dankbar :) .
-
echo $begrüßung;
ich habe ein Problem, nach dem ich auf meinem Linux Server (Xampp) im laufenbetrieb eine MySQL Datenbank kopiert habe, kann ich im phpmyadmin alle Datenbanken sehen in den Klammern nach dem Datenbanknamen steht auch noch die Anzahl der Tabellen, und wenn ich dann die gewünschte Datenbank anwähle sieht man keine Tabelle mehr :( .
Was genau hast du gemacht? Welche Dateien hast du kopiert? Welche Konfigurationswerte hast du danach geändert? Um welche Database Engine handelt es sich (MyISAM, InnoDB, ...)?
Jedoch sind alle Datenbankwerte mit php noch abrufbar.
Was macht der anders als der phpMyAdmin? Verwenden die beiden unterschiedliche Logins? Verbinden sie sich zum gleichen Server? Mit der gleichen Methode (Socket oder TCP/IP)?
Woran könnte das liegen ? Gibt es irgendwelche index dateien oder so für Datenbank die irgendwie beim kopieren gelöscht habe oder so ?
Kommt auf das Speicherformat der Database Engine an.
echo "$verabschiedung $name";
-
Also ich habe nur den ordner $datenbankname einfach kopiert (alle Dateien).
Wie genau oder richtig der Befehl ?!? mit cp ....Ich habe überhaupt keine Konfigurationswerte geändert !
MySQL - 5.0.24a-log
MyISAM Default engine as of MySQL 3.23 with great performanceAlso mit show tables in phpmyadmin zeigt der alle tabellen an... !!
Die verbinden alle zum gleichen Server bzw localhost....
also ich habe mal nachgesehen zu jeder Tabelle ist *.myd,*.myi, *.myd*, .frm
Datei vorhanden plus db.opt ansonsten befindet sich nichts im Ordner der datenbank....-
Hello,
hast Du denn auch die mysql-Datenbank kopiert?
In dieser stehen die Rechte für die User.
MySQL arbeitet nach dem Prinzip der Einschränkungen.
Sind keine Einschränkungen vorhanden, dann sind auch alle Rechte vorhanden.
Erst wenn eine generelle Einschränkung besteht, kann man diese wieder durch zusätzliche (positive) Rechte lockern.Liebe Grüße aus Dortmund
Tom vom Berg
-
Nein ich habe meine persönliche Datenbank kopiert...
Dateirechte für die *.myi *.myd usw...
-rw-rw---- 1 nobody nogroup
-
echo $begrüßung;
Nein ich habe meine persönliche Datenbank kopiert...
Dateirechte für die *.myi *.myd usw...
-rw-rw---- 1 nobody nogroupUnter welcher Kennung läuft der MySQL-Server? Hast du ihn nach dem Kopieren neu gestartet? Zeigt die Einstellung datadir auf das richtige Verzeichnis (SHOW VARIABLES LIKE 'datadir')?
nobody, nogroup findet weitere Verwendung für andere Software. Du wirst sicher nicht wollen, dass diese auch auf die Datenbank zugreifen dürfen.
echo "$verabschiedung $name";
-
unter root läuft mysql...
nach dem kopieren habe ich neugestartet....Da zeigt die datadir drauf -> /opt/lampp/var/mysql
und in dem verzeichnis sind die datenbanken alle...-
echo $begrüßung;
nach dem kopieren habe ich neugestartet....
Du könntest ein "REPAIR TABLE tablename" probieren. Mehr wüsste ich auch nicht.
echo "$verabschiedung $name";
-
-
-
Moin!
Nein ich habe meine persönliche Datenbank kopiert...
Du hast den bzw. die (wenn du von einem anderen Server kopiert hast) MySQL-Server vor der Aktion also nicht heruntergefahren (und danach wieder gestartet)?
- Sven Rautenberg
--
"Love your nation - respect the others."-
Ja während des Betriebes...
-
Moin!
Ja während des Betriebes...
Was "ja"?
"Ja", du hast den MySQL-Server während des Betriebs heruntergefahren?
Oder "ja", du hast während des laufenden Betriebs kopiert, ohne den MySQL-Server herunterzufahren?
Wenn du den Server nicht heruntergefahren hast, dann könntest du dir deine Datenbank zerstört haben, mindestens aber dürfte MySQL nichts von dem Kopieren mitbekommen haben und seine internen Verwaltungsinformationen noch nicht aktualisiert haben.
Es ist NIEMALS ratsam, an den Datenbank-Files eines laufenden DB-Servers herumzuspielen!
Es ist ebenfalls nicht ratsam, ohne Prüfung der äußeren Bedingungen Datenbank-Files einfach so zu kopieren. Für sowas macht man sich einen Datenbank-Dump (eine Auflistung aller SQL-Befehle, die die betroffene Datenbank 1:1 wieder in den DB-Server hineinpackt, also sowohl die notwendigen CREATE-Befehle als auch INSERTs für die enthaltenen Daten), den man dann wieder in die Datenbank einspeist.
- Sven Rautenberg
--
"Love your nation - respect the others."-
yo,
Es ist NIEMALS ratsam, an den Datenbank-Files eines laufenden DB-Servers herumzuspielen!
mal davon abgesehen, dass ein gute backup-strategie, auch damit umgehen können müsste, wenn dateien verschwinden oder zerstört sind, ist diese aussage nicht richtig. warum sollte ich den server herunter fahren, nur weil ich dateien verschieben oder anlegen will ?
Ilja
-
Moin!
yo,
Es ist NIEMALS ratsam, an den Datenbank-Files eines laufenden DB-Servers herumzuspielen!
mal davon abgesehen, dass ein gute backup-strategie, auch damit umgehen können müsste, wenn dateien verschwinden oder zerstört sind, ist diese aussage nicht richtig. warum sollte ich den server herunter fahren, nur weil ich dateien verschieben oder anlegen will ?
Weil ein Datenbankserver (also die Serversoftware) es nicht witzig findet, wenn du seine im laufenden Betrieb geöffneten, zum Lesen und Schreiben benutzten Dateien veränderst und diese sich deshalb nicht mehr mit den sicherlich vorhandenen Cache-Kopien oder internen Datenstrukturen im RAM-Speicher decken.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Also während des Betriebes habe ich den Datenbankordner einfach kopiert auf den gleichen Server...
In der Datenbank funktioniert alles...!
Ausser unter phpmyadmin werden die Tabellen nicht angezeigt..
Geh ich aber über SQl befehl "SHOW TABLES " zeigt der mir alle an !
-
yo,
Weil ein Datenbankserver (also die Serversoftware) es nicht witzig findet, wenn du seine im laufenden Betrieb geöffneten, zum Lesen und Schreiben benutzten Dateien veränderst und diese sich deshalb nicht mehr mit den sicherlich vorhandenen Cache-Kopien oder internen Datenstrukturen im RAM-Speicher decken.
meinst du nicht auch, dass es viel besser wäre, wenn ich dateien verschieben kann, ohne den server herunter fahren zu müssen ?
Ilja
-
Hello,
meinst du nicht auch, dass es viel besser wäre, wenn ich dateien verschieben kann, ohne den server herunter fahren zu müssen ?
redet ihr über die selben Dateien? Du möchtest einem DBMS die DB wegnehmen ohne das DBMS anzuhalten?
MfG
Rouven--
-------------------
sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
Wenn du die Nadel im Heuhaufen nicht findest, zünde den Heuhaufen an.-
yo,
redet ihr über die selben Dateien? Du möchtest einem DBMS die DB wegnehmen ohne das DBMS anzuhalten?
wegnehmen, verschieben oder neu anlegen, letztlich kann ich ein dbms auch hochfahren, ohne dass ich überhaupt eine datenbank habe.
Ilja
-
Sorry aber wäre das vielleicht möglich das mir jemand hilft ?!
-
Hello,
wegnehmen, verschieben oder neu anlegen, letztlich kann ich ein dbms auch hochfahren, ohne dass ich überhaupt eine datenbank habe.
Dann müsstest Du nach dem Erzeugen einen Datenbank vor dem Sichern der Daten aber auf jeden Fall dem Server mitteilen, dass er nun noch alle im Speicher verfügbaren Daten in die Dateien schreiben soll, also seine Buffers leeren soll und anschließend für einen kurzen Moment bitte keine (weiteren) schreibenden Zugriffe auf die Datenbank vornehmen soll. Diese Auszeit muss lang genug sein, um das gesamte Dateienset der Datenbank konsistent zu kopieren. Das geht innerhalb desselben Dateisystems meistens recht schnell.
Danach kann der Datanbankserver auch mit schreibenden Zugriffen weiterarbeiten.
Wenn Sven hier schreibt "den Server herunterfahren", so hat er ganz bestimmt die Kurzform meiner obigen Ausführungen damit gemeint.
Wie Du es mit einer Flatcopy anders machen willst, wüsste ich nicht. Das wäre dann interessant.
Das Verfahren ist immer ohne Transactionlog und Spiegelsystem immer noch das mit der kürzesten Offtime.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
yo,
Wenn Sven hier schreibt "den Server herunterfahren", so hat er ganz bestimmt die Kurzform meiner obigen Ausführungen damit gemeint.
es gibt sicherlich verschiedene verfahren, bestimmte datenbank-dateien zu verschieben oder anzulegen. aber ich würde dazu nicht das dbms herunter fahren, letztlich muss es ja wissen, wohin ich die dateien verschiebe.
ob Sven das damit gemeint hat, dazu kann er sich ja selbst äußern.
Ilja
-
Hello,
es gibt sicherlich verschiedene verfahren, bestimmte datenbank-dateien zu verschieben oder anzulegen. aber ich würde dazu nicht das dbms herunter fahren, letztlich muss es ja wissen, wohin ich die dateien verschiebe.
Ich hatte das so verstanden, dass es um das sichern der Datenbanken ging.
Dazu muss ich nicht unbedingt den Server herunterfahren, aber ich muss vorher die Buffers flushen.
Und am schreibenden Zugriff muss ich das DBMS auch dann hindern, wenn ich mit einem SQL-Dump arbeite, damit meine Datenbank konsistent bleibt.Man muss ich also sowieso überlegen, wie man das DBMS an Veränderungen von Daten hindert, solange man die Sicherung durchführt.
Ausgenommen davon ist auch wieder das Verfahren mit Transaction-Log.ob Sven das damit gemeint hat, dazu kann er sich ja selbst äußern.
Schaun wir mal, dann sehn wir schon ;-)
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
yo,
Ich hatte das so verstanden, dass es um das sichern der Datenbanken ging.
ich habe es anders verstanden, dass es darum ging, grundsätzlich den speicherort der datenbankdateien zu ändern.
Ilja
-
echo $begrüßung;
Ich hatte das so verstanden, dass es um das sichern der Datenbanken ging.
ich habe es anders verstanden, dass es darum ging, grundsätzlich den speicherort der datenbankdateien zu ändern.Meine Lesart des Problems war, dass mindestens das Datenverzeichnis MySQLs umziehen sollte. Allerdings weiß ich nicht, was du uns die ganze Zeit weiszumachen versuchst. MySQL hat nur ein Verzeichnis, unterhalb dessen seine Datenbanken liegen (wenn man mal den Sonderfall InnoDB außer Acht lässt). Dieses kann man mit der Konfigurationseinstellung datadir explizit einstellen. Die Namen der Unterverzeichnisse richten sich nach dem Namen der Datenbanken und die Tabellennamen werden für die Tabellendateinamen herangezogen. Man kann also den Speicherort nur einmal konfigurieren und die Datenbanken und Tabellen nicht mal hier, mal da, mal dort unterbringen oder einzeln verschieben. Wenn man umzieht, dann das gesamte Datenbankverzeichnis oder nichts.
Zurück zum eigentlichen Problem:
Leider hat der OP es trotz Aufforderung nicht geschafft, konkret zu werden, was er denn nun eigentlich wie geändert hat. Bei einer XAMPP-Installation (zumindest unter Windows, ich nehme an, das gilt auch für die Linux-Version) ist kein datadir konfiguriert. Der MySQL-Server findet es relativ zu seinem bin-Verzeichnis. Will man es in einer anderen Relation zum bin-Verzeichnis ablegen, dann muss man datadir konfigurieren. Das, so schrieb musti2008, hat er nicht gemacht. Wenn weiterhin, wie er ebenso schrieb, der Zugriff generell klappt (nur nicht aus dem PMA heraus), dann muss er wohl beides, bin und datadir, verschoben haben. Oder auch nicht. Vielleicht beobachtet und beschreibt er nicht richtig. Wie auch immer. Bei den bisher gegebenen Informationen ist eine Ferndiagnose jedenfalls nicht möglich.echo "$verabschiedung $name";
-
yo,
Allerdings weiß ich nicht, was du uns die ganze Zeit weiszumachen versuchst. MySQL hat nur ein Verzeichnis, unterhalb dessen seine Datenbanken liegen (wenn man mal den Sonderfall InnoDB außer Acht lässt).
ich zitiere noch um die stelle, um die es mir ging.
"Es ist NIEMALS ratsam, an den Datenbank-Files eines laufenden DB-Servers herumzuspielen!"
wie nun mysql seine datenbank-dateien verwaltet, ob diese nur an einer stelle sein können (was ich persönlich als sehr negativ empfinden würde), das ist mir relativ wurscht. bei anderen dbms wie zum beispiel oracle will die instanz nicht runtergefahren sein, letzlich muss ich den dbms ja mitteilen, wohin ich sie verschiebe.
Ilja
-
-
-
-
Hello,
noch eine kleine Ergänzung zum Sichern:
http://dev.mysql.com/doc/refman/5.1/en/mysqlhotcopy.html
MySQL empfiehlt selber mysqlhotcopy anstelle von mysqldump, wenn man myisam-Tabellen benutzt.
Es sind angeblch Perl-Scripte.Dasselbe versuche ich gerade in C++ nachzuprogrammieren und es funktioniert schon ganz anständig.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
-
-
-
-
-
-
-
-
-
-
echo $begrüßung;
MySQL arbeitet nach dem Prinzip der Einschränkungen.
Sind keine Einschränkungen vorhanden, dann sind auch alle Rechte vorhanden.
Erst wenn eine generelle Einschränkung besteht, kann man diese wieder durch zusätzliche (positive) Rechte lockern.Das stimmt so allgemein nicht. Ohne einen Eintrag in der Tabelle mysql.user bekommt man kein Login. Mit Eintrag hat man ja/nein-Felder für die generellen Rechte. Das ist also schon mal eine explizite Rechtevergabe. Erst für Datenbanken, Tabellen und Felder gibt es das Prinzip "kein Eintrag - keine Einschränkung". Und dann sind die Rechte für diese Einträge nicht zusätzlich hinzuzufügen sondern auch wieder vorhandene ja/nein-Felder.
echo "$verabschiedung $name";
-
-
-