Nachträgliches Einrichten eines "1&1 Cloud Servers"

prinzipiell musst Du sie auf der einen Seite exportieren (mit „mysqldump“ oder wenn installiert mit „drush sql-dump“) und auf der anderen Seite muss du sie importieren (mit „mysql“ bzw. „drush sqlc“). In der Praxis wirst Du bei einer Datenbank dieser Größe aber timer Probleme bzw. Buffer-Overflow (whatever) Fehlermeldungen bekommen, wenn Du die Dantenbank in einem Stück importieren willst.

Um das Problem zu lösen müsstest Du den Server verdrehen oder (einfacher) die Tabellen einzeln exportieren und importieren.
Möglicherweise stellt auch „drush sql-sync“ einen Lösungsansatz dar. Allerdings weiß ich, das 1&1 die Vertragsübergreifende Kommunikation meist via Firewall blockt.

Ergo, … :

• alte Datenbank in kleinen Häpchen exportieren
• kopieren der Export-Dateien (sind Textdateien) auf den neuen Server
• importieren in die neue Datenbank

Übrigens lösen auch die diversen automatisierten Tools das Problem mit der Größe meist nicht. Wie gesagt, wenn Du eine so große DB exportierst erhältst Du eine so große Textdatei, dass der Server auf der Importseite irgendwann die Grätsche macht und mit einer Fehlermeldung abbricht.

Komplette Lösungsanweiung kann ich dir nicht bieten, aber vieleicht hilft dir das erst mal weiter.
Ansonsten mal den Support bei 1&1 löchern od die diese DB nicht umziehen können.

Grüße
Peter

Klar ist ein SQL-Dump eine riesige Text-Datei, die sich aber auch prima komprimieren lässt.
Schnell geht es mit GZip. Am kleinsten wird die Datei mit BZip.
Dann rüber auf den neuen Server mit Rsync und entpacken.
Danach importieren mit dem "MySQL"-Befehl und gut.
Entweder diese Werkzeuge selbst aneignen oder Dienstleister engagieren.

Ps.: Drush arbeitet auch nur mit Standard-Commandline Tools wie MySQLdump und Rsync, wenn man ein SQL-Sync macht.

Meine Ausführungen bezogen sich (vorgreifend) auf ein Problem, dass sich speziell beim Import grosser Dumps stellen kann.

Details dazu finde man z.B. hier:
http://stackoverflow.com/questions/12425287/mysql-server-has-gone-away-w...

Dem Transfer der (großen) Textdatei - ob nun als Zip oder wie auch immer - habe ich gar keine weitere Beachtung geschenkt. (:-

Moin,

soweit erst mal vielen Dank. Die neue DB konnte geladen werden. Was seltsam war: PHPAdmin hat 1,6 GB nach Optimierung (modul optimizedb) angezeigt. Der Export als ZIP waren aber dann dennoch nur 13MB und der Import in die neue DB ergaben 0,8GB. Seltsame Größenverhältnisse ..

Ja, der DB-Server sollte nach Möglichkeit natürlich genügend Kapazitäten haben. Ansonsten muss man halt tricksen, da hast Du Recht. Aber bei den Tricks würde ich trotzdem auf PHP-Helfer verzichten, und statt dessen andere Strategien versuchen wie z.B. die Datenbank in Tabellen-Gruppen zu transferieren.
Gerade bei Drupal kann man bei dem Export eine DB oft auch auf den Inhalt diverser Tabellen verzichten wie z.B. diverse Caching und Log-Tabellen. Dabei sollte man dann darauf achten, daß man die Tabellen-Struktur aber wenigstens mitnimmt. Auch in Backups kann man darauf auch oft gut verzichten.
Das lässt sich dann prima in Drush voreinstellen auch in den Sitealias-Settings.

PHPmyadmin betrachte ich übrigens als unnötige weitere, angreifbare Webanwendung, die ich in der Regel gar nicht erst installiere und statt dessen bei Bedarf per SSH-Tunnel auf die Datenbanken zugreife. Programme dieser Art haben dann nicht nur mit den Limitierungen der Datenbank selbst zu kämpfen sondern auch noch zusätzlich mit den Grenzen von Webserver und PHP-Prozessen. Da klappt dann oft noch der Export größerer Datenbanken, aber beim Import gibt es dann teilweise Probleme, die teilweise nicht sofort erkennbar sind (verlorene Datensätze). Und wenn man dann dringend ein Backup wieder einspielen muss, hat man den Datensalat.

ich habe schon einige große datenbanken mit mysqldumper umgezogen. Das tool ist schnell installiert und arbeitet zuverlässig. nach db-umzug entferne ich es gleich wieder.