Je suis assez nouveau sur MySQL et j'obtiens une erreur assez intéressante sur laquelle je ne trouve aucune aide via google et la recherche stackoverflow.
J'utilise un serveur local de MySQL 5.6.10 sur MacOS 10.8.3 et gère ma base de données via Navicat essentials for MySQL.
L’erreur que j’obtiens, c’est que, après avoir exécuté et géré ma base de données pendant quelques jours/semaines, quelque chose déclenche (il semble incomplet) la suppression de certaines des tables que j’ai créées à l’aide de requêtes de Navicat.
Lorsque j'essaie d'exécuter des requêtes à l'aide de ces tables, Navicat m'avertit que celle-ci n'existe pas. Jusqu'ici tout va bien - voici la bonne partie:
Lorsque j'essaie de CRÉER la table, par exemple nommé "temp", qui était là auparavant, j'obtiens le message d'erreur suivant:
Error : Tablespace for table '`database`.`temp`' exists. Please DISCARD the tablespace before IMPORT.
Cependant, si j'essaie de supprimer la table ou d'essayer de supprimer le tablespace pour cette table, en utilisant
DROP TABLE temp;
ALTER TABLE temp DISCARD TABLESPACE;
Je reçois les messages d'erreur suivants:
Error : Unknown table 'database.temp'
Error : Table 'database.temp' doesn't exist
Cela signifie donc qu'il m'est conseillé de supprimer l'espace table, mais lorsque j'essaie de le faire, la table n'existe pas. Est-il possible qu'il y ait un type de reste de cette table à un endroit différent où la requête DISCARD n'est pas vérifiée? Et est-ce que quelqu'un a une idée de ce qui pourrait déclencher tout ça - complètement au hasard, comme cela semble être?
Comme je l'ai dit, je suis nouveau sur le sujet et je ne connais pas grand-chose. Je soupçonne que le redémarrage de mon ordinateur portable, c’est-à-dire mon serveur MySQL local, ou peut-être les droits d’autorisation de l’utilisateur, y sont pour quelque chose, mais j’émets simplement des hypothèses ici.
Un peu tard ici, mais en général, j'ai constaté ce problème lorsque vous obtenez une erreur 'tablespace full' lors de l'exécution en mode 'innodb_file_per_table'. Sans entrer trop dans les détails (plus ici ), le tablespace du serveur de base de données est défini par le paramètre innodb_data_file_path et est par défaut plutôt petit. Même agrandi, le "tablespace full" peut toujours apparaître avec des requêtes plus volumineuses (par exemple, de nombreux "éléments" non-table sont stockés, des journaux d'annulation, des caches, etc.).
Quoi qu'il en soit, j'ai trouvé que si vous regardez dans le répertoire du système d'exploitation où sont stockés les fichiers par table,/var/lib/mysql par défaut sous OSX,/usr/local/var/mysql avec homebrew iirc, vous trouverez un fichier tablename.ibd orphelin sans son fichier tablename.frm compagnon normal. Si vous déplacez ce fichier .ibd vers un emplacement temporaire sûr (juste pour être sûr), cela devrait résoudre le problème.
$ ls /var/lib/mysql
table1.frm
table1.idb
table2.frm
table2.ibd
table3.idb <- problem table, no table3.frm
table4.frm
table4.idb
$ mkdir /tmp/mysql_orphans
$ mv /var/lib/mysql/table3.ibd /tmp/mysql_orphans/
Une mise en garde cependant, assurez-vous de ce qui est à l'origine du problème, par exemple. longue requête en cours, table verrouillée, etc ... a été effacé. Sinon, vous vous retrouvez avec un autre fichier .ibd orphelin lorsque vous essayez une seconde fois.
Utilisateurs de Xampp et Mamp
A eu la même erreur lors de l'importation d'une base de données (après l'avoir vidée) via MySQL. J'ai trouvé qu'il me restait un fichier tablename.ibd
alors que tous les autres étaient supprimés ..__ Je l'ai supprimé manuellement de mysql/data/database_name
et l'erreur a disparu.
Pour WAMP [Windows 7 Ultimate x64-bit] Utilisateurs:
Je suis d’accord avec ce que DangerDave a dit et je mets donc une réponse à la disposition de Utilisateurs de WAMP .
Remarque: Tout d’abord, vous devez accéder à votre dossier ..\WAMP\Bin\MySQL\MySQL [Votre version de MySQL]\Data .
Maintenant, vous verrez les dossiers de toutes vos bases de données
[Your offending MySQL table name].frm
, mais plutôt un fichier [Your offending MySQL table name].ibd
[Your offending MySQL table name].ibd
Si vous obtenez le .idb
recréé après l'avoir supprimé, lisez cette réponse.
ça a fonctionné avec moi. J'avais le fichier .idb
sans le .frm
correspondant et chaque fois que je supprime le fichier .idb
, la base de données le recrée de nouveau. et j'ai trouvé la solution en une ligne dans mysql documentation (la partie Tablespace Is Not Exist)
1- Créez un fichier .frm correspondant dans un autre répertoire de base de données et copiez-le dans le répertoire de base de données où se trouve la table Orphan.
2- Émettre DROP TABLE pour la table d'origine. Cela devrait permettre de supprimer la table et InnoDB devrait imprimer un avertissement au journal des erreurs indiquant que le fichier .ibd était manquant.
J'ai copié un autre fichier table .frm
et l'ai nommé comme ma table manquante, puis j'ai lancé une requête de suppression de table normale. et voalla cela a fonctionné et la table est abandonnée normalement!
_ {mon système est xampp sous Windows MariaDB v 10.1.8} _
Dans mon cas, la seule solution de travail était:
bad_table
ENGINE = MyISAM ...bad_table
J'ai eu la même erreur en l'exécutant sur wampserver en essayant de créer une table d'utilisateurs. J'ai trouvé un fichier users.ibd et après avoir supprimé ce fichier, j'ai à nouveau exécuté la commande migrate et cela a fonctionné. Le fichier sur ma machine Windows se trouvait dans wamp/bin/mysql/mysql5.6.12/data/myproject.
Solution
Cependant, l’option la plus simple est la suivante: redémarrez mysql, puis effectuez les quatre étapes énumérées au début de la publication. De cette façon, l'ID de tablespace sur le dictionnaire de données et le fichier correspondent; ainsi l'importation du tablespace a réussi.
Cela peut vous donner une plus grande confiance dans le traitement de certains "acquis" d'InnoDB pendant le processus de récupération ou même de transferts de fichiers.
Voici les étapes de la solution:
Cette erreur se produit lorsque vous suspendez certaines fonctions. C'est comme si vous exécutiez la requête ci-dessous avec une clé étrangère incorrecte.
set foreign_key_checks=0
Suppression/Déplacement tablename.ibd ne fonctionnait pas pour moi.
Comment je l'ai résolu
Puisque je voulais supprimer la table corrompue et non existante, j'ai pris une sauvegarde des autres tables en allant dans phpmyadmin-> base de données-> exporter> tables sélectionnées à sauvegarder-> exporter (au format .sql).
Après cela, j'ai sélectionné l'icône de la base de données à côté du nom de la base de données, puis je l'ai supprimée. Créé une nouvelle base de données. Sélectionnez votre nouvelle base de données -> Importer -> Sélectionnez le fichier que vous avez téléchargé précédemment -> Cliquez sur Importer. Maintenant, j'ai mes anciennes tables de travail et je supprime la table corrompue. Maintenant, je viens de créer la table qui lançait l'erreur.
J'ai probablement eu une sauvegarde antérieure de la table corrompue.
Si vous avez un autre serveur avec une bonne version de la même table, vous pouvez en faire une copie (copie_table), transférez la copie_table au serveur posant problème. Supprimez ensuite la table problématique et renommez table_copy en table.
A eu ce problème plusieurs fois. Si vous avez une base de données volumineuse et que vous souhaitez éviter la sauvegarde/restauration (avec la table manquante ajoutée), essayez plusieurs fois:
DROP TABLE my_table;
ALTER TABLE my_table DISCARD TABLESPACE;
-et-
rm my_table.ibd (orphelin sans my_table.frm correspondant) situé dans le répertoire/var/lib/mysql/my_db /
-et alors-
CREATE TABLE SI PAS EXISTS my_table
(...)
Avait exactement le même problème; Je brasserai ajouté [email protected]
(après avoir déjà eu 5.5).
Les valeurs de brassage par défaut pour 5.6 sont innodb_file_per_table=1
alors que dans 5.5 elles sont innodb_file_per_table=0
.
Votre fichier ibdata1
existant (les données combinées innodb) contiendra toujours des références aux tables que vous essayez de créer/supprimer. Modifiez le code innodb_file_per_table
à 0 ou supprimez le fichier de données ibdata1 ( toutes vos données seront perdues. Assurez-vous donc de le copier au préalable ou utilisez déjà un fichier .sql ).
L'autre brasseur [email protected]
default qui m'a mordu était l'absence de port. Le réseau utilisait donc des sockets unix par défaut, et le client mysql continuait à signaler:
ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32
J'ai ajouté <string>--port=3306</string>
au tableau .plist
, mais vous pouvez aussi spécifier port=3306
dans votre my.cnf
Exécutez brew services stop [email protected]
apportez vos modifications puis brew services start [email protected]
C’est exactement ce que j’ai fait dans mariadb 10.2.16 sur Fedora quand j’avais un tableau qui montrait exactement les mêmes erreurs dans le fichier journal, je suppose ...
2018-07-11 9:43:58 140323764213504 [Note] InnoDB: The file './database_name/innodb_table.ibd' already exists though the corresponding table did not exist in the InnoDB data dictionary. You can resolve the problem by removing the file.
2018-07-11 9:44:29 140323764213504 [Warning] InnoDB: Tablespace 'database_name/innodb_table' exists in the cache with id 2836 != 2918
votre kilométrage et les erreurs peuvent varier, mais le principal, je suppose est
...already exists though the corresponding table did not exist in the InnoDB data dictionary...
avec drop table ne fonctionne pas aussi bien que alter table ...
MariaDB [database_name]> drop table innodb_table;
ERROR 1051 (42S02): Unknown table 'database_name.innodb_table'
MariaDB [database_name]> alter table innodb_table discard tablespace;
ERROR 1146 (42S02): Table 'database_name.innodb_table' doesn't exist
la création de la table échoue aussi comme ceci:
MariaDB [database_name]> create table innodb_table(`id` int(10) unsigned NOT NULL);
ERROR 1813 (HY000): Tablespace for table '`database_name`.`innodb_table`' exists. Please DISCARD the tablespace before IMPORT
afin de résoudre ce problème, ce que j'ai fait était d'abord
create table innodb_table2(`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.07 sec)
puis dans le répertoire/var/lib/mysql/nom_bdd, j’ai fait ce qui suit en tant que root, accusant réception du remplacement de innodb_table.ibd, ce qui nous a causé
cp innodb_table2.frm innodb_table.frm
cp innodb_table2.ibd innodb_table.ibd
chown mysql:mysql innodb_table.frm innodb_table.ibd
chmod 660 innodb_table.frm innodb_table.ibd
systemctl restart mariadb
puis retour dans la console mysql j'ai émis une commande de suppression réussie sur les deux tables
MariaDB [database_name]> drop table innodb_table;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 8
Current database: database_name
Query OK, 0 rows affected (0.08 sec)
MariaDB [database_name]> drop table innodb_table2;
Query OK, 0 rows affected (0.25 sec)
et tout est maintenant tout carré et je peux recréer la table unique ...
MariaDB [database_name]> create table innodb_table (`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.08 sec)
Essayer de supprimer le tablespace peut vous donner d'autres erreurs. Pour moi, j'ai l'erreur suivante:
DROP TABLESPACE `tablename`
Error Code: 1478. Table storage engine 'InnoDB' does not support the create option 'TABLESPACE or LOGFILE GROUP'
Ma solution était de supprimer la base de données. Cela supprimera les espaces de table associés et vous permettra de créer à nouveau les tables.
Pour moi, cela m'a aidé d'aller dans le répertoire MYSQL DATA sous/var/lib/mysql/{nom_bdd} (linux) et de supprimer {nom_table} .ibd fichier qui était identique au nom du dossier.
Vous pouvez exécuter la requête suivante en tant qu'utilisateur root mysql
drop tablespace `tableName`
Je supprime uniquement mon ancienne base de données située dans mon hôte local directement à partir de wamp, arrêtez tous les services, accédez à wamp/bin/mysql/mysql [version]/data et j'ai trouvé la base de données avec problemas, je la supprime et je relance tous les services créer à nouveau votre base de données et c'est fait, vous pouvez maintenant importer vos tables,
La seule façon dont cela a fonctionné pour moi était: