MySQL connection lost during query

[Verwijderd]

Op mijn server heb ik een database die vervelende problemen veroorzaakt. MySQL geeft regelmatig 'connection lost' tijdens het verbinden met deze database. De website die deze database gebruikt functioneert nog gewoon, echter gaat het exporten steeds mis.

In phpMyAdmin zie ik geen tabellen bij de database, maar er staat wel dat er 18 tabellen zijn, bij databasenaam(18). Het betreft een database met enkele myisam tabellen en enkele innodb tabellen.

MySQL dump via console helpt ook weinig en geeft ook een foutmelding.

code:

[root@server06 ~]# mysqldump -uadmin -p beek > beek.sql
Enter password:
mysqldump: Got error: 144: Table './beek/customimages' is marked as crashed and last (automatic?) repair failed when using LOCK TABLES
[root@server06 ~]#

Ik accepteer dat de database niet meer 100% is, echter functioneert de site gewoon en zou ik graag opnieuw de database importeren om van de MySQL connection lost foutmeldingen af te zijn. Deze veroorzaakt namelijk ook problemen voor andere sites, o.a. bij het verwerken van statistieken. Dit gaat al mis als de statistics binary langs MySQL database 'beek' komt. De databases hiervoor worden keurig verwerkt, maar MySQL sluit dan af met de melding:

code:

statistics: Unable to get database status for "beek": Lost connection to MySQL server during query
statistics: Unable to get database status for "beek": Lost connection to MySQL server during query
statistics: Unable to fetch info from MailLists: MySQL server has gone away
statistics: Unable to fetch info from MailLists: MySQL server has gone away
statistics: Unable to fetch info from Domain Services List : MySQL server has gone away
statistics: Unable to fetch info from Domain Services List : MySQL server has gone away
statistics: Unable to define client's ID: MySQL server has gone away
statistics: Unable to define client's ID: MySQL server has gone away

Ik ben radeloos. Mijn MySQL database server presteerde altijd zo goed, maar de laatste 2 maanden niet meer.

[Coltrui]

Ik ben geen MySQL-kenner, maar hoe gaat die om met command time-outs?

[HuHu]

Er is een tabel gecrashed zo te zien. Dus log even in op de server en voer handmatig een REPAIR TABLE uit en dan hopen dat er nog zoveel mogelijk hersteld kan worden.

Zie: http://dev.mysql.com/doc/refman/5.0/en/repair.html en http://dev.mysql.com/doc/refman/5.0/en/repair-table.html

[Verwijderd]

Wat nou als je eerst die table repairt en vervolgens weer een dump probeert te maken?

[Verwijderd]

Coltrui schreef op vrijdag 15 mei 2009 @ 11:49:
Ik ben geen MySQL-kenner, maar hoe gaat die om met command time-outs?

Uhhh... Ik weet niet, maar hij verliest verbinding doordat enkele tabellen niet meer gezond zijn.

HuHu schreef op vrijdag 15 mei 2009 @ 12:09:
Er is een tabel gecrashed zo te zien. Dus log even in op de server en voer handmatig een REPAIR TABLE uit en dan hopen dat er nog zoveel mogelijk hersteld kan worden.

Zie: http://dev.mysql.com/doc/refman/5.0/en/repair.html en http://dev.mysql.com/doc/refman/5.0/en/repair-table.html

Bedankt voor je reactie. Beide artikelen heb ik al doorgenomen.Hij poogt gewoon alle tabellen te repareren en zegt steeds dat hij de tabellen repareert, maar de tabellen zijn nog steeds stuk. Elke keer zegt hij dat hij ze repareert... maar ze blijven stuk.

Verwijderd schreef op vrijdag 15 mei 2009 @ 12:09:
Wat nou als je eerst die table repairt en vervolgens weer een dump probeert te maken?

Dat heb ik geprobeerd. myisamchk -r gedraaid en verschillende andere commando's om een reparatie te forceren. Helaas helpt het weinig, de dump maken blijft foutmeldingen geven. Ik ben liever wat data kwijt, dan nog steeds een corrupte database met corrupte tabellen te hebben.

[Manuel]

Doe anders even een CHECK, dan als het meezit zie je precies wat er allemaal fout is.

[remco_k]

Best kans dat je query gewoon in timeout raakt:

http://dev.mysql.com/doc/refman/5.1/en/gone-away.html
Even de timeout verlengen en gaan met die banaan.
Werkt het dan nog niet, kijk dan even naar max_allowed_packet:

