MySQL-Backup: DB zu groß

[Bastian Kurz]

Hallo!

Ich versuche mit PHPMyAdmin ein Backup einer DB zu machen. Eine Tabelle ist aber recht groß und kann deswegen nicht gespeichert werden, ohne daß es zu einem Fehler kommt. Es sieht im ersten Augenblick immer so aus, als hätte es funktioniert, schaue ich aber in mein File, dann endet das auf:
<b>Fatal error</b>:  Allowed memory size of 16777216 bytes exhausted (tried to allocate 840 bytes) in <b>/home/httpd/vhosts/seite.de/httpdocs/csb/phpmyadmin/libraries/export/sql.php</b> on line <b>515</b>

Was mache ich jetzt? Ich hab mal davon gehört, es sollte Tools geben, die mir das in viele kleine Files splitten könnten. Aber ich finde da nur etwas, um Backups wieder einzuspielen und nicht zum speichern.

Wie geht man hier vor? Bitte um Hilfe. Danke.

Basti

[Matthias Jütte]

Hallo!

Kannst du den Server konfigurieren? Dann setze in der php.ini einfach die Speicherbegrenzung hoch. Hast du schon versucht die Daten komprimieren zu lassen (wobei ich nicht weiß, ob das Einfluß auf die Speichernutzung während der Verarbeitung hat - aber ausprobieren kann man ja mal).

Gruß

Matthias

[Bastian Kurz]

Kannst du den Server konfigurieren?

Nö. Ist nicht mein Server. Ist ein shared Server bei einem Provider.
Sonst wäre das ja kein Problem.
Und das mit dem Komprimieren habe ich auch bereits versucht und es funktioniert nicht.
Aber ich muß es doch irgendwie schaffen, meine Datenbank zu sichern.

[Matthias Jütte]

Hallo!
Sprichst du von deiner _Datenbank_ oder von einzelnen Tabellen? Sonst exportiere doch einfach jeweils in Blöcken von Tabellen. Die Größe einer jeden Tabelle kann man ja im phpMyAdmin sehen.

Gruß

Matthias

[fastix®]

Moin!

Ich kenne Dein Problem, hatte es auch.
http://www.fastix.de/dbbackup.zip
Sollte es tun. Downloaden, konfigurieren (ähnlich dem phpmyadmin), In geschützetes Verzeichnis laden. los gehts :)

Aber ohne jede Garantie!

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Andreas Korthaus]

Hi!

<b>Fatal error</b>:  Allowed memory size of 16777216 bytes exhausted (tried to allocate 840 bytes) in <b>/home/httpd/vhosts/seite.de/httpdocs/csb/phpmyadmin/libraries/export/sql.php</b> on line <b>515</b>

Also da würde ich als erstes mal den Provider fragen wie Du das anstellen sollst. Hast Du SSH-Zugriff, dann sollte es kein Problem sein, Stichwort "mysqldump".

Und sonst musst Du Dir ein eigenes Script schreiben, welches weniger Resourcen braucht als phpmyadmin, das macht man am besten indem man die Arbeit der DB überlässt, also durch Verwendung von Sachen wie "LOAD DATA INFILE" oder "BACKUP TABLE". Die Datentyp-Beschreibungen wirst Du ja über phpmyadmin bekommen.

Vielleicht hilft Dir einer der folgenden Links:

http://dev.mysql.com/doc/mysql/de/LOAD_DATA.html
http://dev.mysql.com/doc/mysql/de/BACKUP_TABLE.html
http://dev.mysql.com/doc/mysql/de/Backup.html

Das ist alles gar nicht so kompliziert. Und wie gesagt, im Zweifel einfach bei Deinem Provider nachfragen!

Grüße
Andreas

[Tom]

Hello,

Und sonst musst Du Dir ein eigenes Script schreiben, welches weniger Resourcen braucht als phpmyadmin, das macht man am besten indem man die Arbeit der DB überlässt, also durch Verwendung von Sachen wie "LOAD DATA INFILE" oder "BACKUP TABLE". Die Datentyp-Beschreibungen wirst Du ja über phpmyadmin bekommen.

Vielleicht hilft Dir einer der folgenden Links:

http://dev.mysql.com/doc/mysql/de/LOAD_DATA.html
http://dev.mysql.com/doc/mysql/de/BACKUP_TABLE.html
http://dev.mysql.com/doc/mysql/de/Backup.html

Der eingebaute Datenexport von MySQL geht bei den meisten Providern nicht, weil man nicht an das Outfile-Verzeichnis herankommt. Das ist in MySQL siw fest eingestellt und der shared user hat keinen Einfluss darauf.

Sollte es anders sein, würde ich mich über eine Rückmeldung auch freuen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Andreas Korthaus]

Hi!

