Datenbank zerstört? (Error 2006, 1118) Seite nicht mehr erreichbar
Eingetragen von zwerg (736)am 22.06.2017 - 08:46 Uhr in
Hallo,
auf einer Drupalseite habe ich seit heute folgenden "Begrüßungstext":
Additional uncaught exception thrown while handling exception.
Original
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT nid, cid, last_comment_timestamp, last_comment_name, last_comment_uid, comment_count FROM {node_comment_statistics} WHERE nid IN (:comments_enabled_0); Array ( [:comments_enabled_0] => 4 ) in comment_node_load() (line 1282 of /var/www/vhosts/hostingserver/pfad/zu/drupal/modules/comment/comment.module).
Additional
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'; Array ( [:language] => de [:source] => A field which is not visible to the user, but is recorded with the submission. [:context] => ) in locale() (line 720 of /var/www/vhosts/hostingserver/pfad/zu/drupal/modules/locale/locale.module).
Uncaught exception thrown in shutdown function.
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: DELETE FROM {semaphore} WHERE (value = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 1810628128594b734a239d44.27319589 ) in lock_release_all() (line 269 of /var/www/vhosts/hostingserver/pfad/zu/drupal/includes/lock.inc).
Uncaught exception thrown in session handler.
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ); Array ( [:db_condition_placeholder_0] => rPLleco-PwZT8R0PfQg004gFmNADQJpyQBxGqawxGCo [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 209 of /var/www/vhosts/hostingserver/pfad/zu/drupal/includes/session.inc).
Um ein bisschen zu probieren, wollte ich die Datenbank mit Prefix kopieren. Das erzeugte folgenden Fehler:
#1118 - The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size. Increase the redo log size using innodb_log_file_size.
Hat jemand einen Rat? Die Seite kann weder inhaltlich bearbeitet, noch betrachtet werden. Es handelt sich um eine Seite mit 36000 Fotos in gut 700 Beiträgen.
Vielen Dank vorab für eure Hilfe!
- Anmelden oder Registrieren um Kommentare zu schreiben
Hi,ist wohl ne recht grosse
am 22.06.2017 - 09:24 Uhr
Hi,
ist wohl ne recht grosse DB.
Mach was da steht:
#1118 - The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size. Increase the redo log size using innodb_log_file_size.
Ich übersetz das mal:
Die Grösse eines BLOB/Text Feldes das in nur EINER transaction gespeichert werden soll ist gösser als 10% der "wiederherstellen" Log Datei.
Also, entwerder das Innodb Log File vergrössern, oder das logging/wiederherstellen ganz abschalten.
MfG
Robert
Kannst du mir als
am 22.06.2017 - 09:15 Uhr
Kannst du mir als SQL-Fremdling bitte noch sagen, wie ich das lösen kann= Deaktivierung des Loggings in Drupal?
Hi, ich weiss ja nicht ob Du
am 22.06.2017 - 09:21 Uhr
Hi,
ich weiss ja nicht ob Du Zugriff auf den MySQL Server hast,
ansonsten musst Du Deinen Provider fragen.
Das ist in den Einstellungen des MYSQL Servers festgellegt.
Deine Datenbank wird durch eine InnoDB Engine betrieben.
In diesen Einstellungen kannst Du das ändern.
https://dev.mysql.com/doc/refman/5.6/en/optimizing-innodb-diskio.html
Robert
Der gleiche Fehlerzwerg
am 22.06.2017 - 09:29 Uhr
Der gleiche Fehler
:
#1118 - The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size. Increase the redo log size using innodb_log_file_size.
kommt übrigens beim Import der Tabellen in einer neuen DB:
INSERT INTO `biel_field_data_body` (`entity_type`, `bundle`, `deleted`, `entity_id`, `revision_id`, `language`, `delta`, `body_value`, `body_summary`, `body_format`) VALUES('node', 'zeitzeuge', 0, 469, 469, 'und', 0, '<p>Bieler Brunnen Nr. 80: Stadtpark-Planschbecken mit Skulptur "Consulation"</p><p>Haltestelle / Arrêt / Bus stop: Schleusenweg / Chemin des Ecluses, Nr. 2, 7</p><p>Trinkbar / potable / drinkable: Ja, oui, yes - Sprudelt seit / jaillit depuis / bubbled since: KA</p><p>Wasserversorgung / Prélèvement d’eau / water supply: Energie Service Biel (B60)</p><p>Brunnen-Geschichte: Im Becken befindet sich die Skulptur "Consulation" (1954) von André Ramseyer. Sie stand ursprünglich beim Zentralplatz. Die Öffnungszeiten des Parks sind während der Sommerzeit von 07.00 - 22.00 Uhr und in der Winterzeit von 07.00 - 20.00 Uhr.</p><p><img alt="" src="data:image/gif;base64,R0lGODlhkAEsAecAABEUDxkcJBgmFBsmKyMcEyAeIyopGDAwKxwsRRs9YjI4Rys8Yh5BDB5BNjRQETVLKztmEz1jJR[...]
Allerdings weiß ich nicht, was ich mit der Info anfangen soll...
Hast Du in my.ini oder
am 22.06.2017 - 09:28 Uhr
Hast Du in my.ini oder my.cnf
innodb_log_file_size
(oben in der Fehlermeldung steht dieser Parameter ist kleiner als 10% der Daten, die Du einfügen möchtest)
den Wert erhöht und den MySQL Server neu gestartet?
Was steht denn dort für ein Wert?
Leider nein, vermutlich kann
am 22.06.2017 - 09:32 Uhr
Leider nein, vermutlich kann ich in meinem Webhosting-Tarif nicht darauf zugreifen.
Wenn es drupalseitig keine Einstellfrage ist, werde ich wohl den Support kontaktieren.
Danke für eure Tipps, mal sehen wir es weitergeht...
Fehler 2006
am 22.06.2017 - 09:54 Uhr
Ist damit auch der Fehler ausgelöst worden?:
Additional uncaught exception thrown while handling exception.
Original
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT nid, cid, last_comment_timestamp, last_comment_name, last_comment_uid, comment_count FROM {node_comment_statistics} WHERE nid IN (:comments_enabled_0, :comments_enabled_1, :comments_enabled_2, :comments_enabled_3, :comments_enabled_4, :comments_enabled_5, :comments_enabled_6, :comments_enabled_7, :comments_enabled_8, :comments_enabled_9, :comments_enabled_10, :comments_enabled_11, :comments_enabled_12, :comments_enabled_13, :comments_enabled_14, :comments_enabled_15, :comments_enabled_16, :comments_enabled_17, :comments_enabled_18, :comments_enabled_19, :comments_enabled_20, :comments_enabled_21, :comments_enabled_22, :comments_enabled_23, :comments_enabled_24, :comments_enabled_25, :comments_enabled_26, :comments_enabled_27, :comments_enabled_28, :comments_enabled_29, :comments_enabled_30, :comments_enabled_31, :comments_enabled_32, :comments_enabled_33, :comments_enabled_34, :comments_enabled_35, :comments_enabled_36, :comments_enabled_37, :comments_enabled_38, :comments_enabled_39, :comments_enabled_40, :comments_enabled_41, :comments_enabled_42, :comments_enabled_43, :comments_enabled_44, :comments_enabled_45, :comments_enabled_46, :comments_enabled_47, :comments_enabled_48, :comments_enabled_49); Array ( [:comments_enabled_0] => 4 [:comments_enabled_1] => 53 [:comments_enabled_2] => 94 [:comments_enabled_3] => 137 [:comments_enabled_4] => 157 [:comments_enabled_5] => 209 [:comments_enabled_6] => 227 [:comments_enabled_7] => 277 [:comments_enabled_8] => 279 [:comments_enabled_9] => 297 [:comments_enabled_10] => 344 [:comments_enabled_11] => 348 [:comments_enabled_12] => 360 [:comments_enabled_13] => 670 [:comments_enabled_14] => 672 [:comments_enabled_15] => 675 [:comments_enabled_16] => 676 [:comments_enabled_17] => 677 [:comments_enabled_18] => 678 [:comments_enabled_19] => 679 [:comments_enabled_20] => 680 [:comments_enabled_21] => 681 [:comments_enabled_22] => 682 [:comments_enabled_23] => 684 [:comments_enabled_24] => 685 [:comments_enabled_25] => 686 [:comments_enabled_26] => 687 [:comments_enabled_27] => 688 [:comments_enabled_28] => 689 [:comments_enabled_29] => 698 [:comments_enabled_30] => 699 [:comments_enabled_31] => 700 [:comments_enabled_32] => 704 [:comments_enabled_33] => 705 [:comments_enabled_34] => 706 [:comments_enabled_35] => 707 [:comments_enabled_36] => 710 [:comments_enabled_37] => 711 [:comments_enabled_38] => 712 [:comments_enabled_39] => 713 [:comments_enabled_40] => 714 [:comments_enabled_41] => 715 [:comments_enabled_42] => 717 [:comments_enabled_43] => 720 [:comments_enabled_44] => 721 [:comments_enabled_45] => 722 [:comments_enabled_46] => 723 [:comments_enabled_47] => 724 [:comments_enabled_48] => 725 [:comments_enabled_49] => 726 ) in comment_node_load() (line 1282 of /.../comment.module).
Additional
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'; Array ( [:language] => de [:source] => A field which is not visible to the user, but is recorded with the submission. [:context] => ) in locale() (line 720 of /.../locale/locale.module).
Uncaught exception thrown in session handler.
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ); Array ( [:db_condition_placeholder_0] => rPLleco-PwZT8R0PfQg004gFmNADQJpyQBxGqawxGCo [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 209 of /.../includes/session.inc).
Weiterer Tipp: Wenn Du per
am 22.06.2017 - 09:39 Uhr
Weiterer Tipp:
Wenn Du per phpmyadmin die Datenbank Engine von InnoDB auf MyISAM umstellen kannst,
bin ich mir fast sicher dass der Import funktionieren würde.
MyISAM benötigt VIEL weniger Ressourcen als InnoDB.
Viel Glück
Bei 2006 hat sich der MySQL
am 22.06.2017 - 10:14 Uhr
Nein, bei einem 2006 hat sich der MySQL Server schon verabschiedet,
der Fehler muss also vorher passiert sein! ;-)
2006 MySQL server has gone away
Die Antwort vom Hoster ist,
am 22.06.2017 - 12:45 Uhr
Die Antwort vom Hoster ist, dass die Server ordnungsgemäß laufen und diese Einstellungen nicht im Webhosting vorgenommen werden können.
Klingt fast so, als ob ich vom Webhosting auf Servermiete upgraden muss?
Hoster wechseln der Dich
am 22.06.2017 - 13:20 Uhr
Hoster wechseln der Dich diese Einstellungen machen lässt
oder mach es lokal über einen AMP Stack(Apache,MySQL,PHP) wie LAMP,MAMP oder WAMP.
Hyp1 schrieb Hoster wechseln
am 22.06.2017 - 19:53 Uhr
Hoster wechseln der Dich diese Einstellungen machen lässt
oder mach es lokal über einen AMP Stack(Apache,MySQL,PHP) wie LAMP,MAMP oder WAMP.
Ist es möglich, das lokal zu machen und die Datenbank dann wieder hochladen? Im Netz finde ich nix dazu, habe von MySQL keinen blassen Schimmer...
Grundsätzlich
am 22.06.2017 - 21:44 Uhr
Grundsätzlich Ja.
Entschuldige die lange Antwort ;-)
MfG
Robert
mysql server has gone away
am 23.06.2017 - 08:08 Uhr
Die Meldung "mysql server has gone away" ist generell ein Indiz dafür, dass die internen Buffer der Datenbank zu klein dimensioniert sind. Dies tritt typischer Weise in Zusammenhang mit sehr großen Dumps oder übergroßen Blog-Inhalten auf. In Deinem Fall dürfte es konkret darann liegen, dass Du Bilder als Binärdaten in den Blobs ablegst (ablegen lässt). Das ist natürlich speziell in Zusammenhang mit einer Comunity-Seite tötlich - bzw. nur eine Frage der Zeit bis es knallt.
Lösen kannst Du das Problem mMn. nur indem Du die Dabenbank auf CLI-Ebene exportierts ("mysqldump ... > lala.sql" bzw. "drush sql-dump > lala.sql" ), anschließend den Dump in eine (lokale) für die entsprechend Dimension konigurierte Datenbank importierts und dort die entsprechenden Zeilen killst. Alternativ auch mit einem entsprechenden Texteditor - der allerrding entsprechend große Daten bearbeiten können muss - was selten ist. (Ansonsten direkt auf der SQL-Console versuchen die entsprechenden Zeilen zu löschen.)
Das alles ist aber sehr schwierig ohne genaue Kentniss über den Aufbau der Drupal-Datenbank.
Zumal Du aufgrund der beschriebenen Problematik ohne Sicherung arbeiten musst (Du kannst die Datenbank zwar sichern, kannst Sie aber aufgrund des beschriebenen Problems nicht ohne weiteres zurückholen).
---
Aber .. soweit ich das sehe hängt das Problem noch in der letzten aktiven Session - das sind rein temporäre Daten.
Also:
1. SQL-Console aufrufen
2. dann die Session-Tabelle leeren: "TRUNCATE `sessions`;"
Zusätzlich lassen sich in gleicher Weise der Cache leeren (nicht löschen!) also alle Tabellen die die mit "cache_" beginnen.
Viel Glück.
Hallo, qb schrieb Also: 1.
am 23.06.2017 - 15:01 Uhr
Hallo,
Also:
1. SQL-Console aufrufen
2. dann die Session-Tabelle leeren: "TRUNCATE `sessions`;"
Zusätzlich lassen sich in gleicher Weise der Cache leeren (nicht löschen!) also alle Tabellen die die mit "cache_" beginnen.
Viel Glück.
das hat leider gar nichts gebracht :-(
Lässt sich das
In Deinem Fall dürfte es konkret darann liegen, dass Du Bilder als Binärdaten in den Blobs ablegst (ablegen lässt). Das ist natürlich speziell in Zusammenhang mit einer Comunity-Seite tötlich - bzw. nur eine Frage der Zeit bis es knallt.
irgendwie anders lösen? Es handelt sich in Summe um 10 gemeinnützige Projekte, die alle gleich aufgebaut sind :-(
Hi, also nochmal: ohne
am 23.06.2017 - 15:34 Uhr
Hi,
also nochmal:
ohne direkten Zugriff auf die MYSQL Einstellungen, wirst Du das nicht lösen können.
Daher habe ich empfohlen den Import lokal zu machen, dort kannst Du solche Einstellungen vornehmen.
Das Innodb logfile ist zu klein um die Transaktion auszuführen!
https://www.percona.com/blog/2011/07/09/how-to-change-innodb_log_file_size-safely/
Wenn Du das nicht grösser machst, funktioniert der Import in die InnoDB Engine nicht!
Gruss
Robert
Hallo, danke für die
am 01.07.2017 - 14:39 Uhr
Hallo, danke für die Erklärung. Ich versuche es lokal, bin aus familiären Gründen die letzten Tage leider nicht dazu gekommen. Ich würde mich dann wieder melden.
Allerdings klang es ja so, als sei Drupal grundsätzlich nicht für Projekte mit massig Fotos geeignet. Hat hier jemand Lösungsansätze?
Grüße
Zitat: Allerdings klang es ja
am 01.07.2017 - 15:32 Uhr
Allerdings klang es ja so, als sei Drupal grundsätzlich nicht für Projekte mit massig Fotos geeignet. Hat hier jemand Lösungsansätze?
Drupal dürfte es ziemlich egal sein wieviele Nodes oder Images du anlegst, die Datenbank auf der Drupal läuft gehört ja nicht in dem Sinne zu Drupal, sondern zu deinem Hosting Paket.
Ich würde nicht auf die Idee kommen 36000 Bilder auf einem Klickbunti Tarif zu betreiben, im schlimmsten Fall noch kostenlos...
Bei z.B. meinem Managed Server habe ich den Zugriff auf solche Funktionen und im Notfall eine 24/7 Hotline Nummer (gegen Bezahlung wenn der Fehler bei mir liegt), dafür keine Warteschleifen oder ähnliche lapidare Auskünfte, sondern engagierte Techniker, die in 6 Jahren jedes Problem lösen konnten und vor allem auch lösen wollten....
Sorry, wenn ich das so schreibe...aber wenn du von Eingriffen in MySQL nur wenig verstehst, aber ein ziemlich großes Projekt betreibst, dann würde ich für die Zukunft anders rangehen.
Sei es ein Spendenbutton oder minimale Werbung etc. um zumindest ein paar hundert Euro einzunehmen für genau solche Fälle und einen vernünftig betreuten Server mit ausreichend Rechten und Kapazität.
Wenn deine Seite jetzt weiter wächst, können ähnliche Probleme immer wieder mal auftauchen, und du bekommst nur eine Standardantwort vom Anbieter und kommst nicht weiter.
Da muß man dann selbst entscheiden ob man Serverkonfiguration etc. auch noch komplett erlernen/betreuen will oder auch mal Dinge abgibt die extrem Zeit und Nerven kosten.
Leider kann ich dir zu deiner technischen Frage auch nicht weiter helfen, nur viel Glück wünschen das du schnell eine Lösung findest.
Grüße Jenna
Grundsätzlich kannst du
am 02.07.2017 - 08:14 Uhr
Grundsätzlich kannst du unendlich viele Images in Drupal verwalten,
die Frage ist, wie du es machst.
Man könnte z.B. für die suche einen Solr Index server für die Suche
verwenden und die Images über einen statischen Webserver ausliefern lassen.
Benötigt kaum Ressourcen und ist superschnelle.
MfG
Robert
Jenna
am 02.07.2017 - 21:02 Uhr
Allerdings klang es ja so, als sei Drupal grundsätzlich nicht für Projekte mit massig Fotos geeignet. Hat hier jemand Lösungsansätze?
Drupal dürfte es ziemlich egal sein wieviele Nodes oder Images du anlegst, die Datenbank auf der Drupal läuft gehört ja nicht in dem Sinne zu Drupal, sondern zu deinem Hosting Paket.
Der Auffassung bin ich auch, allerdings ist das Argument halt Shared Hosting :-(
Ich würde nicht auf die Idee kommen 36000 Bilder auf einem Klickbunti Tarif zu betreiben, im schlimmsten Fall noch kostenlos...
Es handelt sich um einen Webhosting-Tarif von Netcup. Wusste gar nicht, dass es noch kostenlose gibt?
Bei z.B. meinem Managed Server habe ich den Zugriff auf solche Funktionen und im Notfall eine 24/7 Hotline Nummer (gegen Bezahlung wenn der Fehler bei mir liegt), dafür keine Warteschleifen oder ähnliche lapidare Auskünfte, sondern engagierte Techniker, die in 6 Jahren jedes Problem lösen konnten und vor allem auch lösen wollten....
Sorry, wenn ich das so schreibe...aber wenn du von Eingriffen in MySQL nur wenig verstehst, aber ein ziemlich großes Projekt betreibst, dann würde ich für die Zukunft anders rangehen.
Sei es ein Spendenbutton oder minimale Werbung etc. um zumindest ein paar hundert Euro einzunehmen für genau solche Fälle und einen vernünftig betreuten Server mit ausreichend Rechten und Kapazität.
Wenn deine Seite jetzt weiter wächst, können ähnliche Probleme immer wieder mal auftauchen, und du bekommst nur eine Standardantwort vom Anbieter und kommst nicht weiter.
Da muß man dann selbst entscheiden ob man Serverkonfiguration etc. auch noch komplett erlernen/betreuen will oder auch mal Dinge abgibt die extrem Zeit und Nerven kosten.
Leider kann ich dir zu deiner technischen Frage auch nicht weiter helfen, nur viel Glück wünschen das du schnell eine Lösung findest.
Grüße Jenna
Danke für deine Denkanstöße, Jenna. Die Überlegung, einen Server zu mieten, hatte ich bereits auch. Aber wie du schon sagst, muss dieser auch betreut werden. Und irgendwo sind Zeit, Knowhow und Geld halt doch endlich. Die Problematik an der Sache ist, dass die Webseiten gemeinnützige Online-Projekte sind. Wir recherchieren selbst, fotografieren selbst, um uns urheberrechtlich keine Sorgen machen zu müssen. Sobald Werbung etc. eingebunden wird, handelt es sich telemedienrechtlich um eine andere Kategorie, deren Risiken nicht in einem Verhältnis zum Nutzen stehen wrüden. Unser Team hat das schon mal andiskutiert und sich gegen Werbung entschieden. Mit Spenden ist es ähnlich.
Ehrlich gesagt bin ich momentan ziemlich rat- und planlos, was die nächsten Schritte betrifft. Klar würde ich sofort einen RootServer kaufen und die Domains inkl. Daten umziehen - nur wenn damit nicht das Architekturproblem behoben ist, nützt mir das wenig. Ich bin auch gern bereit, mir weiteres Wissen anzueignen. Nur wird das vermutlich nicht so schnell funktionieren, wie die Behebung des Problems benötigt.
Zumindest hab ich gerade keinen Fahrplan :-(
Zitat:Es handelt sich um
am 02.07.2017 - 23:28 Uhr
Es handelt sich um einen Webhosting-Tarif von Netcup. Wusste gar nicht, dass es noch kostenlose gibt?
Sorry, das hab ich so vor mich hin geschrieben, ich meinte mit kostenlos, das ihr so ein großes Projekt kostenlos anbietet bzw. bereit stellt.
Nur wie schon geschrieben, es kann leicht ein Dauerproblem werden mit wachsenden Inhalten und kleinem Webspace, damit ist schnell jeder überfordert, der nicht Fachmann auf dem Gebiet ist.
Langfristig kann man ja nicht dir die Verantwortung aufhalsen, das ist ganz einfach ein 2. Full-Time-Job, zumindest zeitweise, das lernt man ja nicht an einem Nachmittag was da auf dich zukommt.
Das hilft dir jetzt zwar technisch auch nicht weiter, ich meinte auch mehr auf die Zukunft hin gesehen, braucht ihr irgendwie eine tragbare Lösung die dich nicht zeitlich und nervlich komplett überfordert.
Falls du Infos zum Hosting möchtest, schreib mir gern eine PN.
Grüße Jenna
Ich meinte keinen Root-Server, sondern einen Managed-Server, der wird professionell betreut und reicht normalerweise von den Rechten her aus. Und notfalls gib es dann ja immer noch den technischen Support, die eingreifen können (das dann eben gegen extra Gebühr).