You can also get these errors if you send a query to the server that is incorrect or too large. If mysqld receives a packet that is too large or out of order, it assumes that something has gone wrong with the client and closes the connection. If you need big queries (for example, if you are working with big BLOB columns), you can increase the query limit by setting the server's max_allowed_packet variable, which has a default value of 1MB. You may also need to increase the maximum packet size on the client end. More information on setting the packet size is given in Section B.1.2.10, “Packet too large”.

Been there, done that.

Verder staan er op die pagina nog veel meer zinvolle tips voor dit probleem.

[ Voor 74% gewijzigd door remco_k op 15-05-2009 15:35 ]

[Verwijderd]

Manueltje22 schreef op vrijdag 15 mei 2009 @ 15:25:
Doe anders even een CHECK, dan als het meezit zie je precies wat er allemaal fout is.

code:

[root@server06 ~]# mysqlcheck -uadmin -p beek
Enter password:
beek.account
error    : Table upgrade required. Please do "REPAIR TABLE `account`" to fix it!
beek.artikelen
error    : Table upgrade required. Please do "REPAIR TABLE `artikelen`" to fix it!
beek.bestelling_herinnering
error    : Table upgrade required. Please do "REPAIR TABLE `bestelling_herinnering`" to fix it!
beek.bestellingen
error    : Table upgrade required. Please do "REPAIR TABLE `bestellingen`" to fix it!
beek.bestellingen_items
error    : Table upgrade required. Please do "REPAIR TABLE `bestellingen_items`" to fix it!
beek.bestellingen_status
error    : Table upgrade required. Please do "REPAIR TABLE `bestellingen_status`" to fix it!
beek.boeken
error    : Table upgrade required. Please do "REPAIR TABLE `boeken`" to fix it!
beek.boeken_categorieen
error    : Table upgrade required. Please do "REPAIR TABLE `boeken_categorieen`" to fix it!
beek.boeken_gewichtsklassen
error    : Table upgrade required. Please do "REPAIR TABLE `boeken_gewichtsklassen`" to fix it!
beek.customimages
error    : Table upgrade required. Please do "REPAIR TABLE `customimages`" to fix it!
beek.ecards
error    : Table upgrade required. Please do "REPAIR TABLE `ecards`" to fix it!
beek.referers
error    : Table upgrade required. Please do "REPAIR TABLE `referers`" to fix it!
beek.scans
error    : Table upgrade required. Please do "REPAIR TABLE `scans`" to fix it!
beek.slides
error    : Table upgrade required. Please do "REPAIR TABLE `slides`" to fix it!
beek.talen
error    : Table upgrade required. Please do "REPAIR TABLE `talen`" to fix it!
beek.talen_items
error    : Table upgrade required. Please do "REPAIR TABLE `talen_items`" to fix it!
beek.variables
error    : Table upgrade required. Please do "REPAIR TABLE `variables`" to fix it!
beek.winkelmandje
error    : Table upgrade required. Please do "REPAIR TABLE `winkelmandje`" to fix it!
[root@server06 ~]#
[root@server06 ~]# mysql -uadmin -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 99557
Server version: 5.0.79-log Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use beek
Database changed
mysql> REPAIR TABLE `account`;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> REPAIR TABLE `account`;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    13
Current database: beek

ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> REPAIR TABLE `account`;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    4
Current database: beek

ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
[3]+  Stopped                 mysql -uadmin -p
[root@server06 ~]#

Manueltje22 schreef op vrijdag 15 mei 2009 @ 15:25:
Doe anders even een CHECK, dan als het meezit zie je precies wat er allemaal fout is.

Cruciaal: er wordt steeds binnen 1 seconde een time-out gegeven.

[remco_k]

Verwijderd schreef op vrijdag 15 mei 2009 @ 15:31:
Cruciaal: er wordt steeds binnen 1 seconde een time-out gegeven.

Check mijn post boven je even (mocht je die gemist hebben), en met name het laatste stuk over: max_allowed_packet

[LuCarD]

Ik heb er geen ervaring mee,

Maar ik kwam deze link tegen in google: http://blog.tigertech.net...l-table-upgrade-required/ dit lijkt te beschrijven waar jij nu last van heb.

[Verwijderd]

Het is momenteel denk ik opgelost... heb alle probleembestanden (ook 2x .sql) in /var/lib/mysql/beek verplaatst naar directory /root/beek.backup.20090515.

Het betrof gelukkig vooral oude bestanden die de mysqlcheck niet doorkwamen. Heb deze bestanden verplaatst en nu werkt de hoofdpagina nog steeds. Het ging waarschijnlijk om tables die toch niet meer gebruikt worden. scans.MTD had zelfs rechten root.root.