http://dev.mysql.com/doc/mysql/de/LOAD_DATA.html
http://dev.mysql.com/doc/mysql/de/BACKUP_TABLE.html
http://dev.mysql.com/doc/mysql/de/Backup.html

Der eingebaute Datenexport von MySQL geht bei den meisten Providern nicht, weil man nicht an das Outfile-Verzeichnis herankommt. Das ist in MySQL siw fest eingestellt und der shared user hat keinen Einfluss darauf.

Das Verzeichnis bei LOAD DATA INFILE kann man doch angeben, und man kann auch bestimmen dass es auf dem Client-Host gespeichert wird. Es gibt viele Wege für eine Datensicherung. Der bequemste ist sicher über die shell.

Grüße
Andreas

[Tom]

Hello,

http://dev.mysql.com/doc/mysql/de/BACKUP_TABLE.html

Danke, der Tipp war für mich sehr gut. Funktioniert ja sogar.
Bei den shared users wird es wohl trotzdem nichts, weil der mysql-Deamon meistens keinen Schreibzugriff auf das Userverzeichnis hat.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[fastix®]

Moin!

Danke, der Tipp war für mich sehr gut. Funktioniert ja sogar.
Bei den shared users wird es wohl trotzdem nichts, weil der mysql-Deamon meistens keinen Schreibzugriff auf das Userverzeichnis hat.

Bei z.B. 1und1 kann das sogar nichts werden. Da hat der User nicht mal Zugriff auf den Datenbankserver, aber der client ist auf den Webservern vorhanden und kann innerhalb eines CGI-Skriptes oder PHP z.B. mit system() aufgerufen werden. Einen SSH- Zugang gibts bei den Massenpaketen nicht.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Tom]

Hello,

Danke, der Tipp war für mich sehr gut. Funktioniert ja sogar.
Bei den shared users wird es wohl trotzdem nichts, weil der mysql-Deamon meistens keinen Schreibzugriff auf das Userverzeichnis hat.

Bei z.B. 1und1 kann das sogar nichts werden. Da hat der User nicht mal Zugriff auf den Datenbankserver, aber der client ist auf den Webservern vorhanden und kann innerhalb eines CGI-Skriptes oder PHP z.B. mit system() aufgerufen werden. Einen SSH- Zugang gibts bei den Massenpaketen nicht.

Ich habe es eben das erste Mal selber benutzt. Wir haben die Tables bisher aus Zeitgründen immer mit copy gesichert. Also mysql kurzzeitig beendet, ganzes Datenbankverzeichnis kopieren, Mysql-Server wirder rauf. Dann hat man anschließend Zeit und Muße für Tar -czvf und den Download auf den Backupserver. Die Offtime ist dabei selbst bei den riesigsten Datenbanken (mehrere GByte) nur wenige Sekunden.

Diese Möglichkeit ist natürlich zu bevorzugen, da es nur eine "Write-Offtime" gibt und das Lesen immer möglich ist.

Es wäre nun denkbar, dass der Befehl über die normale SQL-Schnittstelle von PHP funktioniert und dann der wwwrun ("PHP-Deamon") der Eigentümer der Files wird. Dann kann man sie auch damit anschließend gleich zippen und zum download bereitstellen über HTTP.

Wie gesagt, ich habe es noch nicht durchgetestet mit PHP/MySQL.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[fastix®]

Moin!

Ich habe es eben das erste Mal selber benutzt. Wir haben die Tables bisher aus Zeitgründen immer mit copy gesichert. Also mysql kurzzeitig beendet, ganzes Datenbankverzeichnis kopieren, Mysql-Server wirder rauf. Dann hat man anschließend Zeit und Muße für Tar -czvf und den Download auf den Backupserver. Die Offtime ist dabei selbst bei den riesigsten Datenbanken (mehrere GByte) nur wenige Sekunden.

Upsalla!

Du weisst noch nicht, wie man mit MySQL einen Server auf ein Backupsystem repliziert? Das geht nämlich seit einiger Zeit und Du hast immer ein aktuelles Backup. Daneben kannst Du in hochbelasteten Systemen sogar mehrere Backup- Server verwenden, z.B. um mit "nur" Abfragen einen extra- Server zu beschäftigen. "lastverteilung by aufgabe". Ich glaube, das geht schon seit 3.32.x oder so.

Wenn Du ein Backup auf Band brauchst kannst Du ja einen der replizierten Server vom Netz nehmen. Der holt sich dann beim Hochfahren schon wieder die inzwischen geänderten Daten.

MySQL kann also auch ein gutes Stück Hochverfügbarkeit...

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Tom]

Hello,

