Ich nutze seit mehreren Jahren XAMPP und hab grad ein echt merkwürdiges Problem, wie ich es zuvor noch nie hatte.
Auf die Kürze:
Ich greife auf eine zuvor schon verwendete und fehlerfrei laufende Datenbank zu und bekomme folgenden Fehler:
#2006 - MySQL server has gone away
Das ganze passiert immer wieder, sobald ich auf diese Datenbank zugreife, natürlich nachdem ich den Server wieder gestartet habe.
Das schlimmste an der Sache ist aber, dass die Datenbank die diesen Fehler auslößt verloren ist und nicht wieder hergestellt werden kann, da auch die Datenbank "information_schema" bei jedem Zugriffsversuch diesen Abstrurz verursacht und lt. errorlog (Inhalt errorlog siehe unten) dort der Fehler liegt. Andere Datenbanken auf dem Server funktionieren noch einwandfrei.
Ich konnte bisher nicht nachvollziehen, wann dieser Fehler passiert, einige Tage läuft alles ohne Probleme und plötzlich kracht es wieder.
Die Googlesuche konnte mir keine Lösung liefern, da die Fehlermeldung "#2006 - MySQL server has gone away" zu allgemein ist und die Suche nach den InnoDB-Fehlern kein Ergebnis liefert, das ich mit meinem Problem in Verbindung bringen kann.
Mich würde zum einen Interessieren, ob es evtl. Leidensgenossen gibt, bzw. diese Fehlerkonstellation bekannt und eine Lösung verfügbar ist.
Noch einige Versuche meinerseits:
Da ich in einer Domäne bin und auf meinem System eingeschränkte Rechte habe und z.B. Apache- und MySQL-Dienste nicht starten oder beenden durfte,lag der Gedanke nahe, dass die Dienste unsauber beendet werden, weshalb ich die Dienste entfernt habe und Apache und MySQL jetzt über das ControlPanel manuell starte.
Die Zugriffsrechte auf alle Verzeichnisse in welchen Daten abgelegt sind habe ich überprüft, ich habe volle Zugriff.
Der Zugriff per Konsole geht schief, sobald in irgendeiner Form auf eine betroffenen Datenbank stattfindet, ich habe keine Chance an eine der verursachenden Tabellen ranzukommen.
Mein System:
WindowsXp Professional SP3
Error Log:
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
090529 12:49:41 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
090529 12:49:41 InnoDB: Started; log sequence number 0 2813379
090529 12:49:41 [Note] Event Scheduler: Loaded 0 events
090529 12:49:41 [Note] mysql\bin\mysqld.exe: ready for connections.
Version: '5.1.33-community' socket: '' port: 3306 MySQL Community Server (GPL)
090529 12:49:52 InnoDB: Error: (1500) Couldn't read the MAX(TemplateFormatCalculationID) autoinc value from the index (PRIMARY).
090529 12:49:52 InnoDB: Assertion failure in thread 284 in file .\handler\ha_innodb.cc line 2601
InnoDB: Failing assertion: error == DB_SUCCESS
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/ ... overy.html
InnoDB: about forcing recovery.
090529 12:49:52 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=2
max_threads=151
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133304 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x24976e0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
006AC8BB mysqld.exe!???
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0249D050=SHOW TABLE STATUS FROM `article_management`
thd->thread_id=2
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.