2010-11-15 23 views
1

J'ai eu des problèmes avec une base de données à plusieurs reprises ayant planté des tables. Heureusement, il est assez facile de réparer en réparant la table écrasée, mais ce n'est pas une bonne pratique d'avoir à regarder pour que la table plante (ou que le client me le dise) et de le réparer. Les plantages ont tendance à se produire après qu'une modification a été apportée à la base de données à laquelle le client a accès via un CMS.empêcher les plantages de la table MyISAM mysql

J'ai remarqué la dernière fois que le tableau s'est écrasé qu'il faisait référence à un nombre - quelque chose comme trouvé 57 sur 89; que j'ai ensuite remarqué dans la cardinalité pour la clé primaire. Mettant 2 et 2 ensemble cardinalité googled et trouvé que l'optimisation de la table était en quelque sorte liée et donc je pensais qu'en optimisant la table régulièrement, comme après une mise à jour, il permettrait d'éviter les accidents. Est-ce vrai ou ai-je réussi à obtenir 73 plutôt que 4?

Je peux envoyer des fonctions MYSQL à la base de données lorsque le client effectue des changements via PHP, donc l'aide de cette perspective serait géniale.

Toute autre aide avec des accidents de table serait grandement appréciée.

+1

Les tables InnoDB ne se plantent pas (ou pour être plus exactes, elles se restaurent automatiquement au démarrage du serveur). Êtes-vous sûr que ce ne sont pas MyISAM? – Mchl

+0

whoops, vous avez raison là-dessus. Je regardais un DB complètement différent en écrivant ceci ainsi ai vérifié le mauvais, mouvement muet. – andyface

Répondre

0

est FAUSSE OPTIMIZE table empêchera la table pour s'écraser

en fait, U NE DEVRAIENT PAS terme OPTIMIZE table trop souvent (tableau se verrouillé) bien conçu pour compacter les données gratuites

essayer mysqlcheck -C

ou mysqlcheck -c

+0

merci pour l'info sur l'optimisation.Je n'ai pas mentionné que je cours principalement des choses via PHP donc je cherche une solution qui fonctionne avec cela, de sorte que c'est essentiellement automatisé quand le client fait des changements. – andyface

+0

@ andy-score: est possible en utilisant la syntaxe mysql pure -> http://dev.mysql.com/doc/refman/5.1/en/check-table.html – ajreal

+0

Vu aujourd'hui sur le serveur d'un client: en cours d'exécution 'OPTIMIZE TABLE', la table s'est écrasée ... J'ai dû lancer une 'TABLE DE RÉPARATION 'pour m'en débarrasser. Bien sûr, c'était MyISAM, et j'ai demandé au client d'utiliser InnoDB à la place, comme proposé par @Mchl (et comme je le fais sur mes propres serveurs). – Yvan

0

table MyISAM obtient habituellement corrompu pour les raisons suivantes:

  • Un bug dans MySQL ou les problèmes externes (plantage du système d'exploitation, la mise sous tension vers le bas dur, hors de la mémoire OS kill) qui provoque mysqld pour quitter anormalement
  • Un bug dans le moteur MyISAM
  • Courir deux cas de mysqld sur les mêmes données en même temps
  • dysfonctionnement du matériel

Ainsi, le mieux que vous pouvez faire pour éviter la corruption est d'avoir un bon UPS, exécutez les versions les plus stables d'OS et MySQL, assurez-vous que votre le matériel fonctionne correctement, assurez-vous que vous avez quantité suffisante de RAM (pour éviter que le MOO ne tue, et pour éviter de tenter le diable en général, les bugs sont souvent rencontrés dans des conditions de mémoire insuffisante), et soyez un bon garçon - ne tuez pas mysqld avec le signal 9, et redémarrez L'ancienne instance de mysqld est tombée avant que vous commenciez la nouvelle.

Vous pouvez également prendre des mesures pour faire face à la corruption. Sauvegardez vos données fréquemment et gardez les tables raisonnablement petites pour éviter de longs délais de récupération. L'utilisation d'InnoDB est une autre option qui est en vogue aujourd'hui car elle s'harmonise mieux avec la théorie de base de données enseignée dans les écoles mais elle présente des problèmes propres et peut introduire de nouveaux problèmes si vous essayez de migrer: données dilatoires, performances plus lentes deadlock, corruption de données (style InnoDB), plus complexe - plus susceptible de rencontrer un bug et plus difficile à résoudre, etc.