MySQL-Fehlercode 2013 beim Einloggen - aber nicht immer

Ich habe hier eine klassische Webanwendung mit PHP und MySQL; Basis
ist eine aktuelle Debian stable-Installation. Seit August läuft die
Anwendung tadellos, wobei die Datenbank aber gewaltig wächst, derzeit
enthält diese mehr als 24 GB Daten, alle Tabellen (MyISAM) sind
fehlerfrei laut myisamchk.

Nun hab ich aber seit einigen Tagen, ohne irgendetwas geändert zu
haben, ein Problem: MySQL reagiert auf Kontaktanfragen häufig - aber
nicht immer! - eher ablehnend und bringt Fehlermeldungen mit dem Code
2013:
#2013 - Lost connection to MySQL server at 'reading authorization
packet', system error: 104

Statt 'reading authorization packet' steht da manchmal auch etwas
anderes drinnen, es ist aber jedesmal der Fehlercode 2013. In meinen
selbstgeschriebenen Logs der Tools, die auf die Datenbank zugreifen,
hab ich nun Hinweise entdeckt, dass das ganze Dilemma vor etwa einer
Woche begann, zunächst sehr selten und dann immer häufiger. In den
Logs des Servers (syslog, mysql.log, etc.) finden sich keinerlei
Fehlerhinweise.

Der MySQL-Fehler 2013 steht laut MySQL-Doku für "Lost connection to
MySQL server during query", was leider nicht sehr aussagekräftig ist.
Im Web lernt man dann, dass dieser Fehlercode in den verschiedensten
Situationen auftreten kann, wirklich hilfreiches war aber nicht dabei.
(Eigentlich ist der Code dafür gedacht zu signalisieren, dass der
MySQL-Server während der Anfrage crashte oder die Netzwerkverbindung
ein Problem hatte. Beides trifft definitiv
nicht zu.)

Der genannte Fehler tritt sowohl beim Verbindungsaufbau über PHP-
Scripte auf als auch über die mysql-Kommandozeile - egal ob übers
Netzwerk oder auf dem Server selbst per localhost aufgerufen. Es gibt
i.Ü. sowohl in der PHP- als auch in der MySQL-Bug-Datenbank Einträge
zum Fehlercode 2013, aber auch die dortigen Infos machten mich nicht
schlauer.

Ich bin euch für alle Hinweise dankbar!
Stefan

Re: MySQL-Fehlercode 2013 beim Einloggen - aber nicht immer

z80crew wrote:
> Statt 'reading authorization packet' steht da manchmal auch etwas
> anderes drinnen, es ist aber jedesmal der Fehlercode 2013. In meinen
> selbstgeschriebenen Logs der Tools, die auf die Datenbank zugreifen,
> hab ich nun Hinweise entdeckt, dass das ganze Dilemma vor etwa einer
> Woche begann, zunächst sehr selten und dann immer häufiger. In den
> Logs des Servers (syslog, mysql.log, etc.) finden sich keinerlei
> Fehlerhinweise.

Also auch nicht im daemon-Log, wohin bei aktuellen debian-Packages der
Output z.B. von Crashes etc. geht (das gleiche Log, bei dem auch beim
Startup ein wenig geplappert wird)?

> Der genannte Fehler tritt sowohl beim Verbindungsaufbau über PHP-
> Scripte auf als auch über die mysql-Kommandozeile - egal ob übers
> Netzwerk oder auf dem Server selbst per localhost aufgerufen. Es gibt

Oh. Mal einen strace vom lokalen mysql-Client gemacht, wenn der ueber Unix
Domain Socket connected? Irgendwas auffaelliges?

Re: MySQL-Fehlercode 2013 beim Einloggen - aber nicht immer

