[Problème] Can't open table - corrupt

[Patrice]

Bonjour.

Toute aide serait la bienvenue pour m'expliquer ce qui est pour moi un mystère...

Mon site (http://www.magicoscircusrouennais.fr ) tourne sous Joomla! 3.3.3 - apparemment sans problème...

Du moins jusqu'à il y a quelques jours où j'ai commencé à ne plus recevoir mon backup quotidien de ma base de données créé par Lazydbbackup.

Lorsque j'ai vérifié ce plugin, il m'affiche "impossible d'instancier la fonction mail".

Je n'ai rien installé - rien désinstallé et je me suis donc posé la question "D'où ça peut venir ?".

Je me suis connecté à mon phpMyAdmin chez OVH et j'ai vérifié ma base de données (sachant que mes connaissances dans le domaine sont des plus limitées...).

En lançant une vérification globale des 87 tables de la base de données, je reçois des messages d'erreur "Can't Open table - corrupt" pour 34 d'entre elles.
Mais si je vérifier les tables une par une, la vérification passe sans soucis aucun problème n'est détecté.

D'où ma question : Est-ce normal que la vérification globale de l'ensemble des tables renvoie des messages d'erreur alors que la vérification individuelle des tables corrompues n'en renvoie aucun ?


Par ailleurs, question subsidiaire... Comme le site fonctionne apparemment normalement, qu'est ce qui pourrait expliquer mon problème de backup avec Lazydbbackup sachant que je reçois sans problème les messages du module de contact du site et seul la sauvegarde de la base de données semble affectée.

J'ai désinstallé Lazydbbackup et l'ai réinstallé : même problème.

J'ai modifié mes paramètres de mail en modifiant la fonction phpmail en smtp : même problème.

Help !

[RobertG]

Re : Can't open table - corrupt

As-tu essayé de faire une sauvegarde de ta base depuis phpMyAdmin ?
Je ne serais pas surpris qu'elle te renvoie aussi une erreur.

[Patrice]

Re : Can't open table - corrupt

Bonjour.

Je viens de faire un essai et ça passe... J'ai réussi à la récupérer sans message d'erreur. 4,84 mégas. J'ai essayé la méthode rapide et ensuite la méthode personnalisée. Aucun soucis pour les deux.

[RobertG]

Re : Can't open table - corrupt

Il y a deux problèmes a priori différents : cette impossibilité d'instancier la fonction mail par LazyDbBackup, et ces tables dites corrompues.
Essaie d'importer ta sauvegarde dans une base vide pour voir si tu as les mêmes messages et désactive l'envoi de la sauvegarde LazyDbBackup par mail pour vérifier si le fichier est bien créé (a priori dans le dossier "media").

[Patrice]

Re : Can't open table - corrupt

Je viens de faire l'essai avec Lazydbbackup en désactivant l'envoi par mail. La sauvegarde a été créée et je viens de la récupérer par ftp... Mais elle fait 7,63 Mo alors que quand je passe par PhpMyAdmin elle ne fait que 4,84 Mo... Étrange.

Sinon, j'ai continué à faire des recherches sur différents forums et j'ai appris un truc... Il ne fait pas passer par l'option "opérations" pour vérifier une table mais par le tableau global de la base en ne cochant que la table à vérifier. On sélectionne "pour la sélectionner" et on choisit l'option voulue.

Je viens de le faire avec une de mes tables apparemment corrompues et voilà ce que cela m'annonce :

Vérifier : ok
Optimiser : la réponse est : Table does not support optimize, doing recreate + analyze instead et ensuite ça indique OK
Analyser : Ok
Réparer : la réponse est : The storage engine for the table doesn't support repair.

Qu'est ce que ça veut dire ?
Elle est corrompue ou pas ?

Pour la sauvegarde à importer dans une base vide... Euh... Là on atteint la limite de mes compétences en la matière... Je la crée où cette base vide ?

[RobertG]

Re : Can't open table - corrupt

C'est probablement parce que phpMyadmin ne peut pas réparer une table InnoDb qu'il y a ce message.
Il est probable que les tables ne soient en fait pas corrompues.

En ce qui concerne la taille de la sauvegarde, si elle est différente (avec le même type de compression) entre phpMyAdmin et LazyDbBackup, c'est peut-être parce que celle faite avec phpMyAdmin ne contient pas autant de tables (il faut cocher la désactivation du contrôle des clés étrangères pour les tables InnoDb, sinon certaines peuvent ne pas être incluses).
A vérifier donc en important dans une base vierge locale ou en décompressant les fichiers pour les comparer.

Au niveau de l'envoi de la sauvegarde par mail, je suis étonné que le système de mail OVH ne puisse pas l'envoyer.
Quelle était la taille des dernières sauvegardes reçues par mail ?

[Patrice]

Re : Can't open table - corrupt

Bon, je suis toujours dans mes problèmes de tables InnoDB corrompues.

Et je continue de m'interroger..

Mon site comporte comporte toujours ses 87 tables et il y en a toujours 34 corrompues - toutes InnoDB.

Ma version Joomla est toujours la 3.3.3 et j'ai contacté OVH mon herbergeur (hébergement mutualisé) pour savoir d'où pouvait venir la corruption et comment réparer les tables corrompues.

Là, j'ai eu une réponse incomplète... Je n'ai eu aucun élément concernant l'origine de cette corruption soudaine mais je soupçonne que ce soit du à des plantages répétés du serveur qui héberge mon site.

Quant à la réparation des tables corrompues, la réponse est, on ne peut pas les réparer sans un risque à l'intégrité du site...

Quelqu'un peut-il m'indiquer si cette réponse est-elle satisfaisante car il semblerait qu'on puisse réparer ce genre de table et même au besoin le convertir en MylSAM...

Par ailleurs, j'ai effectué ce test.
J'ai Xmap qui est installé sur le site. Il fonctionne (enfin non, il ne s'affiche pas sur le site depuis le débit et je ne suis apparemment pas le seul à avoir ce problème, mais ça c'est un autre problème...).

Donc, disais-je avant d'être interrompu par moi-même, Xmap crée (oui c'est mieux que fonctionne) deux tables InnoDB qui sont dsignées comme corrompues selon PhpMyAdmin.

