[mysql] tabellen tijdelijk niet beschikbaar

[marty]

Toen ik ineens bepaalde pagina's op m'n site niet meer kon accessen en dat er ook voor zorgde dat de hele verbinding met de database vastliep dacht ik eerst aan een bug in m'n code die mysql over z'n nek liet gaan. (stel ik zat in IE, dan kon ik daarna in IE nix meer doen, terwijl ik met opera gewoon weer m'n site kon bezoeken - tot het moment dat ik de bewuste pagina weer opvroeg)

Na veel gezoek bleek het door een simpele select query te komen. Ik ben daarna via mysqlfront (een soort phpmyadmin voor degene die het niet kennen, maar dan onder windows), eens queries gaan loslaten en wat bleek - zelfs op een SELECT * FROM table liep ie al vast.
IK vreeste het ergste, dat de boel corrupt was geraakt en ben toen onder de echte shell met myisamchk de tabellen gaan checken. Die gaf geen errors, ook niet met de flag -e. Toen ik mysql weer up and running bracht (ik had 'm down gehaald alvorens te checken) bleek dat de bewuste tabellen (bij nader onderzoek bleken er vier hetzelfde verschijnsel te tonen) ineens geen problemen meer te geven.

Dus eigenlijk geen probleem, want alles doet het weer.

Maar ik voel me er toch niet echt lekker bij. Er staat nogal belangrijke data op, en ik maak wel regelmatig backups, maar het zou zelfs al erg zijn als er een dag over heen gaat.

Ik heb nog eens op internet gezocht, maar kan er nix over vinden wat dit verklaart. Weet iemand misschien wat er aan de hand is en hoe ernstig het is?

[Verwijderd]

Waarschijnlijk geeft de MySQL deamon problemen. Misschien is het zinvol om een script te laten runnen vanuit cron o.i.d. om dat eens per uur te checken, en een mailtje /SMS te sturen of misschien zelfs direct de MySQL deamon een trap te geven.

Zonder een concrete foutmelding blijft het echter lastig. Heb je al in je server logs gekeken?

[marty]

Verwijderd schreef op 15 oktober 2002 @ 02:03:
Waarschijnlijk geeft de MySQL deamon problemen. Misschien is het zinvol om een script te laten runnen vanuit cron o.i.d. om dat eens per uur te checken

ehh...wat bedoel je precies? een cron m'n tabellen laten checken was ik toch al van plan, maar dat bedoel je zeker niet? IK weet wel redelijk wat van mysql en php, maar op serverniveau ben ik nog een onwijze n00b

Zonder een concrete foutmelding blijft het echter lastig. Heb je al in je server logs gekeken?

Hij staat bij een vriend. ga ik morgen gelijk doen.

[Verwijderd]

Ik bedoelde om met cron te kijken of je de gewenste select kon doen, dus connecten met de mysql command line tool, een select doen en wachten op resultaat. Als er na 90 seconden nog geen resultaat is, restart de mysql deamon.

Ik ben zelf ook geen server held, maar services / deamons horen niet zonder waarschuwingen de geest te geven.

[Verwijderd]

Klinkt gewoon alsof er ergens een lock blijft hangen op een tabel of rij, aangezien je zegt dat je met opera alles behalve de betreffende pagina kunt ophalen ... ik zou de mysql-versie controleren bij mysql.com -- misschien bugs in betreffende versie. Idem voor je php-versie. Ik geloof niet dat je expliciet een mysql tabel/rij kunt locken met php, maar ik zou het nog ff controleren op nl.php.net, bij de documentatie over de mysql-api.

[marty]

Verwijderd schreef op 15 oktober 2002 @ 13:33:
Klinkt gewoon alsof er ergens een lock blijft hangen op een tabel of rij, aangezien je zegt dat je met opera alles behalve de betreffende pagina kunt ophalen

maar dat gebeurt ook als je in IE een bugje in de PHP code triggered die een query naar mysql stuurt wat resulteert in een half miljoen rijen. Dan loopt dat proces gewoon tijdelijk ff vast, maar kun je wel via andere browsers (of IE helemaal afsluiten en opnieuw starten)

... ik zou de mysql-versie controleren bij mysql.com -- misschien bugs in betreffende versie. Idem voor je php-versie. Ik geloof niet dat je expliciet een mysql tabel/rij kunt locken met php, maar ik zou het nog ff controleren op nl.php.net, bij de documentatie over de mysql-api.

ik heb wel een lijst kunnen vinden waar ze per versie aangeven wat ze gefixed hebben, helaas staat er niet bij vanaf welke versie de bug zich voordeed.
Er zijn sinds 3.23.36 echter wel flink wat fixes betreffende LOCKS geweest, dus dat zou het inderdaad nog best wel eens kunnen zijn. Het maakt ook wel sense eigenlijk - ik had er zelf nog niet aan gedacht.
(ik gebruik overigens niet expliciet locks in de code/queries)

heb de server logs overigens nog niet in handen...misschien dat ik daar strax ook nog wat nuttige info in vind

edit:
Heb inmiddels de server log gehad en bekeken, maar kan rond het tijdstip helemaal niets vinden. Staat wel erg veel deze error in: (Got an error reading communication packets). maar de laatste error was een uur voordat het gebeurde en de eerste error daarna een paar uur later.
Nouja...ik gooi het voorlopig maar een op een lock die er niet meer van af is gegaan.

[ Voor 0% gewijzigd door marty op 15-10-2002 15:48 . Reden: serverlog bekeken ]