Discussion :

[bigsister]

Salut à tous,

Je suis sous MySQL 5.0, j'ai ce message environ une fois par jour :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MYSQL_ERROR=Table 'matable' is marked as crashed and should be repaired

Un petit "Repair table" et ça repart mais c'est génant car cela empêche les backups ou crashe certaines requêtes de selection...

Ca arrive sur mes tables les plus grosses et les plus utilisées...

[bigsister]

re-up Mon pb n'est toujours pas résolu et c'est très embêtant.
J'ai fais de nombreuses recherches mais les solutions ne m'aident pas vraiment. Pourtant apparement je ne suis pas le seul à rencontrer ce problème ...

Vraiment personne ?

[Antoun]

Quel est le moteur de stockage de ta table (je pose la question à destination d'autres contributeurs, car perso je n'ai aucune idée de ce qui peut se passer ) ?

[bigsister]

salut Antoun,

Enfin un début de réponse merci !
C'est du MyIsam, sous Gentoo et une machine récente.

Voici une partie de mon fichier de conf si ça peut aider (et si ça vient de là) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
key_buffer                     = 16M
max_allowed_packet             = 1M
table_cache                 = 64
sort_buffer_size             = 512K
net_buffer_length             = 8K
read_buffer_size             = 256K
read_rnd_buffer_size         = 512K
myisam_sort_buffer_size     = 8M
 
skip-innodb
 
[mysqldump]
quick
max_allowed_packet             = 16M
 
[mysql]
# uncomment the next directive if you are not familiar with SQL
#safe-updates
 
[isamchk]
key_buffer                     = 20M
sort_buffer_size             = 20M
read_buffer                 = 2M
write_buffer                 = 2M
 
[myisamchk]
key_buffer                     = 20M
sort_buffer_size             = 20M
read_buffer                 = 2M
write_buffer                 = 2M
 
[mysqlhotcopy]
interactive-timeout

[Antoun]

Je t'invite à te pencher sur la doc MySQL, chapitre 14.1 sur MyISAM. Les causes de corruption sont notamment :

1. The mysqld process is killed in the middle of a write.
   
2. An unexpected computer shutdown occurs (for example, the computer is turned off).
   
3. Hardware failures.
   
4. You are using an external program (such as myisamchk) to modify a table that is being modified by the server at the same time.
   
5. A software bug in the MySQL or MyISAM code

[bigsister]

Merci pour la petite recherche.
Les seules possibilité pour nous dans cette liste sont donc éventuellement 1 et 5.
Si c'est 1, Est-ce que ce pourrait être le résultat d'un timeout mysql suite à une requête trop longue à l'execution ?

[Antoun]

Seulement si c'est une requête d'écriture (INSERT, UPDATE, DELETE...). Si c'est juste un SELECT, ça ne doit pas poser de problème.

Quant au 3), il n'est jamais à exclure. Les tables MyISAM sont des fichiers, ils peuvent être corrompus comme tous les fichiers.

[bigsister]

Oui mais bizarre que ça arrive sur 3 tables différentes, statistiquement ça fait beaucoup... à moins qu'il y ait un bug (?) dans mysql qui supporte mal mes "grosses" tables. Ca va être "compliqué" pour moi de copier les tables à chaud pour générer un nouveau fichier, mais c'est à tester en effet.

J'ai mon fichier bin-log .00001 qui fait +de 800 méga. Est-ce que ce ne serais pas ça la source du problème ? Si oui comment faire pour le forcer à passer à .000002 ?

[Antoun]

Je n'en ai aucune idée. RTFM !

[bigsister]

je fais que ça de lire ce p... de manuel Ils disent que ça peut être un problème de key cache, un bug, etc etc... bref c'est pas simple. Je vais essayer d'upgrader ma version on verra bien.
Merci quand même en tout cas. Je laisse le thread ouvert au cas une autre âme charitable passait par là.

[Antoun]

J'ai mon fichier bin-log .00001 qui fait +de 800 méga. Est-ce que ce ne serais pas ça la source du problème ? Si oui comment faire pour le forcer à passer à .000002 ?

cf chap 5.11.3. Tu peux le forcer à passer à .000002 en redémarrant mysqld, en faisant un FLUSH LOGS, ou bien en baissant la taille du max_binlog_size.

[bigsister]

ok autant pour moi. La taille par défaut du bin-log est de 1 Go, donc à priori c'est normal

[Antoun]

normal, ça ne veut pas dire que ça ne pose pas de pb... fais un petit FLUSH pour voir, ça ne feras pas de mal.

Sinon, au passage, tu as une option myisam-recover dans le my.ini, pour faire automatiquement le REPAIR TABLE... mais ça masquera ton pb plus que ça ne le résoudra.

[overider]

salut big sister.

Un problème de droit peut parfois provoquer ce genre de chose. Regardes le propriétaire et les droits des fichier myi, myd et frm pour ces tables marqués comme crashé.

[bigsister]

Merci de vos réponses. Grâce à vous j'avance un peu !

normal, ça ne veut pas dire que ça ne pose pas de pb... fais un petit FLUSH pour voir, ça ne feras pas de mal.

Sinon, au passage, tu as une option myisam-recover dans le my.ini, pour faire automatiquement le REPAIR TABLE... mais ça masquera ton pb plus que ça ne le résoudra.

-> En fait je garde ce fichier binaire car je compte mettre en place la réplication. Donc je suis pas trop chaud pour le vider. En revanche je vais suivre ton conseil afin que les prochains fichiers soient moins gros.
-> myisam-recover : Justement j'avais envisagé de faire ça avec PHP, merci tu m'as évité de réinventer la roue ! Néanmoins si je n'ai pas mis en place ce système c'est pour 2 raisons : Celle que tu cites et également la peur que des repair table non contrôlés (à n'importe quel moment) fassent crasher mon serveur en entier. Mais je crois qu'en attendant je vais devoir y passer...

Un problème de droit peut parfois provoquer ce genre de chose

-> Non. Je viens de vérifier au cas où mais je pense que s'il y en avait un problème à ce niveau là c'est toute ma table qui ne serait jamais disponible.

[bigsister]

Finalement, mon serveur a été patché (gentoo 64 bits) par mon fournisseur... Et là plus de problèmes