Sommaire 27 Historique des changements MySQL
1.7 Sources d'informations MySQL
1.7.1 Listes de diffusion MySQL
1.7.1.3 Comment rapporter un bogue ou un problème
Notre base de données de bogues est publique, et peut être lue par tous sur le site
http://bugs.mysql.com/ . Si vous vous identifiez sur le système vous serez aussi capable d'envoyer des rapports.
Ecrire un bon rapport de bogue requiert de la patience, et le faire dès le début épargnera votre temps et le notre. Un bon rapport de bogue qui contient un cas de test complet améliorera vos chances de voir le bogue corrigé à la prochaine version. Cette section vous aidera à écrire
correctement un rapport de bogue, de manière à ce que vous ne gaspillez pas votre temps à faire des textes qui ne nous aideront que peu ou pas.
Nous vous recommandons d'utiliser le script mysqlbug
pour générer un rapport de bogue (ou rapporter un problème), dans la mesure du possible. mysqlbug
est situé dans le dossier scripts
de la distribution, ou, pour les distributions binaire, dans le dossier bin
du dossier d'installation de MySQL. Si vous êtes dans l'incapacité d'utiliser mysqlbug
, vous devez tout de même inclure toutes les informations nécessaires listées dans cette section.
Le script mysqlbug
vous aide à générer un rapport en déterminant automatiquement les informations suivantes, mais si quelque chose d'important lui échappe, ajoutez le dans votre message! Lisez cette section avec attention, et assurez vous que toutes les informations décrites ici sont présentes dans votre message.
De préférence, vous devriez tester le problème avec la dernière version de production ou de développement de MySQL. Il doit être facile de reproduire le test avec simplement la commande '
mysql test < script
', appliquée au cas de test, ou en exécutant le script Shell ou Perl inclut dans le rapport.
Tous les bogues postés sur le site de rapports de bogues http://bugs.mysql.com/ seront corrigés ou documentés dans la prochaine version de MySQL. Si seuls, de petits changements sont
nécessaires, nous publierons aussi un patch.
Si vous avez découvert un problème de sécurité critiques avec MySQL, il faut envoyer un email à security@mysql.com .
Si vous avez un rapport de bogue reproductible, envoyez un rapport sur le site
http://bugs.mysql.com/ . Notez que même dans ce cas, il est bon d'utiliser le script mysqlbug
pour rassembler des informations sur votre système. Tous les bogues que nous pourrons reproduire auront de bonnes chances d'être corrigés lors de la prochaine version de MySQL.
Pour signaler d'autres problèmes, utilisez une des listes de diffusion MySQL.
Sachez qu'il est toujours possible de répondre à un message qui contient trop d'informations, alors qu'il est impossible de répondre à un message qui contient trop peu d'informations. Souvent, il est facile d'omettre des faits parce que vous pensez connaître la cause du problème et supposez que ces détails ne sont pas importants. Un bon principe à suivre est : si vous avez un doute à propos de quelque chose, faites nous en part. Il est bien plus rapide et bien moins frustrant d'écrire quelques lignes de plus dans un rapport plutôt que d'être obligé de demander une nouvelle fois et d'attendre une réponse parce que vous avez oublié une partie des informations la première fois.
L'erreur la plus commune est de ne pas indiquer le numéro de la version de MySQL qui est utilisé, ou de ne pas indiquer le système d'exploitation que vous utilisez (y compris le numéro de version de ce système d'exploitation). Ce sont des informations de première importance, et dans 99% des cas, le rapport de bogue est inutilisable sans ces informations. Souvent, nous recevons des questions telles que ``Pourquoi est ce que cela ne fonctionne pas pour moi?''. Puis nous nous apercevons que la fonctionnalités en question n'est même pas programmée dans la version de MySQL utilisée, ou que le bogue décrit est déjà corrigé dans une nouvelle version de MySQL. Parfois aussi, les erreurs sont dépendantes des plates−formes. Dans ce cas, il est presque impossible de les corriger sans savoir quel système d'exploitation et quelle version exacte est utilisée.
Pensez aussi à fournir des informations concernant votre compilateur, si c'est pertinent. Souvent, les développeurs trouvent des bogues dans les compilateurs, et pensent que c'est liés à MySQL. La plupart des compilateurs sont en constant développement, et s'améliorent de version en version. Pour déterminer si votre problème dépend de votre compilateur, nous avons besoin de savoir quel compilateur est utilisé. Notez que les problèmes de compilations sont des bogues, et doivent être traités avec un rapport de bogues.
Il est particulièrement utile de fournir une bonne description du bogue dans le rapport de bogue. Cela peut être un exemple de ce que vous avez fait qui a conduit au problème, ou une description précise. Les meilleurs rapports sont ceux qui incluent un exemple complet permettant de reproduire le bogue. Faire une batterie de tests lorsque vous faites face à un problème de table corrompue . Si un programme produit un message d'erreur, il est très important d'inclure ce message dans votre rapport. Il est préférable que le message soit le message exact, car il est alors possible de le retrouver en utilisant les archives : même la casse doit être respectée. N'essayez jamais de vous rappeler d'un message d'erreur, mais faites plutôt un copier/coller du message complet dans votre
rapport.
Si vous avez un problème avec MyODBC
, essayez de générer un fichier de trace MyODBC
. How to Report MyODBC Problems or Bugs .
Pensez aussi que de nombreux personnes qui liront votre rapport utilisent un formatage de 80 colonnes. Lorsque vous générez votre rapport et vos exemples avec l'outil de ligne de commande, utilisez une largeur de 80 colonnes. Utilisez l'option −−vertical
(ou la fin de commande \G
) pour les affichages qui excèdent une telle largeur (par exemple, avec la commande EXPLAIN SELECT
; voyez l'exemple un peu plus tard dans cette section.
Voici un pense−bête des informations à fournir dans votre rapport :
Le numéro de version de la distribution de MySQL que vous utilisez (par exemple MySQL Version 3.22.22). Vous pouvez connaître cette version en exécutant la commande mysqladmin version
. mysqladmin
est situé dans le dossier bin
de votre distribution MySQL.
•
Le fabricant et le modèle de votre serveur.
•
Le système d'exploitation et la version que vous utilisez. Pour la plupart des systèmes d'exploitation, vous pouvez obtenir cette information en utilisant la commande Unix uname −a
.
•
Parfois, la quantité de mémoire (physique et virtuelle) est important. Si vous hésitez, ajoutez la.
•
Si vous utilisez une version de MySQL sous forme de source, le nom et le numéro de version du compilateur sont nécessaires. Si vous utilisez une version exécutable, le nom de la distribution est important.
•
Si le problème intervient lors de la compilation, incluez le message d'erreur exact et les quelques lignes de contexte autour du code en question dans le fichier où il est situé.
•
Si mysqld
s'est arrêté, il est recommandé d'inclure la requête qui a mené à cet arrêt de mysqld
. Vous pouvez généralement la trouver en exécutant mysqld
en ayant activé les logs. Utilisation des fichiers de log pour trouver d'où viennent les erreurs de mysqld .
•
Si une table ou une base sont liés au problème ajoutez le résultat de la commande mysqldump −−no−data db_name tbl_name1 tbl_name2 ...
. C'est très simple à faire, et c'est un moyen efficace d'obtenir un descriptif de table, qui nous permettra de recréer une situation comparable à la votre.
•
Pour les problèmes liés à la vitesse, ou des problèmes liés à la commande SELECT
, pensez à inclure le résultat de la commande EXPLAIN SELECT ...
, et au moins le nombre de ligne que la commande SELECT
doit produire. Vous devriez aussi inclure le résultat de la commande SHOW CREATE TABLE table_name
pour chaque table impliquée. Plus vous nous fournirez d'informations, plus nous aurons de chance de vous aider efficacement. Par exemple, voici un excellent rapport de bogue (posté avec le script mysqlbug
, et effectivement rédigé en anglais) : Exemple réalisé avec mysql
en ligne de commande (notez l'utilisation de la fin de commande
\G
, pour les résultats qui pourraient dépasser les 80 colonnes de large) :
mysql> SHOW VARIABLES; mysql> SHOW COLUMNS FROM ...\G <output from SHOW COLUMNS> mysql> EXPLAIN SELECT ...\G <output from EXPLAIN> mysql> FLUSH STATUS; mysql> SELECT ...;
<A short version of the output from SELECT, including the time taken to run the query> mysql> SHOW STATUS;
<output from SHOW STATUS>
•
Si un bogue ou un problème survient lors de l'exécution de mysqld
, essayez de fournir un script qui reproduit l'anomalie. Ce script doit inclure tous les fichiers sources nécessaires. Plus votre script reproduira fidèlement votre situation, mieux ce sera. Si vous pouvez réaliser un cas de test postez−le sur le site http://bugs.mysql.com/ pour un traitement prioritaire!
•
Si vous ne pouvez pas fournir de script, fournissez tout au moins le résultat de la commande
mysqladmin variables extended−status processlist
dans votre mail pour fournir des informations sur les performances de votre système.
Si vous ne pouvez pas reproduire votre situation en quelques lignes, ou si une table de test est trop grosse à être envoyée par mail (plus de 10 lignes), exportez vos tables sous forme de fichier avec la commande mysqldump
et créez un fichier README
qui décrit votre problème. Créez une archive compressée de votre fichier en utilisant tar
et gzip
ou zip
, et placez le via
ftp
sur le site de ftp://support.mysql.com/pub/mysql/secret/ . Puis, entrez la description de l'anomalie sur le site http://bugs.mysql.com/ .
•
Si vous pensez que le serveur MySQL fournit des résultats étranges pour une requête, incluez non seulement le résultat, mais aussi votre propre explication sur ce que le résultat devrait être, et un diagnostic de la situation.
•
Lorsque vous donnez un exemple du problème, il est mieux d'utiliser des noms de variables et de tables qui existent dans votre situation, plutôt que d'inventer de nouveaux noms. Le problème peut être lié au noms des variables ou tables que vous utilisez! Ces cas sont rares, mais il vaut mieux éviter les ambiguïtés. Après tout, il est plus facile pour vous de fournir un exemple qui utilise votre situation réelle, et c'est bien mieux pour nous aussi. Si vous avez des données que vous ne souhaitez pas divulguer, vous pouvez utiliser le site ftp
pour les transférer dans le dossier secret ftp://support.mysql.com/pub/mysql/secret/ . Si les données sont vraiment ultra secrètes et que vous ne souhaitez même pas nous les montrer, alors utilisez d'autres noms et données pour votre rapport, mais considérez cela comme un dernier recours.
•
Incluez toutes les options utilisées, si possible. Par exemple, indiquez les options que vous utilisez lors du démarrage de mysqld
, et celle que vous utilisez avec les programmes comme
mysqld
et mysql
, et le script configure
, qui sont souvent primordiaux et pertinents. Ce n'est jamais une mauvaise idée que de les inclure. Si vous utilisez des modules, comme Perl ou PHP, incluez aussi les versions de ces logiciels.
•
Si votre question porte sur le système de droits, incluez le résultat de l'utilitaire mysqlaccess
, celui de mysqladmin reload
et tous les messages d'erreurs que vous obtenez lors de la connexion. Lorsque vous testez votre système de droits, il faut commencer par utiliser la commande
mysqladmin reload version
et de vous connecter avec le programme qui vous pose problème.
mysqlaccess
est situé dans le dossier bin
de votre installation de MySQL.
•
Si vous avez un patch pour un bogue, c'est une excellente chose. Mais ne supposez pas que nous n'avons besoin que du patch, ou même que nous allons l'utiliser, si vous ne fournissez pas les informations nécessaires pour le tester. Nous pourrions trouver des problèmes générés par votre patch, ou bien nous pourrions ne pas le comprendre du tout. Si tel est le cas, nous ne l'utiliserons pas.
Si nous ne pouvons pas vérifier exactement ce pourquoi est fait le patch, nous ne
l'utiliserons pas. Les cas de tests seront utiles ici. Montrez nous que votre patch va générer toutes les situations qui pourraient arriver. Si nous trouvons un cas limite dans lequel votre patche ne fonctionne pas, même si il est rare, il risque d'être inutile.
•
Les diagnostics sur la nature du bogue, la raison de son déclenchement ou les effets de bords sont généralement faux. Même l'équipe MySQL ne peut diagnostiquer sans commencer par utiliser un débogueur pour déterminer la cause véritable.
•
Indiquez dans votre mail que vous avez vérifié le manuel de référence et les archives de courrier, de façon à avoir épuiser les solutions que d'autres avant vous auraient pu trouver.
•
Si vous obtenez un message parse error
, vérifiez votre syntaxe avec attention. Si vous ne pouvez rien y trouvez à redire, il est très probable que votre version de MySQL ne supporte pas encore cette fonctionnalité que vous essayez d'utiliser. Si vous utilisez la version courante de mySQL et que le manuel http://www.mysql.com/doc/ ne couvre pas la syntaxe que vous utilisez, c'est que MySQL ne supporte pas votre syntaxe. Dans ce cas, vos seules options sont d'implémenter vous même la syntaxe ou d'envoyez un message à
•
licensing@mysql.com pour proposer de l'implémenter.
Si le manuel présente la syntaxe que vous utilisez, mais que vous avez une ancienne version du serveur MySQL, il est recommandé de vérifier l'historique d'évolution de MySQL pour savoir quand la syntaxe a été supportée. Dans ce cas, vous avez l'option de mettre à jour votre MySQL avec une version plus récente. Historique de MySQL .
Si vous avez un problème tel que vos données semblent corrompues, ou que vous recevez constamment des erreurs lors d'accès à une table, vous devriez commencer par essayer de réparer votre table avec l'utilitaire de ligne de commande myisamchk
ou les syntaxes SQL CHECK TABLE
et REPAIR TABLE
. Administration de la base .
•
Si vous avez des tables qui se corrompent facilement, il vous faut essayer de trouver quand et pourquoi cela arrive. Dans ce cas, le fichier mysql−data−directory/'hostname'.err
peut contenir des informations pertinentes qu'il est bon d'inclure dans votre rapport de bogues. Le log d'erreurs . Normalement, mysqld
ne doit jamais corrompre une table si il a été interrompu au
milieu d'une mise à jour. Si vous pouvez trouvez la cause de l'arrêt de mysqld
, il est bien plus facile pour nous de fournir un correctif. Comment déterminer ce qui cause problème .
•
Si possible, téléchargez et installez la version la plus récente du serveur MySQL, et vérifiez si cela résout votre problème. Toutes les versions de MySQL sont testées à fond, et doivent fonctionner sans problème. Nous croyons à la compatibilité ascendante, et vous devriez pouvoir passer d'une version à l'autre facilement. Choisir quelle distribution installer .
•
Si vous disposez de l'accès au support client, contactez aussi le support client à
mysql−support@mysql.com , en plus de la liste de rapport de bogues, pour un traitement prioritaire. Pour des informations sur les rapports de bogues avec MyODBC
, voyez How to Report MyODBC Problems or Bugs .
Pour des solutions aux problèmes les plus courants, voyez Problèmes et erreurs communes . Lorsque des solutions vous sont envoyées individuellement et non pas à la liste, il est considéré comme bien vu de rassembler ces réponses et d'en envoyer un résumé sur le liste, de manière à ce que les autres en profitent aussi.