| Linux/UNIX Linuxverfechter finden hier Weggefährten. |
Diskussion: [Problem] ibdata1 viel zu groß im Forum Linux/UNIX, in der Kategorie Operating Systems; Anzeige Hallo! Folgendes Problem: Auf einem Webserver ist die ibdata1 ~60GB groß, dadurch ist die Partition voll und ich kann ...
![]() |
| | #1 (permalink) |
| Anzeige Hallo! Folgendes Problem: Auf einem Webserver ist die ibdata1 ~60GB groß, dadurch ist die Partition voll und ich kann den mysql-Daemon nicht neu starten. Dadurch kann ich aber auch nicht über phpMyAdmin o.ä. nach schauen welche Tabelle überhaupt mit InnoDB gespeichert sind, natürlich kann ich auch die Datenbank nicht neu aufsetzen weil ich keine tables dropen kann ohne laufenden mysql-Daemon ... [ERROR] Can't start server: can't create PID file: No space left on device Gibt es irgendeine Möglichkeit hier noch etwas zu retten oder 'einfach' mal das idbdata1-file verschieben und dann schauen ob sich MySQL neu starten lässt? | |
| | |
| | #2 (permalink) |
| Member of Honour ![]() | hast du bei dir daheim ein Testsystem, wo der gesamte /var/lib/mysql-Ordner drauf passt? Wenn ja: dann versuch mal, das gesamte Verzeichnis herunter zu laden (auch wenn es Stunden bis Tage dauern kann), bei dir lokal den MySQL-Server mit diesem Verzeichnis zu füttern und zu schauen, welche Tabelle so groß ist... |
| | |
| HaBOT | - Anzeige - |
| |
| | #3 (permalink) |
| Themenstarter | Danke für die Antwort! Ich habe jetzt folgendes gemacht: Die ibdata1 auf eine andere Partition verschoben, runterladen hätte wohl wirklich Tage gedauert und mysql neu gestartet. Es sind fast alle Tabellen MyISAM, nur ein paar Tabellen von typo3-Extensions (eines der CMS die auf dem Server laufen) hatten InnoDB als Engine. Ohne diese ~60 GB funktioniert auch alles, diese paar Tabellen sind halt jetzt leer. Da hatte ich nochmal Glück im Unglück, dass keine wichtigen Tabellen auf InnoDB gesetzt haben. Jetzt kann ich mir dann in Ruhe nochmal alle confs usw. anschauen, aber zumindest ist wieder alles erreichbar und der Server nicht mehr down weil kein mysql rennt. |
| | |
| | #4 (permalink) |
| Member of Honour ![]() | wenn du die Datei jetzt auf 'ner anderen Partition hast, kannst du ja auch mal nen Symlink nach /var/lib/mysql machen - dann hast du die Daten wieder und kannst schauen, wo der Übeltäter steckt. |
| | |
| | #5 (permalink) |
| Themenstarter | Danke nochmals ... habe ich dann sowieso gemacht und was die DB so zugemüllt hat war mir von Anfang an klar: indexed_search Extension von typo3. Die hat mehrere Tabellen die alle zwischen 5-10 GB groß sind und nachdem sich die ibdata1 von MyISAM automatisch aufbläht aber selbst bei regelmäßiger "Reinigung" der Datenbank nicht schrumpft kam es zu diesem Brocken von Datenbankdatei obwohl die Tabellen für sich eh "nur" ein paar GB haben. |
| | |
| | #6 (permalink) | |
| Moderator ![]() Registriert seit: 30.06.08 ![]() ![]() ![]() ![]() Likes: 227 | Zitat:
In den allermeisten Fällen ist InnoDB obsolet.
__________________ Wenn ein Gesetz nicht gerecht ist, dann geht die Gerechtigkeit vor dem Gesetz! Habo Blog - http://blog.hackerboard.de/ | |
| | |
| | #7 (permalink) |
| Moderator ![]() Registriert seit: 30.09.06 ![]() ![]() ![]() ![]() ![]() ![]() Likes: 442 | InnoDB bietet aber noch die bessere Performance als MyISAM, vor allem wenn man mit großen Indexes zu tun hat und nicht auf Volltext-Indexes angewiesen ist.
__________________ Mein Blog - Mein Job - Diaspora Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund. Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+ |
| | |
![]() |
| - Anzeige - | |
| |
| Themen-Optionen | |
| Ansicht | |
| |