Tables InnoDB <<< |
Solutions pour le dictionnaire de données InnoDB | Tables InnoDB >>> |
16.18 Résolution de problèmes avec InnoDB 16 Tables InnoDB Manuel de Référence MySQL 4.1 : Version Française ->Solutions pour le dictionnaire de données InnoDB |
16.18.1 Solutions pour le dictionnaire de données InnoDB
Un problème spécifique avec les tables est que le serveur MySQL garde les données dans un dictionnaire de données .frm , qu'il stocke dans le dossier de base de données, alors que InnoDB stocke aussi les informations dans son propre dossier de données dans l'espace de tables. Si vous déplacez le fichier .frm , ou si vous utilisez DROP DATABASE en MySQL versions 3.23.44 et plus anciennes, ou si le serveur crashe au milieu d'une opération dans le dictionnaire de données, le fichier .frm peut être déconnecté du dictionnaire de données interne InnoDB . Un symptôme de ce déphasage est que les commandes CREATE TABLE échouent. Si cela arrive, vous devez lire le fichier de log d'erreurs. Si le fichier de log dit que la table existe déjà dans le dictionnaire interne d' InnoDB , vous avez un fichier de table orphelin dans l'espace de table InnoDB , qui n'a plus de fichier .frm correspondant. Le message d'erreur ressemble à ceci :
Si MyQSL crashe au milieu d'une opération ALTER TABLE , vous pouvez vous retrouver avec un fichier temporaire de table, orphelin, dans le code InnoDB . Avec innodb_table_monitor vous pouvez voir une table dont le nom est #sql... , mais comme MySQL ne vous permet pas d'accéder à une table avec un tel nom vous ne pouvez ni l'effacer, ni la détruire. La solution est d'utiliser un mécanisme spécial, disponible depuis MySQL 3.23.48. Lorsque vous avez une table orpheline #sql_id dans un espace de table, vous pouvez faire que InnoDB le renomme en rsql_id_recover_innodb_tmp_table avec la commande :
|
<< | Solutions pour le dictionnaire de données InnoDB | >> |
Tables InnoDB | Résolution de problèmes avec InnoDB | Tables InnoDB |