code:

[root@server06 ~]# ls -ltr beek.backup.20090515
total 290448
-rw-rw---- 1 mysql mysql        65 Aug 30  2006 db.opt
-rw-rw---- 1 mysql mysql      8724 Aug 30  2006 artikelen.frm
-rw-rw---- 1 mysql mysql      8666 Aug 30  2006 account.frm
-rw-rw---- 1 mysql mysql      8606 Mar 14 15:59 customimages.frm
-rw-rw---- 1 mysql mysql      8632 Mar 14 15:59 scans.frm
-rw-r--r-- 1 root  root        746 Mar 21 16:17 reek.sql
-rw-r----- 1 root  root   83988480 Mar 21 17:20 scans.TMD
-rw-rw---- 1 mysql mysql 213063224 May 14 12:10 scans.MYD
-rw-r--r-- 1 root  root        746 May 15 10:39 roombeek.sql
[root@server06 ~]#

De repairs gaan nu perfect en de MySQL database server verliest de verbinding niet in het geval van mysql repairs en andere queries op tabellen in de database 'beek'.

[Verwijderd]

Helaas bleek er toch belangrijke informatie te staan in de verplaatste bestanden. Indien ik queries draai op de tabel, dan krijg ik 'MySQL lost during query'. Hierdoor zorgen deze tabellen voor grotere problemen binnen de server, waaronder tijdens het maken van backups en verwerken van statistieken.

Heb de tabellen inmiddels terug gezet, omdat er afbeeldingen waren opgeslagen in een innoDB-database. Ben alleen bang voor nieuwe MySQL Server storingen en snap nog steeds niet dat de MySQL-melding onoplosbaar lijkt.

[cariolive23]

Even een vraag die een hoop mensen niet willen horen en waar ik mij vast niet populair mee maak, maar waarom gebruik je een database die genoodzaakt is om een functie REPAIR mee te leveren en die in de handleiding beschrijft dat om onduidelijke redenen de data corrupt kan raken?

Er zijn vele tientallen tot wellicht honderden databases, zie Google of Wikipedia, die deze problemen niet kennen en gewoon keurig hun werk doen. Bij deze lijst met betrouwbare databases, zitten ook een groot aantal open source databases die helemaal gratis zijn. Ook wat betreft performance hoeft het echt geen probleem te zijn, komt bij dat ik liever een langzame maar betrouwbare database heb dan eentje die razendsnel mijn data om zeep helpt.

Ik zou nu gaan redden wat er te redden valt en z.s.m. de data verhuizen naar een database die wel betrouwbaar is. Wanneer je de oorzaak van de corruptie niet weet (MySQL weet het zelf ook niet...), blijf je met MySQL het risico lopen dat het weer fout gaat. De boel omzetten is wellicht goedkoper dan blijven aanmodderen.

Maar wat je ook doet, veel succes toegewenst en hopelijk kun je de data redden.

[BCC]

Je kunt nog zo'n goede database engine hebben, maar er gaat toch niets boven een fatsoenlijk backup plan.

[cariolive23]

BCC schreef op vrijdag 26 juni 2009 @ 19:21:
Je kunt nog zo'n goede database engine hebben, maar er gaat toch niets boven een fatsoenlijk backup plan.

Helemaal mee eens, dat is altijd onmisbaar. Alleen moet dat wel de laatste redding zijn die je bij hoge uitzondering nodig hebt en niet iets waar je regelmatig op terug moet vallen. Je verliest er altijd data mee.

Ik vraag me zelfs af of replicatie (dus real time backup) hier een reddende engel had kunnen zijn, want wat gebeurt er als de master corrupt raakt? Stuurt die dan ook onzin naar de slaves? En backups, hoelang gaat dat "goed" met een corrupte database? Daarmee zou je het hele backupplan naar de bliksem helpen, je hebt er weinig aan om de ene corrupte database te vervangen door een corrupte backup. En om nu alle data van afgelopen dagen/weken weg te moeten gooien, daar zit je ook niet op te wachten.

Ik zou toch beginnen bij een betrouwbare database, dan weet je tenminste zeker dat je ook nog betrouwbare backups kunt maken.

[silverstorm]

kijk eens of je tabellen kan repareren met myisamchk.

[BCC]

cariolive23 schreef op vrijdag 26 juni 2009 @ 19:56:
[...]
Ik vraag me zelfs af of replicatie (dus real time backup) hier een reddende engel had kunnen zijn, want wat gebeurt er als de master corrupt raakt? Stuurt die dan ook onzin naar de slaves?

