[mySQL] Status "** DEAD **" in PROCESSLIST

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • JasperE
  • Registratie: December 2003
  • Laatst online: 03-10 10:05
Ik heb een mySQL database die voornamelijk bestaat uit een myISAM tabel van ongeveer vier miljoen rijen bestaande uit een autoincrement-id, enkele numerieke waarden en een varchar met daarop een UNIQUE en FULLTEXT index.

Met deze database wordt verbinding tegelijkertijd gemaakt door verscheidene TCL scripts, ik gebruik mysqltcl om vanuit TCL de database aan te kunnen spreken.

Dit heeft jarenlang goed gewerkt, zomaar ogenschijnlijk uit het niets bleven opeens queries hangen. In de status kolom van "SHOW PROCESSLIST" stonden verschillende queries voor "SHOW DATABASES" open met in de statuskolom de tekst "** DEAD **". In de logbestanden stonden verder geen foutmeldingen.

mySQL kreeg ik vervolgens niet afgesloten met het script uit init.d (bleef hangen), een "kill -9" is telkens nodig.

Versies:
OS: Ubuntu Hardy LTS
mySQL: "mysqld Ver 5.0.51a-3ubuntu5.4-log for debian-linux-gnu on i486 ((Ubuntu))"
(gewoon uit de repos dus)

Wat ik al heb gedaan om dit probleem op te lossen:
  1. "myisamcheck -r" op alle .MYI's uit alle databases.
  2. reboot
  3. memtest86+ een tijd laten lopen, geen fouten gevonden.
  4. De nieuwste mysql versie gecompileerd (5.1.40) met een andere --prefix, die laten draaien op een kopie van /var/lib/mysql en vervolgens mysql_upgrade gedraaid. De fout trad nog steeds op. Nu stond er echter niet "** DEAD **" in processlist maar oneindig "executing".
  5. De mysqltcl versie van de ubuntu repos vervangen door laatste en zelf gecompileerde versie.
  6. Vrije schijfruimte gecheckt.
  7. Alle tabellen uit alle databases gedumped, gedropped en opnieuw aangemaakt.
  8. "apt-get install --reinstall" voor alle mysql componenten.
De fout treed nog steeds op, telkens na ongeveer 4 minuten na het starten van de database en scripts. Wat de fout precies triggert heb ik niet kunnen vinden.

Iemand een idee wat hier aan de hand kan zijn?

[ Voor 6% gewijzigd door JasperE op 15-11-2009 21:03 ]


Acties:
  • 0 Henk 'm!

  • Kees
  • Registratie: Juni 1999
  • Laatst online: 16:58

Kees

Serveradmin / BOFH / DoC
Als je handmatig queries uitvoert, crashen of loopen die queries dan ook?

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan


Acties:
  • 0 Henk 'm!

  • JasperE
  • Registratie: December 2003
  • Laatst online: 03-10 10:05
Nee het lijkt helaas nogal random op te treden. De query in de processlist met status "dead" is tot dusver "show databases" geweest, maar als ik deze query handatig uitvoer werkt het prima.

Edit: Ik denk dat ik ook een keer een andere query te hebben gezien die vastzat maar dit weet ik niet zeker.

[ Voor 22% gewijzigd door JasperE op 15-11-2009 21:00 ]


Acties:
  • 0 Henk 'm!

  • Kees
  • Registratie: Juni 1999
  • Laatst online: 16:58

Kees

Serveradmin / BOFH / DoC
Als het kan denk ik dat je het beste de 5.1.x uit de ubuntu repos kan halen, en dan de data exporteren en opnieuw importeren.

Show databases is nu niet bepaald een query die veel programma's uitvoeren, dus het lijkt erop dat er iets in de datadir mis is?

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan


Acties:
  • 0 Henk 'm!

  • JasperE
  • Registratie: December 2003
  • Laatst online: 03-10 10:05
Ik heb query logging aangezet en zag dat de show databases query vaak werd uitgevoerd door de verschillende clients (scrollsnelheid zelfs met "tail -f"). Vervolgens heb ik in de scripts uitgezocht hoe dat kwam, het bleek een functie te zijn om te checken of de mysql verbinding nog werkte. Niet erg logisch, dus heb ik het script vervolgens aangepast om ping te gebruiken. Nu lijkt de fout niet meer op te treden. (afkloppen! zout! waar is het zout?)

Ironisch genoeg was het dus blijkbaar de functie die de werking van de mysql verbinding moest checken die diezelfde verbinding om zeep hielp.

Hoe dat kan en waarom het na jaren zonder fouten zomaar opeens fouten gaf weet ik echter nog steeds niet.

[ Voor 4% gewijzigd door JasperE op 15-11-2009 22:17 ]


Acties:
  • 0 Henk 'm!

  • JasperE
  • Registratie: December 2003
  • Laatst online: 03-10 10:05
De fout bleef nog af en toe optreden, bijvoorbeeld bij het gebruik van phpmyadmin. Het probleem leek op te treden bij queries waarbij de database en gebruikersrechten opgevraagd werden. Dit deed mij vermoeden dat er ergens iets mis was met de mysql database waarin de rechten opgeslagen zijn. (/var/lib/mysql/mysql)

Uiteindelijk lijk ik het nu zo opgelost te hebben (fingers crossed):
  1. $ /etc/init.d/mysql stop
  2. $ mv /var/lib/mysql /var/lib/mysql_bad
  3. $ /usr/bin/mysql_install_db
  4. Omdat het bij mij op debian draait heb ik de debian-sys-maint account aangemaakt (wachtwoord staat in /etc/mysql/debian.cnf)
  5. Toen heb ik alle databasenamen en gebruikers opnieuw aangemaakt.
  6. $ /etc/init.d/mysql stop
  7. Toen heb ik alle directories van alle databases behalve de "mysql" database uit /var/lib/mysql_bad overgezet naar /var/lib/mysql
  8. /etc/init.d/mysql start

Acties:
  • 0 Henk 'm!

  • JasperE
  • Registratie: December 2003
  • Laatst online: 03-10 10:05
Correctie, zojuist de fout alsnog weer gekregen. Het opnieuw aanmaken van de mysql tabel heeft dus geen uitkomst geboden.
Iemand nog een idee over wat de oorzaak van de fout zou kunnen zijn?
Dit keer heb ik wel kunnen zien wat er gebeurt, in phpmyadmin bleef het laden van een pagina hangen, dit stond er in "SHOW PROCESLIST"

code:
1
2
3
| 191381 | root        | localhost | gebruiker     | Query          |   35 | checking permissions | SELECT *,
                    `TABLE_SCHEMA`       AS `Db`,
                    `TABLE_NAME`         |


En een paar seconden later stond dit er:
code:
1
2
3
| 191381 | root        | localhost | gebruiker     | Query          |   38 | *** DEAD ***       | SELECT *,
                    `TABLE_SCHEMA`       AS `Db`,
                    `TABLE_NAME`         |

8)7

Voorlopig het gebruik van phpmyadmin dus maar weer vermijden.

mySQL bugreport: http://bugs.mysql.com/bug.php?id=48515
De fout lijkt zeldzaam te zijn maar ik ben in ieder geval niet de enige die 'm krijgt.

[ Voor 72% gewijzigd door JasperE op 24-01-2010 14:37 ]

Pagina: 1