> > Statt 'reading authorization packet' steht da manchmal auch etwas
> > anderes drinnen, es ist aber jedesmal der Fehlercode 2013. In meinen
> > selbstgeschriebenen Logs der Tools, die auf die Datenbank zugreifen,
> > hab ich nun Hinweise entdeckt, dass das ganze Dilemma vor etwa einer
> > Woche begann, zunächst sehr selten und dann immer häufiger. In den
> > Logs des Servers (syslog, mysql.log, etc.) finden sich keinerlei
> > Fehlerhinweise.
> Also auch nicht im daemon-Log, wohin bei aktuellen debian-Packages der
> Output z.B. von Crashes etc. geht (das gleiche Log, bei dem auch beim
> Startup ein wenig geplappert wird)?

Richtig, im daemon.log steht jeweils nur die Info, dass der Server
normal gestartet bzw. beendet wurde - also immer dann, wenn ich das
von Hand gemacht habe. Kein Fehlermeldungen, keine Crashhinweise,
nichts außergewöhnliches. Es gibt auch sonst keinerlei Hinweise auf
ein Hardware-Problem o.ä.


> > Der genannte Fehler tritt sowohl beim Verbindungsaufbau über PHP-
> > Scripte auf als auch über die mysql-Kommandozeile - egal ob übers
> > Netzwerk oder auf dem Server selbst per localhost aufgerufen. Es gibt
>
> Oh. Mal einen strace vom lokalen mysql-Client gemacht, wenn der ueber Unix
> Domain Socket connected? Irgendwas auffaelliges?

Ich hab folgendes ausgeführt:
strace mysql -uUSER -p DB

Das ist ein Auszug der Ausgabe von strace, wenn der Fehler auftritt:
stat64("/usr/share/mysql/charsets/Index.xml", {st_mode=3DS_IFREG|0644,
st_size=3D18221, ...}) =3D 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY|O_LARGEFILE) =3D 4
read(4, " close(4) =3D 0
setsockopt(3, SOL_SOCKET, SO_SNDTIMEO, "\2003\341\1\0\0\0\0", 8) =3D 0
write(3, "?\0\0\1\215\246\3\0\0\0\0\1\10\0\0\0\0\0\0\0\0\0\0\0\0"...,
67) =3D -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
shutdown(3, 2 /* send and receive */) =3D 0
close(3) =3D 0
fstat64(1, {st_mode=3DS_IFCHR|0620, st_rdev=3Dmakedev(136, 1), ...}) =3D 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0x1000) =3D 0xf7f9f000
write(2, "ERROR 2013 (HY000): ", 20ERROR 2013 (HY000): ) =3D 20
write(2, "Lost connection to MySQL server "..., 89Lost connection to
MySQL server at 'sending authentication information', system error:
32) =3D 89

Und hier die gleiche Stelle im strace, wenn die Anmeldung klappte:
stat64("/usr/share/mysql/charsets/Index.xml", {st_mode=3DS_IFREG|0644,
st_size=3D18221, ...}) =3D 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY|O_LARGEFILE) =3D 4
read(4, " close(4) =3D 0
setsockopt(3, SOL_SOCKET, SO_SNDTIMEO, "\2003\341\1\0\0\0\0", 8) =3D 0
write(3, "?\0\0\1\215\246\3\0\0\0\0\1\10\0\0\0\0\0\0\0\0\0\0\0\0"...,
67) =3D 67
setsockopt(3, SOL_SOCKET, SO_RCVTIMEO, "\2003\341\1\0\0\0\0", 8) =3D 0
read(3, "\7\0\0\2\0\0\0\2\0\0\0", 16384) =3D 11
poll([{fd=3D3, events=3DPOLLIN|POLLPRI}], 1, 0) =3D 0
setsockopt(3, SOL_SOCKET, SO_SNDTIMEO, "\2003\341\1\0\0\0\0", 8) =3D 0
write(3, "\17\0\0\0\3show databases", 19) =3D 19


Jedenfalls schon mal danke für die Antwort!

Viele Grüße,
Stefan