J'ai donc désinstallé Xmap et les deux tables ont bien évidemment été supprimées (quoique "bien évidemment" est de trop, car ça aurait pu ne pas les supprimer...).

J'ai ensuite réinstallé Xmap et je pensais en toute logique que les deux tables ainsi recréées ne seraient plus corrompues.

Que nenni... Si je sélectionne mes 87 tables et que je fais "vérifier", les deux tables Xmap font à nouveau partie des tables corrompues alors même que je n'ai pas encore recréé mon plan de site.

Mais plus étrange, si je ne sélectionne que les deux tables Xmap et que je demande "vérifier" la réponse pour le statut est "OK" - Donc pas de corruption.

Et encore plus étrange, si j'interroge une table par une table les tables soit-disant corrompues, aucune n’apparaît corrompue...

Dites docteur, c'est grave ?

Quelqu'un aurait-il une idée ?

[Patrice]

Re : Can't open table - corrupt

Allez quelques nouvelles supplémentaires.

J'ai recréé la totalité du site en local et réinjecté la base "corrompue". Je mets des guillemets car en faisant une vérification de cette base sous phpMyAdmin en local (Wampserver)... Et là, très étrange, aucune table n’apparaît corrompue... alors que lorsque je fais la même vérification avec la base en ligne sur le serveur d'OVH, plusieurs tables sont corrompues.

Déjà que quand ça marche correctement, c'est un peu compliqué pour moi de tout comprendre, mais là... c'est à y perdre son Latin, sachant que je ne parle pas Latin...

Personne n'a une idée, une suggestion (mise à part celle de choisir un autre hébergeur...) ?

[jisse03]

Re : Can't open table - corrupt

Bonjour,

S'agissant de tables InnoDB, il est possible que les tables "corrompues" ne le soient pas, mais que le "container" InnoDB, surtout s'il n'est pas configuré de manière unitaire (un container par base de données) mais de manière globale (un seul container en mode autogrow pour toutes les bases d'un serveur) ait atteint sa taille limite et ne supporte plus aucune modification. Dans ces cas là, phpMyAdmin affiche un statut "corrupt", alors qu ele statut réel est "full".

Lors de l'interrogation unitaire, le cache de requête ayant moins de résultats à calculer, les tables n'appraissent plus corrompues.

[Patrice]

Re : Can't open table - corrupt

Oups ! On rentre dans un domaine technique qui dépasse de très loin mes connaissances...

Y a-t-il un moyen à mon niveau de déterminer le type de container (unitaire ou global) dépend ma base de données ?
J'ai viens de faire une demande à ce sujet à OVH , mais je suis très critique envers leur support... La qualité des réponses apportées laisse plutôt à désirer.

Et concrètement, quels sont les risques pour le site d'avoir affaire à un container global et qui plus est "full" ?

Depuis la détection du problème en ligne (et de la non existence de ce problème en local...) j'ai procéder à des mises à jours d'extensions - sans problème - à la création de nouveaux articles - sans problème non plus...
J'ai même supprimé certaines tables laissées par des extensions portant désinstallées. Tout semble fonctionner... mais jusqu'à quand ? D'autant que sur le serveur, je suis passé de 30 tables corrompues à 31 sur 82... ce qui fait beaucoup.