Du weisst noch nicht, wie man mit MySQL einen Server auf ein Backupsystem repliziert? Das geht nämlich seit einiger Zeit und Du hast immer ein aktuelles Backup. Daneben kannst Du in hochbelasteten Systemen sogar mehrere Backup- Server verwenden, z.B. um mit "nur" Abfragen einen extra- Server zu beschäftigen. "lastverteilung by aufgabe". Ich glaube, das geht schon seit 3.32.x oder so.

Doch, das haben wir ausprobiert. Das sorgt aber wegen der geforderten Konsistenz (Datenschnitt) für eine zu lange Offtime. Außerdem ist der Backup-Server nicht immer am Netz. Wir (bzw. mein Kollege, der auch Thomas heißt) hat da ca. vier Wochen Experimente und Dokumantationen angelegt für uns und einige Kunden.

Die Brutalmethode, über Cron x-mal am Tag die DB einfach kurz runterzufahren, komplett zu kopieren und wieder hochzufahren, ist die schnellste. Außerdem hat man dann die erforderliche Zeit, die Daten zu ballen und zu zippen. Der Backup-Server meldet sich dann über ssh ein paar Minuten später an und holt sich das Backup ab. Dafür hat er eine halbe Stunde Zeit.

Es handelt sich also immer um eine Vollsicherung, die sofort einsatzfähig ist. Da MySQL keine Tranaktionslogs erzeugen kann, geht der Incrementalanteil seit der letzten Sicherung dann ggf. leider verloren.

Aber das lösen wir auch noch. Es gibt ja eine eingebaute Möglichkeit der Änderungshistorie, aber die hat (noch) nicht zu unserer Zufriedenheit funktioniert.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[fastix®]

Moin!

Les mal hier:
http://dev.mysql.com/doc/mysql/de/Replication.html

Besonders aber:
http://dev.mysql.com/doc/mysql/de/Replication_Intro.html

Replikation _ist_ _die_ Lösung für euer Offtime- Problem.

Du replizierts die Server und hast dadurch schon mal ständig ein Backup. Allerdings muss der zweite Rechner dann immer am Netz beleiben. (Am besten sogar an einem extra- Netz nur für den internen Datenaustausch der Server)

Um jetzt ein echtes Backup zu fahren stopst Du den zweiten Server (Slave), machst das Backup wie gehabt und startest danach den Slave-Server neu. Der holt sich fix die geänderten Daten vom Master (genauer: Das binäre Log in welchem eigentlich nichts anderes als eine Art Dump steht) führt das aus und ist Sekunden später auf dem selben Stand wie der originäre Server. Du hast also keine Offtime für die Datensicherung, immer einen aktuellen Server und, falls mal alles bricht: noch immer das Backup.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Tom]

Hello,

http://dev.mysql.com/doc/mysql/de/Replication.html

Besonders aber:
http://dev.mysql.com/doc/mysql/de/Replication_Intro.html

Danke für die Links.
Ich hatte eben kurz die Orientierung verloren, warum es bei und doch nicht so praktisch war.
Ich denke, das lag daran, dass wir noch eine Menge externer Daten halten, die aber in die MySQL-Tabellen related sind.

Wir müssen die alle in einem Stand sichern. Während der Replikation laufen die DB und PHP ja weiter. Ich weiß es nicht mehr auswendig, aber da gab es ein Integritätsproblem, dass wir nicht lösen konnten.

Ich packe mir die Tips aber auf jeden Fall mit zu den Unterlagen des Projektes. Wenn wir das nächste Mal rangehen, werden wir das nochmal ergründen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[fastix®]

Moin!

Übrigens: Bitworks.com steht offensichtlich zum Verkauf.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[fastix®]

Moin!

Übrigens: Bitworks.com steht offensichtlich zum Verkauf.

Ich mal wieder... es ist bitwork.com

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Tom]

Hello,

Übrigens: Bitworks.com steht offensichtlich zum Verkauf.
Ich mal wieder... es ist bitwork.com

Danke. Das ist jetzt schon einge Jahre lang Sache meiner Partner. Aber die sind leider recht langsam (!?). Ich hatte da mal ein paar blöde Verletzugnen unserer Gemeinschaftsmarken angemämgelt und versucht, die Verletzer zu bremsen. Aber meine Partner haben _mich_ dann gebremst und gemeint, sie müssten noch recherchiern und meine erste Abmahnung hätte doch wohl gereicht. Außerdem wüssten die Verletzer ja nun nachweislich Bescheid und müssten sich daher demnächst mit Strafanzeigen wegen fortgesetzten Betruges auseinanderstzen. Ich solle man hübsch weiter meine Hotelsoftware schreiben und vermarkten usw ... Ich denke, die Mädels und Jungs sind da einfach härter drauf als ich. Die ziehen das durch und wenn dabei noch ein bitwork.com abfällt oder ein bitwerk.de sich blöd umgucken wird, dann nehmen die das auch noch mit. Ich habe derzeit leider nur noch "privaten Nießbrauch" oder wie das heißt. Meine Krankheit hat halt viel Geld gekostet und trotz über 120.000 an Beiträgen ohne Gegenleistung sagt die damalige Krankasse "denkste"...

