18.1 Que faire si MySQL plante constamment?

Toutes les versions de MySQL sont testées sur de nombreuses plates-formes avant d'être livrées. Cela n'assure pas qu'il n'y ait aucune erreur dans MySQL, mais si elles existent, elles sont rares et très difficiles à trouver. Si vous avez un problème, il nous sera toujours utile que vous fassiez un bilan complet de votre système, et cela vous permettra aussi de résoudre plus sûrement votre problème.

En premier lieu, il faut savoir si le problème provient de votre démon mysqld ou de votre client. Si vous exécutez la commande mysqladmin version , vous pourrez savoir le temps de service de votre serveur mysqld. Si mysqld a terminé son service inopinément, vous en trouverez la raison dans le fichier ``mysql-data-directory/'hostname'.err''.

Etant donné qu'il est très difficile de savoir pourquoi le serveur plante, commencez par vérifier si ce qui plante chez d'autres, plante aussi pour vous. Vous pouvez ainsi tester ce qui suit :@:

• Arrêtez votre démon mysqld avec mysqladmin shutdown, puis lancez isamchk --silent --force */*.ISM sur toutes les tables. Enfin, relancez le démon mysqld. Ceci vous assurera que le serveur est en état de marche. Reportez vous à la section Maintenance.
• Utilisez mysqld --log pour accéder à l'historique :@: vous pourrez ainsi savoir si le serveur s'arrête après une requête particulière. Près de 95% des bugs interviennent après la même requête !Généralement, c'est une des dernières requête du fichier d'historique, juste avant les lignes de redémarrage de MySQL. Vous pouvez vérifier ceci avec la séquence suivante :
  • Arrêtez le serveur MySQL (avec mysqladmin shutdown)
  • Make a backup of files in the MySQL database directory.
  • Vérifiez les toutes tables avec isamchk -s */*.ISM. Réparez les tables corrompues avec isamchk -r chemin-de-la-table.ISM.
  • Effacez (ou déplacez) les anciens fichiers d'historiques du dossier de donnéesde MySQL.
  • Redémarrez le serveur avec safe_mysql --log.
  • Si mysqld s'interromps, vous pourrez exécuter mysql < mysql-log-file pour recherche une éventuelle requête rebelle. Vous pouvez aussi mettre le fichier d'historique dans un autre dossier que le dossier par défaut, en lancant MySQL avec les options safe_mysqld --data=path-to-backup-directory.
• Avez vous essayé les benchmarks ? Elles testent MySQL dans de nombreux domaines. Vous pouvez aussi ajoutez des lignes de codes qui vont simuler votre application! Les benchmarks sont situées dans le dossier ``bench'' de la distribution, ou, pour les distributions binaire, dans le dossier ``sql-bench'' du dossier d'installation MySQL.
• Essayez fork_test.pl et fork2_test.pl.
• Vérifiez le fichier ``mysql-data-directory/'hostname'.err'' :@: il contient peut être les erreurs.
• Si vous configurez MySQL en mode debuggage, il vous sera plus facile de repérer des erreurs lorsqu'un problème se présentera. Reconfigurez MySQL avec l'option --with-debug puis recompilez. G.1 Debugguer un serveur MySQL.
• La configuration en mode debug de MySQL force le mode d'allocation sécurisé :@: cela met en lumière des erreurs, et fourni un affichage plus important sur le détails des opérations.
• Avez vous appliqué les derniers patchs de votre OS ?
• Utiliser l'option --skip-locking de mysqld. Sur certains systèmes, le gestionnaire lockd de verrous ne fonctionne par correctement. Cette option (--skip-locking) force mysqld à ne pas l'utiliser. (Cela implique que vous ne pourrez pas lancer 2 serveurs mysqld sur les mêmes données, et que vous devrez être très prudent lors de l'utilsiation de isamchk, mais ce peut être une option instructive.).
• Avez vous essayé la commande mysqladmin -u root processlist lorsque mysqld semble fonctionner, mais ne pas répondre ? Parfois, mysqld est dans le comas, même si il ne semble pas l'être. Le problème peut provenir du fait que toutes les connexions sont prises, ou bien d'un problème interne. mysqladmin processlist est toujours utilisable, même en cas de surcharge de connexions, et peut fournir des informations très utiles, comme le nombre de connexions et leur statut.
• Lancez la commande mysqladmin -i 5 status dans une nouvelle console, pour avoir des statistiques en temps réel.
• Essayez la combinaison suivante :@:

1. Lancez mysqld à partir de gdb (ou d'un autre debuggeur).
2. Exécutez vos scripts de tests.
3. Utilisez la commande back (ou backtrace dans votre debuggeur) lorsque le dump de mysqld est généré.

• Essayez de simuler votre application avec un script Perl pour forcer MySQL à crasher ou faire des erreurs.
• Ou enfin, envoyer un rapport d'erreur. 2.3 Comment rapporter des bugs et des problèmes. Mais, soyez encore plus détaillé que d'habitude. Etant donné que MySQL fonctionne parfaitement pour de nombreuses personnes, le crash peut provenir d'une caractéristique de votre ordinateur. (par exemple, une erreur due à un système de librairies spécifique).
• Si vous avez un problème avec les tables à lignes de taille variable, et que vous n'utilisez pas de colonne de type BLOB ou TEXT (et seulement des VARCHAR) vous pouvez essayer de remplacer tous les types VARCHAR par CHAR avec ALTER TABLE. Cela va forcer MySQL à utiliser des lignes à taille fixe. Les lignes à taille fixe prennent un peu plus de place, mais sont beaucoup moins sujette à dégradation. Le gestionnaire de ligne de taille variable a été utilisé à TCX (NDT :@: qui a concu MySQL) depuis 3 ans au moins sans aucun problème, mais, par nature, les lignes à taille variables sont plus délicates.