[GELÖST] export von ca 70.000 büchern geht nicht -> Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE
Eingetragen von axid (4)am 25.06.2015 - 13:18 Uhr in
Hallo Leute,
ich bin leider ein wenig verzweifelt drum wende ich mich an die expterten unter euch.
kurze einleitung: mein onkel hat jemanden beauftragt eine bücherdatenbank mit kundenverwaltung zu erstellen, entwicklung in "Drupal 7.34"
hard facts:
-) derzeit ca70.000 bücher in db, ca 2.000 mit foto (nicht in DB sondern auf filesystem)
wollen in den nächsten jahren auf 200.000 bücher kommen
-) 8.000 kundendaten, leicht steigernd
aktuell haben sie ein massives performance problem (virtueller server liegt auf http://all-inkl.com/webhosting/premium/ -> Kunden je Server 50
jetzt zum problem:
beim export aller bücher in eine txt datei bekommen sie immer einen error:
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /www/htdocs/w011210d/domain.at/shop/antiquariat/includes/database/database.inc:2171 Stack trace: #0 /www/htdocs/w011210d/domain.at/shop/antiquariat/includes/database/database.inc(2171): PDOStatement->execute(Array) #1 /www/htdocs/w011210d/domain.at/shop/antiquariat/includes/database/database.inc(683): DatabaseStatementBase->execute(Array, Array) #2 /www/htdocs/w011210d/domain.at/shop/antiquariat/includes/database/database.inc(2350): DatabaseConnection->query('SELECT expire, ...', Array, Array) #3 /www/htdocs/w011210d/domain.at/shop/antiquariat/includes/lock.inc(167): db_query('SELECT expire, ...', Array) #4 /www/htdocs/w011210d/domain.at/shop/antiquariat/includes/lock.inc(146): lock_may_be_available('schema:runtime:...') #5 /www/htdocs/w011210d/domain.at/shop/antiquariat/includes/bootstrap.inc(433): lock_acquire('schema:runtime:...') #6 /www/htdocs/w011210d/domain.at/shop/antiquariat/inc in /www/htdocs/w011210d/domain.at/shop/antiquariat/includes/database/database.inc on line 2171
das problem ist, der programmierer meint sie brauchen mehr speicher aber bei (eh schon 1gb) bezweifel ich wieviel sinn es machen wird wenn man diesen jetzt auf 2gb oder 4gb hinaufschrauben wird.
ich weiss das es jetzt bisschen weit hergeholt ist euch zu fragen was man besser machen kann aber ich glaube die abarbeitung des exports kann man massiv optimieren... ändern auf multithreading oder ähnliches....
was ich so ärgerlich finde ist das der entwickler sich immer auf die hardware herausredet und ich nicht weiss ob das stimmt. letztes monat haben wir das Memory Limit auf 1GB per htaccess erhöht, heute solln wir es auf 2GB erhöhen...
das hat doch keinen sinn oder was haltet ihr davon?
anbei noch ein kurzes export.txt (so ist die struktur der bücher db)
url: http://antik.loecker.at/antiquariat/sites/default/files/export.txt
- Anmelden oder Registrieren um Kommentare zu schreiben
die Frage ist
am 25.06.2015 - 13:36 Uhr
warum wird der gesamte Bestand in eine txt-Datei exportiert?
Wenn dies eine Sicherungsstrategie ist, warum dann in einer web-Umgebung, und nicht als Shellprozess?
Bei dieser Größenordnung muss man auch mit anderen Strategien dran gehen.
Liegt die Datenbank auf der gleichen Maschine? Vermutlich ja.
Hier ist dann zu fragen, ob es nicht sinnvoll sein könnte, diese auf einen anderen Server auszulagern, und solche Sicherungsmechanismen auf dem DB-Server im Hintergrund laufen zu lassen.
hallo, danke für die rasche
am 25.06.2015 - 13:47 Uhr
hallo,
danke für die rasche antwort!
es ist keine sicherungsstrategie sondern wir wollen den datenbestand an andere drittanbieter weiterleten, darum txt.
web-umgebung, keine ahnung -> shell wäre nachträglich besser gewesen :-(
Bei dieser Größenordnung muss man auch mit anderen Strategien dran gehen. --> was meinst du bitte damit genau? :-)
Liegt die Datenbank auf der gleichen Maschine? --> ja!
letzte frage --> das ist keine sicherung, die mache ich mittels DB dump, wir brauchen halt ein export file :-)
wäre multithreading evtl besser oder ist ausschließlich ein batch job von vorteil?
lg
Für den exporrt in eine txt
am 25.06.2015 - 14:04 Uhr
Für den exporrt in eine txt Datei verwende am besten http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html
Das ganze über cli.
Was den Ressourcenerbrauch betrifft:
Das kann schon sein, wenn Ihr einen shop damit pflegt!
Das meinte ich
am 25.06.2015 - 14:13 Uhr
einen Exportprozess außerhalb Drupals, aufgerufen von der Shell aus.
Am besten getriggert von einem cron-job (außerhalb drupals).
Du musst natürlich wissen, was du brauchst, und ggf. etwas an dem Query feilen.
danke :)
am 25.06.2015 - 14:16 Uhr
danke :)
Mit diesem Modul
am 25.06.2015 - 17:54 Uhr
Mit diesem Modul https://www.drupal.org/project/views_data_export kannst du den export splitten lassen bzw. den Export in mehreren Schritten erledigen lassen, um genau dieses Problem zu umgehen.
danke!
am 29.06.2015 - 10:28 Uhr
danke!