Replicatie is geen backup. En Mysql is een prima betrouwbare database.

[ Voor 6% gewijzigd door BCC op 26-06-2009 20:49 ]

[Kalentum]

cariolive23 schreef op vrijdag 26 juni 2009 @ 19:56:
[...]
Ik vraag me zelfs af of replicatie (dus real time backup) hier een reddende engel had kunnen zijn, want wat gebeurt er als de master corrupt raakt? Stuurt die dan ook onzin naar de slaves?

Een slave moet geen andere data gaan bevatten dan de master. Een INSERT die op de master faalt mag niet slagen op de slave. Anders heeft je slave andere data dan je master.

Ik zou toch beginnen bij een betrouwbare database, dan weet je tenminste zeker dat je ook nog betrouwbare backups kunt maken.

Elke database kan corrupte tables hebben. Het DBMS is maar 1 factor, besturingssysteem, filesystem, kwaliteit van de hardware zijn andere factoren.

MySQL is meestal zo geconfigureerd dat MyISAM het default tabel type is en die heeft grotere kans op problemen. InnoDB heeft veel meer checks ingebouwd en de kans op data corruptie is veel kleiner.

[cariolive23]

rutgerw schreef op vrijdag 26 juni 2009 @ 20:50:
Een slave moet geen andere data gaan bevatten dan de master. Een INSERT die op de master faalt mag niet slagen op de slave. Anders heeft je slave andere data dan je master.

Ja, dat is duidelijk, probleem is alleen dat de INSERT wel lijkt te slagen. En wat dan? De database maakt een corrupt record aan, wordt deze deze grap dan ook op de slave uitgehaald? Ik ken het replicatiesysteem van MySQL nauwelijks, maar vertrouw het van geen meter...

Elke database kan corrupte tables hebben. Het DBMS is maar 1 factor, besturingssysteem, filesystem, kwaliteit van de hardware zijn andere factoren.

Elke database kan corrupte tabellen hebben, maar MySQL is bij mijn weten de enige die ze zelf aanmaakt... Bij andere databases gaat het mis met het besturingssysteem, filesystem of inderdaad de hardware, maar zelf corrupte tabellen aanmaken? Dat is echt een functionaliteit van MySQL, zie de handleiding. De functie REPAIR is echt niet zomaar uit de lucht komen vallen, deze heb je gewoon hard nodig.

Ik bash ongetwijfeld teveel op MySQL, maar ik kan gewoon niet snappen waarom men het normaal vindt dat databases zonder enige reden corrupt raken en men de data kwijt raakt. MySQL mag dan gratis zijn (al is er ook een betaalde versie), helemaal kosteloos is het zeker niet. Ik heb toch de indruk dat velen hun geld met hun database moeten verdienen, dan ga je toch niet zo achteloos om met de data? Of ben ik echt toe aan een nieuwe bril?

Het raakt nu wel erg offtopic, ik laat het hier verder bij. Moraal van het verhaal: Er zijn betere en goedkopere databases.

[Frash]

Vergeet niet dat een nachtelijkse OPTIMIZE en REPAIR cronjob een hoop gezeik voorkomt. (Of gebruik de 'optimize voor dump' opties van een evt. mysqldump cronjob).

Met MyISAM is het gewoon een hoop gepiel door table-based locking itt InnoDBs row-based locking maar hier valt goed tegen op te boksen met optimalisatieroutines. Elke zichzelf respecterende DBA adviseert dan ook InnoDB voor tabellen waar veel (parallel) in geschreven wordt (sessies, log).

Ik ben het met iedereen eens dat MySQL out-of-the-box slordig kan zijn, maar het is naïef om MySQL 100% af te schrijven; daar staat het te goed z'n mannetje voor bij veel populaire sites.

[remco_k]

Verwijderd schreef op vrijdag 26 juni 2009 @ 18:02:
Helaas bleek er toch belangrijke informatie te staan in de verplaatste bestanden. Indien ik queries draai op de tabel, dan krijg ik 'MySQL lost during query'. Hierdoor zorgen deze tabellen voor grotere problemen binnen de server, waaronder tijdens het maken van backups en verwerken van statistieken.

Heb de tabellen inmiddels terug gezet, omdat er afbeeldingen waren opgeslagen in een innoDB-database. Ben alleen bang voor nieuwe MySQL Server storingen en snap nog steeds niet dat de MySQL-melding onoplosbaar lijkt.

Dit nog eens bekijken dan?
remco_k in "MySQL connection lost during query"