Warum soll ich mich noch aufregen?

Wenn ich dann bei ISS versuche, alte Kontakte nochmals wiederzubeleben und nach fundierter Planung frage, dann werde ich (zusmmen mit einigen anderen Profis) nur dumm angemacht. Also wozu noch aufregen? Die zwei bis drei Jahre bekomme ich auch noch rum :-(

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Andreas Korthaus]

Hi!

Bei z.B. 1und1 kann das sogar nichts werden. Da hat der User nicht mal Zugriff auf den Datenbankserver,

der ist ja AFAIK auch zentral gehostet.

aber der client ist auf den Webservern vorhanden und kann innerhalb eines CGI-Skriptes oder PHP z.B. mit system() aufgerufen werden. Einen SSH- Zugang gibts bei den Massenpaketen nicht.

Ich persönlich ziehe die Kommandozeilen-Tools vor, selbst wenn ich sie aus PHP heraus aufrufen muss. Und wenn es selbst die nicht gibt, LOAD DATA LOCAL INFILE sollte auch dann noch funktionieren, und auch keine Rechteprobleme bereiten.

Grüße
Andreas

[fastix®]

Moin!

Ich persönlich ziehe die Kommandozeilen-Tools vor, selbst wenn ich sie aus PHP heraus aufrufen muss. Und wenn es selbst die nicht gibt, LOAD DATA LOCAL INFILE sollte auch dann noch funktionieren, und auch keine Rechteprobleme bereiten.

Das nicht. Aber die Arbeit mit (komprimierten) Dumps hat auch Vorteile :)
Vielleicht sollte ich das oben verlinkte Skriptchen mal zur Diskussion stellen (insbesondere, weil es unter Windows noch nicht getestet ist) und dann mit einer Reihe von Mitautoren als Feature-Artikel vorschlagen. Ich denke die Situation bei 1und1 ist kein Einzelfall, es gibt viele Hoster mit PHP, MySQL, CGI, aber ohne SSH- Zugang. (Warum eigentlich... system(), exec()...können  doch denselben Schaden anrichten)

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Andreas Korthaus]

Hi fastix!

Vielleicht sollte ich das oben verlinkte Skriptchen mal zur Diskussion stellen (insbesondere, weil es unter Windows noch nicht getestet ist) und dann mit einer Reihe von Mitautoren als Feature-Artikel vorschlagen.

Ja, das ist eine sehr gute Idee! Oder auch erstmal nur einen kleinen Beitrag für Tipps&Tricks, zu große Projekte haben die Tendenz nie fertig zu werden ;-)
Aber mal prinzipiell zu beschreiben wie man ein MySQL-Backup ohne phpmyadmin macht, das wäre doch sicher einen Tipp wert: http://aktuell.de.selfhtml.org/tippstricks/beitrag.htm

Später kann man gerne auch einen großen Feature Artikel schreiben, bei dem man die verschiedenen Problematiken genauer beleuchtet, und alternative Lösungswege aufzeigt.

Wenn Du Lust hast was zu schreiben, kannst Du mich auch gerne per mail kontaktieren, oder hier im Forum.

Viele Grüße
Andreas

[fastix®]

Moin!

Aber mal prinzipiell zu beschreiben wie man ein MySQL-Backup ohne phpmyadmin macht, das wäre doch sicher einen Tipp wert: http://aktuell.de.selfhtml.org/tippstricks/beitrag.htm

Die Idee halte ich für eine gute. Ich brauche ja nur die existierenden Skripte abspecken und ein paar Erläuterungen schreiben.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Andreas Korthaus]

Hi!

Aber mal prinzipiell zu beschreiben wie man ein MySQL-Backup ohne phpmyadmin macht, das wäre doch sicher einen Tipp wert: http://aktuell.de.selfhtml.org/tippstricks/beitrag.htm

Die Idee halte ich für eine gute. Ich brauche ja nur die existierenden Skripte abspecken und ein paar Erläuterungen schreiben.

Ja, genau das. Ich würde das ganze schön auf das Kernproblem reduzieren, und nicht viel drumherum. Braucht nicht endlos lang werden, nur so dass jemand der nicht selber drauf kommen würde es gut versteht und danach evtl. sowas bei seinem Provider anwenden kann. Genau dafür ist die Rubrik "Tipps & Tricks" gedacht!

Ich freue mich schon auf Deinen Beitrag ;-)

Grüße
Andreas