YF=X5.dY "xXсr3O1 1TH姈z٠ IxGHjtA20 u=2b6ӄdOӻ݅d6Ga2 bИ0#(S֘{OAe;r *3ɬ;:nO*av!$*!ƤtNy5 r@r >BN u~6ڮ,̻GqlUiA~NG| htOoOC!6 gQ.U#aBoPr2CF9ys0&&Qdٲ1i=5a?1C1JNchL%'־'Kg ~eEYT\q٬dvGXs~+$J"Z <[L q=ws &G~г<^0헍V:ZEaku(OI4p "`'Z68|XͤwOCRѐҳ;"yMíi.0Q羯cS jY3ڧF{KV%lNkkGXT26FhlJݑdž:T_σ\vGwI=f/=?嵰Co3׸* ?3=#v= wmaYQ ^jK `a^mZM7H>5O35%Cbw3,:2Y 4Nu3YVڳr6ptU}jPD,lٺ b:R]Qnz öQ"OzQޒ1" kNsI$nlrrPf͋j=SхqVdu_8p m\$-zT$ GS<_B"kӖHsS /dM{=y^g# ^+kf.{m+w$\k0¨7ƛ ڋ2;4䲧@-~p"9&ʹmw˱ް>Pr22_dK}#XB +Vbw +z3az(۴ĻǰÞT}Tv<>W:F\L?48M'NEM<`yK;9VSXZpʠA :86*MӠY*Jgy̥e/qse\s͍8i@NF5htfu@ԝN:<^wMBߓ.T1Uڔ1GmЫMJ!C;U0;=JjX^5Zȳ3>drk1øT(ͅ`1^(5W^sm<  (tHJUjy4󯖨ԲCk&z2G!uIz^o 4V3!1W#pf>V}0V@TZ0']JYFF} Y @\dqZcF/e 3'Cz#=^\3_u%KUEZk<*raJR"g$5uIZCP;ĚFRs暯ϽHҌz$BN̲n&&UoIWW-"6'v^H y xٓhѝ'5\^SCb+J.@/ͷּ!,6Dcm3-, .}㟄2c>Y^H_j̬z+]PVjseMr ETJ\s"~o*?f0M|:>)1l%Vl~0` ((^sw4FV3*LP^9+YKҞVƒW:.i{lεw]ZBJPs5׆25T$"{b*bOF$&U,s*]]oQuH'Wa+ĻM Vb4H ȸcm.q!xh5W^smC34`'i(<-!*jj{@5_6P6r+<S^=طSG o-g&BeϗDY$b@D)\뜢5<],b4k+܋D홤KQvt0{0o+Y7¾y Y8ِRSsukķG=0gv^ۦQFS22:B5v\A䫯ҬCz>Ҝ]C,S@LzG(4+N@߻⤸'@! 0 y9X)ٯf7ZIwxfM(Fdy4jvNviv̢XRJ0f ; ?fҲH7;k{BTgpNso|٣#ί *C DkyAͦP% "sD "k itWrr B\->yH}v-_rvH(ft1w27  X\GԾ֣/!-T#u#2 ıPԜhyX,t99\y5_{E13HzyɂmԿ|K/5D^q'1`r zLT%6 ԋ}):)ڥJ 9CAm02'%92P@Iqc*%Gq3NbNjA=,>j?YXݱު5$֫ zuHxYbuМDP LUGUõ99ǁdۣ|oL\ {f:=uFU,s^;8MxK;d 0o΃oXtm&N-Ipnu#!\=,IӅz\y5_ ̓/WȺO5]/5|}ɣV ~#\AD8t &7|7w~}-8PΎw<`
MySQL- das offizielle Handbuch

Subscribe to the monthly
MySQL Newsletter!

A.2.2 MySQL server has gone away-Fehler

Dieser Abschnitt behandelt auch den verwandten Lost connection to server during query-Fehler.

Der hufigste Grund fr den MySQL server has gone away-Fehler ist eine Zeitberschreitung, nach der der Server die Verbindung schloss. Vorgabemig schliet der Server die Verbindung nach 8 Stunden, wenn nichts passiert ist. Sie knnen diesen Wert mit der wait_timeout-Variablen ndern, die beim Start von mysqld gesetzt wird.

Ein weiterer hufiger Grund fr den MySQL server has gone away-Fehler ist das Absetzen eines ``close'' auf Ihre MySQL-Verbindung mit dem anschlieenden Versuch, auf der geschlossenen Verbindung eine Anfrage abzusetzen.

Sie knnen berprfen, ob der MySQL-Server gestorben ist, indem Sie mysqladmin version ausfhren und die Uptime untersuchen.

Wenn Sie ein Skript haben, mssen Sie die Anfrage lediglich noch einmal fr den Client absetzen, um eine automatische Neuverbindung zu machen.

Normalerweise knnen Sie folgende Fehler-Codes fr diesen Fall abfragen (die Betriebssystem-abhngig sind):

CR_SERVER_GONE_ERROR Der Client konnte keine Anfrage an den Server schicken.
CR_SERVER_LOST Der Client erhielt beim Schreiben zum Server keinen Fehler, bekam aber keine vollstndige (oder berhaupt keine) Antwort.

Sie erhalten diese Fehler auch, wenn Sie eine Anfrage zum Server schicken, die falsch oder zu Gro ist. Wenn mysqld ein Paket erhlt, das zu Gro oder nicht in Ordnung ist, nimmt er hat, dass etwas mit dem Client schief ging und schliet die Verbindung. Wenn Sie groe Anfragen brauchen (beispielsweise wenn Sie mit BLOB-Spalten arbeiten), knnen Sie die Anfragebeschrnkung erhhen, indem Sie mysqld mit der -O max_allowed_packet=#-Option starten (Vorgabe 1 MB). Der zustzliche Speicher wird bei Bedarf zugewiesen, daher benutzt mysqld nur dann mehr Speicher, wenn Sie eine groe Anfrage ausfhren oder wenn mysqld ein groes Ergebnis zurckgeben muss!


User Comments

Posted by [name withheld] on June 7 2002 5:11pm[Delete] [Edit]

For those amongst us unfortunate enough to run
MySQL on windows 2000:
If you can't get the service to start, configure
your my.ini script to use innodb and set some
normal params as described in the manual
elsewhere.
Run "MySQLd --skip-name-resolve" from the command
prompt. When innodb has started you can login to
your database with root, even though the MySQL
service doesn't appear to be started. You can now
use your database as you see fit. Also, you don't
have to try to start the service once you've done
the above, because that won't work anyway.
This worked for me on Windows 2000 SBS (yes you
can laugh at me), but I'm not sure weither this
is the solution for everyone...
Depsua666@hotmail.com

Posted by Rodney Peck on October 5 2002 1:58pm[Delete] [Edit]

Here's something that others might run across
which I haven't
seen mentioned on this site elsewhere.

I was suddenly getting server restarts and 'server
has gone
away' errors from one of the hosts that processes
data on
my mysqld database. There were two other hosts which
were running just fine. Rebuilding the indices
with myisamchk
took a long time, but didn't fix the problem.

The problem turned out to be caused by a lack of
reverse
name lookups in DNS for the ip of the clients.
Somehow
the dns server listed in /etc/resolv.conf had
stopped doing
reverse lookup resolution for the zone these
clients were in.
Some of the hosts were listed in /etc/hosts --
those were
the ones that were working.

Simply adding the hostnames to /etc/hosts with the
correct
ip addresses was enough to get mysqld and the
client working
normally again.

The dns server has since been fixed as well to manage
the reverse zone for the client network as expected by
mysqld.


This is interesting because the error has nothing
to do
with a network timeout as was described in the other
messages.

I dont know if it would have helped, but there was
nothing
logged in the error log for mysqld saying that it
failed
because of the ip address lookup.

Posted by hooi Yap on June 25 2003 1:41am[Delete] [Edit]

The way I have resolved the 'Error message = Lost connection to MySQL server during query' is to edit /etc/hosts.allow and then add an additional line as shown below to the file:
mysqld:127.0.0.1


Posted by Martin Mokrejs on August 27 2003 12:50pm[Delete] [Edit]

See more explanation and future request about this issue at

http://bugs.mysql.com/bug.php?id=1011

Posted by [name withheld] on September 24 2003 8:48am[Delete] [Edit]

If you got randomly errors like "Lost connection to MySQL server during query" or "MySQL server has gone away", then explanation can be this one.

When you use a script to connect to MySQL server (like Perl DBI) and fork childrens to make connection faster, it's best to avoid using the same MySQL channel in the parent and childrens, as I did :-( If not, a child could interrupt a request of another one, making MySQL somewhat confused (ie random error messages, depending of MySQL version)

The rule to follow is
1. fork children
2. THEN make new MySQL connection, by child.

See threads below on the subject, it can help ;-)