[gelöst] Datenbank hat 101 MB

und vielen Beiträgen, ist 100 MB nicht viel.
Da in Drupal fast alles in der Datenbank landet, ist wohl auch das Meiste unverzichtbar.

Natürlich ist dies ein Brocken, wenn es um einen Umzug geht.

Beim neuen Provider solltest du gleich darauf achten, dass eine wachsende Datenbank mit 100+ MB kein Problem darstellt.
Zumindest während des Umzuges solltest du in der Lage sein, die Prozesstimeouts zu erhöhen, und du solltest beim zukünftgien Provider mindestens 128 MB Speicherzuweisung bekommen.

Du könntest natürlich mit Backup&Migrate die Datenbank auch in Teilen transferieren, also den content von der config trennen.

Das ganze sollte nicht im Hau-Ruckverfahren, sondern gut geplant ablaufen, dass du keine Datenverluste erleiden musst.

Die Search-Tabellen kannst du - bedenkenlos - leeren. Bei Bedarf erstellt Drupal den Search-Index mit jedem Cron-Lauf neu.

Mein Tipp an dich zur Datenbank-Optimierung, sofern dir nicht eh schon bekannt: DB Maintenance https://drupal.org/project/db_maintenance

Mit diesem Modul kannst du die DB-Tabellen optimieren, das heißt in einem Rutsch den "Überhang" der Tabellen leeren, also das, was die MySQL-Funktion "OPTIMIZE TABLE" tut.

Nach vielen Jahren kann der besagte Überhang (insbesondere in MyISAM-Tabellen) im gesamten viele, viele MBs einnehmen. Von allein löscht MySQL diese Daten nicht. Sie werden dennoch nicht weiter benötigt und können daher bedenkenlos gelöscht werden.

Zu deiner 3. Frage: Du kannst mit dem von dir genannten Dumper-Script viele handlich kleine Pakete deines DB-Dumps erstellen. Der Dumper schreibt diese Pakete insoweit kompatibel, dass du sie auch mit jedem anderen konventionellen Tool in jede MySQL-Datenbank einspielen kannst.

Viel Erfolg
Anoa

... Den MySQL-Dumper kannst du auch so einstellen, dass er vor dem Dump das tut, was ich oben als "OPTIMIZE TABLE" bezeichnet habe. Dann benötigst du das Module DB Maintenance nicht.

Vielen Dank für die Antworten.

@roland: Der Tipp mit der DB-Größe für die Hostersuche ist notiert - vielen Dank!

So dachte ich mir das - vielen Dank für die Bestätigung. Das gibt mir auf jeden Fall ein gutes Gefühl :-)

Die Tabellen sind alle optimiert - leider! Das hatte ich ganz konservativ über PHPMyAdmin gemacht. Hier ist also kein Optimierungspotenzial mehr. Trotzdem vielen Dank für den Tipp!

Danke, der Tipp ist gut. Das Problem ist, dass ich einzelne Tabellen habe, die schon einen Umfang im zweistelligen MB-Bereich haben. So ist die größte Tabelle, die search_index mit 26.1 MB. Die kann ich ja leeren. Jedoch hat z.B.

• node_revisions 10.3 MB
• accesslog 8.8 MB

Womit wir dann die Problemkinder auch komplett identifiziert hätten. Alle anderen Tabellen haben unter 2 MB. Das ist jedoch in der Masse auch noch mal sehr viel. Ich weiß halt nicht, ob ich diese Tabellen auch einfach mal leeren kann. Jedoch bleiben dann immer noch gut 12 MB Datenbankgröße übrig.

Mit dem MySQLDumper kann ich ja den kompletten Dump per FTP in das Verzeichnis MySQLDumper-Verzeichnis /work/backup übertragen und von dort dann die Datei nochmal einspielen. Doch bei Strato funktioniert der MySQLDumper irgendwie nicht. Deshalb suche ich nach anderen Wegen, die DB zu übertragen.

Entschuldige bitte aber welchen Sinn hat das was du da gerade machst?

Ne Datenbank mit 100 MB ist pillepalle ... 1 GB sind "nett" aber selbst die wären nicht tragisch ...

Wenn Dein Hoster damit Problem hat, solltest du dir nen anderen Hoster suchen aber nicht die Zeit mit Sinnlosigkeit verbraten ....