Pour info, ma base de données fait 9 mégas en mode non compressé (.sql).

[jisse03]

Re : Can't open table - corrupt

Y a-t-il un moyen à mon niveau de déterminer le type de container (unitaire ou global) dépend ma base de données ?

Il n'y a aucun moyen simple, sauf à pouvoir accéder à l'intégralité des informations MySQL, donc à avoir un accès administratif sur le serveur.

J'ai viens de faire une demande à ce sujet à OVH , mais je suis très critique envers leur support... La qualité des réponses apportées laisse plutôt à désirer.

N'utilisant pas le support OVH, je n'ai aucune idée personnelle sur la qualité de leur service. Mais il est également possible que le personnel du support ne soit pas au courant des subtilités de configuration des engines InnoDB sur les serveurs mutualisés.

Et concrètement, quels sont les risques pour le site d'avoir affaire à un container global et qui plus est "full" ?

Des erreurs 500 sporadiques, l'impossibilité par moments de pouvoir créer un utilisateur ou ajoutyer un menu, article ou autre contenu...

Depuis la détection du problème en ligne (et de la non existence de ce problème en local...) j'ai procéder à des mises à jours d'extensions - sans problème - à la création de nouveaux articles - sans problème non plus...
J'ai même supprimé certaines tables laissées par des extensions portant désinstallées. Tout semble fonctionner... mais jusqu'à quand ? D'autant que sur le serveur, je suis passé de 30 tables corrompues à 31 sur 82... ce qui fait beaucoup.

Si l'export de la base et l'installation locale ne posent aucun problème, celà confirme simplement qu'il s'agit d'un problème de taille de container ou des buffers intermédiaires. Sur les hébergements mutualisés de bas de gamme, ce type de problème est assez fréquent[/QUOTE]

Pour info, ma base de données fait 9 mégas en mode non compressé (.sql).

C'ets une très petite base de données. Tu m'aurais parlé de 250 mégas, là, évidemment...

[Patrice]

Re : Can't open table - corrupt

Voilà ce qu'on appelle une réponse détaillée... très détaillée, et je t'en remercie infiniment.

Pour l'instant je n'ai rien noté en termes d'erreur 500.

De même j'arrive à faire mes articles sans problème.

Quant aux menus, maintenant que le site est opérationnel, je n'ai plus lieu d'en créer de nouveaux, le site n'évoluera probablement plus dans sa structure.

Dernièrement j'ai rajouté deux super utilisateurs pour qu'ils aillent jeter un œil à mes soucis et la création s'est déroulée sans problème.

Pour la base de données, elle comporte 82 tables et dans PhpMyAdmin il est recensé 444 340 lignes et une taille totale de 137,4 Mio (?).
Quand je rapatrie une sauvegarde j'obtiens une taille de 8 mégas et quelques en compression gzip avec LazyDbBack-up alors qu'en passant par un export PhpMyAdmin (en désactivant le contrôle des clés étrangères) je n'ai plus que 1,91 mégas, ce qui n'est pas sans me surprendre...

Le site en lui-même pèse 1,27 giga.

[Patrice]

Re : Can't open table - corrupt

Du nouveau concernant mon problème de tables corrompues qui ne le seraient peut-être pas...
Suite à la réponse deJisse03 j'ai contacté - à nouveau - l'assistance OVH, pour demander si la gestion du conteneur était globale ou unitaire.
Réponse : Les administrateurs veulent savoir pourquoi vous posez cette question...

Ah... Bon, ben j'ai réexpliqué en me basant sur la réponse de Jisse03.

Je viens de recevoir une nouvelle réponse me demandant de communiquer la liste des tables corrompues et qu'un administrateur va travailler dessus...

Mon problème est : est-ce que cela ne va pas faire pire que bien si en fait, le problème ne vient pas des tables mais du conteneur ?

[jisse03]

Re : Can't open table - corrupt

Mon problème est : est-ce que cela ne va pas faire pire que bien si en fait, le problème ne vient pas des tables mais du conteneur ?

Là, sans connaître l'architecture exacte du déploiement des clusters MySQL mutualisés OVH, impossible à savoir

Mais le fait que la même base, réinstallée en local, ne présente aucune anomalie fait bien penser à un problème quelconque de configuration. Savoir exactement lequel sans disposer des logs du serveur relève de la voyance pure.

[Patrice]

Re : Can't open table - corrupt

Jisse03.

Merci de tes précieux conseils. J'ai transmis au support OVH la liste des tables de la BDD avec le résultat d'analyse indiquant les tables corrompues en précisant qu'une analyse en local ne donne aucun message d'erreur. J'espère que cela sera suffisant pour attirer leur attention et éviter de créer un problème supplémentaire.
Je vais faire télécharger sur on disque une sauvegarde complète... Just In Case..

Merci.