Du sitzt da jetzt stundelang herum und grübelst über Quark nach .... man könnte das damit vergleichen, dass du gerade neben dem Auto sitzt und dir Gedanken darüber machst warum der Reifen aus Gummi ist - anstatt einzusteigen und loszufahren.

... deine Anmerkung. Doch gestatte mir den Einwand "Hast Du auch wirklich gelesen, worum es geht". Es geht mir nicht primär um die DB-Größe, sondern um das Handling für den Upgrade. Da muss ich die DB mit umziehen. Eine DB von 101 MB umzuziehen, wenn ich nur eine max. Dateigröße von 2 MB für den Upload zur Verfügung habe, ist für mich kein Pille-Palle sondern ein ernsthaftes Problem.

Ich glaube, damit ist die Sinnhaftigkeit meines Tuns klarer. Ich habe anderes zu tun, als einfach nur mal theoretisch etwas zu planen. Sollte ich mich da in meinem Anfangspost nicht klar ausgedrückt haben, dann entschuldige bitte. Doch ich war der Meinung, dass jemand, der sich auch nur für 3 Pfennig Gedanken macht, was ich da tue, auch erkennt, wo das Problem liegt. Sorry, wenn ich das falsch eingeschätzt habe.

Dann ändere die Einstellung für die Uploadgröße über eine eigene php.ini (wenn dein Hoster das zulässt) ansonsten suche dir, wie schonmal gesagt, nen neuen Hoster.

Wenn du 5 Jahre Content angelegt hast, wirst du die Datenbank nicht auf 2 MB runterbekommen - egal was du versuchst - außer du löscht den Content und fängst bei null an.

Oder du nimmst Migrate und migrierst damit den Content .... dann musst du nicht mit MySQLDumper (o.ä.) arbeiten.

das Uploadvolumen zu erhöhen.

Sprich mit deinem zukünftigen Provider über dieses Problem.

Es muss doch möglich sein, den gesamten Inhalt von 100+ MB per FTP bereitstellen zu können.

Diese 2 MB beziehen sich doch nur auf einen HTTP-Upload.

Liegt der Dump auf dem Server, ist auch der Import erheblich einfacher.

Eine andere Lösung könnte eine Direktverbindung zwischen den Servern sein, was natürlich noch mehr guten Willen beider Provider erfordert.

Wenn die Datenbank von außen ansprechbar ist, könnte man den Dump auch auf dem Zielsystem ausführen.

Ansätze gibt es reichlich.

Du hast alleine 12 MB Textcontent.

Natürlich lässt sich auch ein Dump in mehrere Teile zerlegen.

Das ist aber verdammt viel Arbeit. Ein gewisses Restrisiko auf Datenverlust bleibt dann weiter bestehen.

Falls Du damit nicht weiter kommst, hier ist ein guter Artikel, der Dir auch sagt, welche Tabellendaten beim Backup nicht unbedingt benötigt werden: http://adellefrank.com/blog/drupal-database-tables-files-backup-migrate

Zunächst nochmal vielen Dank für eure Antworten und die guten Infos!!!!

Ich habe mich jetzt mal den Link von @tobi-berlin angeschaut und dort auch die Tabellen studiert. Ich riskiere es jetzt einfach mal mit dem Modul Backup + Migrate Das Modul bietet ein eigenes Verzeichnis, das über FTP erreichbar ist. Da habe ich dann mal schon die 2 MB für den Upload über den Browser sicher ausgehebelt. Weiterhin kann ich einzelne Tabellen über das Modul sichern und aufspielen, so dass ich den Core und einzelne Module nacheinander aufspielen könnte. Das ist zwar immer noch etwas umständlich und wenn es mir die Installation lahmlegt, dann kann ich auch Backup + Migrate in die Tonne treten, aber über eine lokale Kopie sollte das auch zum Laufen gebracht werden können.

Gruß 2be

Aber Backup and Migrate funktioniert - soweit ich weiß - auch nur bis 2GB große Datenbanken... oder ist das auch wieder eine Einstellung beim Server?

Das hängt an der Upload File Size (upload_max_filesize) in der php.ini auf dem Server.

Beste Grüße
Werner

So sieht es aus. 2 MiB waren glaube ich bei einem frischen PHP der Standardwert. Web (HTTP) sowie FTP sind schon mal zwei verschiedene Paar Schuhe, wenn es jemand wissen möchte ;-)