Erreur: l'espace disque logique pour la table xxx existe. Veuillez REJETER le tablespace avant IMPORT

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'exécute un serveur local de MySQL 5.6.10 sur MacOS 10.8.3 et gère ma base de données via Navicat essentials pour MySQL.

L'erreur que j'obtiens est qu'après avoir exécuté et géré ma base de données très bien pendant quelques jours / semaines, quelque chose déclenche (cela semble incomplet) supprimer certaines des tables que j'ai créées à l'aide de requêtes depuis Navicat.

Lorsque j'essaye d'exécuter des requêtes à l'aide de ces tables, Navicat me prévient alors que la table particulière n'existe pas. Jusqu'ici tout va bien - voici la bonne partie:

Quand j'essaye de CRÉER la table, par exemple nommée "temp", qui était auparavant là, 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 de supprimer l'espace de table de 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 me est conseillé de supprimer l'espace table, mais lorsque j'essaye de le faire, la table n'existe pas. Est-il possible qu'il existe 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 cela - complètement au hasard comme il semble?

Comme je l'ai dit, je suis nouveau sur le sujet et à peu près ignorant. Je soupçonne que le redémarrage de mon ordinateur portable, c'est-à-dire la réinitialisation de mon serveur MySQL local, ou peut-être que les droits de permission des utilisateurs pourraient avoir à voir avec cela, mais je fais juste l'hypothèse ici.

Un peu tard ici, mais en général, j'ai vu ce problème se produire 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 par défaut est plutôt petit. Même agrandi, le «tablespace plein» peut toujours se produire avec des requêtes plus volumineuses et autres (beaucoup de «trucs» non-table sont stockés là-dedans, annulent les journaux, les caches, etc.).

Quoi qu'il en soit, j'ai trouvé que si vous regardez dans le répertoire du système d'exploitation où les fichiers par table sont stockés, / var / lib / mysql par défaut sur OSX, / usr / local / var / mysql avec homebrew iirc, vous trouverez un fichier nomtable.ibd orphelin sans son fichier compagnon normal nomtable.frm. 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 que ce qui cause le problème à l'origine, par exemple une longue requête, une table verrouillée, etc. a été effacé. Sinon, vous vous retrouvez avec un autre fichier .ibd orphelin lorsque vous essayez une deuxième fois.

Utilisateurs Xampp et Mamp

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 constaté qu'il me restait un tablename.ibdfichier tandis que tous les autres étaient supprimés. Je l'ai supprimé manuellement mysql/data/database_nameet l'erreur a disparu.

Pour les utilisateurs de WAMP [Windows 7 Ultimate x64 bits]:

Je suis d'accord avec ce que DangerDave a dit et je mets donc une réponse à la disposition des utilisateurs de WAMP .

Remarque: Tout d'abord, vous devez aller dans votre dossier .. \ WAMP \ Bin \ MySQL \ MySQL [Votre version MySQL] \ Data .

Maintenant, vous verrez les dossiers de toutes vos bases de données

• Double-cliquez sur le dossier de la base de données contenant la table incriminée pour l'ouvrir
• Il ne devrait pas y avoir de fichier [Your offending MySQL table name].frm, mais plutôt un fichier[Your offending MySQL table name].ibd
• Supprimer le [Your offending MySQL table name].ibd
• Ensuite, supprimez-le également de la corbeille
• Ensuite, exécutez votre requête MySQL sur la base de données et vous avez terminé

Si vous obtenez le .idbrecréé après l'avoir supprimé, lisez cette réponse.

Voilà comment cela a fonctionné avec moi. J'ai eu le .idbfichier sans sa correspondance .frmet chaque fois que je supprime le .idbfichier, la base de données le recrée à nouveau. et j'ai trouvé la solution en une seule ligne dans la documentation MySQL (la partie Tablespace n'existe pas )

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 orpheline.

2- Émettez DROP TABLE pour la table d'origine. Cela devrait réussir à supprimer la table et InnoDB devrait afficher un avertissement dans le journal des erreurs indiquant que le fichier .ibd était manquant.

J'ai copié un autre .frmfichier de table et le nommez comme ma table manquante, puis effectuez une requête de table de dépôt normale et le tour est joué, cela a fonctionné et la table est supprimée normalement!

mon système est XAMPP sur windows MariaDB v 10.1.8

Dans mon cas, la seule solution de travail était:

1. CREATE TABLE bad_tableENGINE = MyISAM ...
2. rm bad_table.ibd
3. DROP TABLE bad_table

C'est exactement ce que j'ai fait dans mariadb 10.2.16 sur fedora quand j'avais une table 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 vos erreurs peuvent varier, mais je suppose que le principal est

...already exists though the corresponding table did not exist in the InnoDB data dictionary...

avec la table de dépôt ne fonctionne pas aussi bien que modifier la 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

create table échoue également 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

pour 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 / database_name, j'ai fait ce qui suit en tant que root en reconnaissant l'écrasement de innodb_table.ibd nous causant des problèmes

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

puis de retour dans la console mysql, j'ai émis une commande drop 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 une seule table ...

MariaDB [database_name]> create table  innodb_table (`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.08 sec)

EDIT: j'allais ajouter un

restorecon -Rv /var/lib/mysql/database_name 

après la copie de la base de données pour obtenir tous les contextes selinux tels qu'ils devraient être, même si nous les supprimons de la base de données presque immédiatement, mais à titre d'alternative, vous pouvez simplement ajouter l'option --archive ou -a aux deux cp commandes, donc oui en fait l'option d'archivage raccourcit ceci:

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
restorecon -Rv /var/lib/mysql/database_name
systemctl restart mariadb

à ce qui suit que je pense est meilleur et il conserve le contexte selinux qui est défini pour la table déjà créée.

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

J'ai remplacé la liste de commandes plus longue ci-dessus par la liste plus courte qui pourrait encore être raccourcie avec un *

Dans mon cas:

Supprimez d'abord tableName.ibddans votre répertoire de base de données de Mysql et deuxième exécution:

ALTER TABLE tableName DISCARD TABLESPACE;
DROP TABLE tableName;

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 exécuté à nouveau 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 mêmes étapes comme suit:

1) created a dummy table in the database;
2) discarded its tablespace;
3) moved the .ibd file into the database folder on the system;
4) attached the tablespace back to the table

De cette façon, l'identifiant du tablespace sur le dictionnaire de données et le fichier correspondaient; ainsi l'importation du tablespace a réussi.

Cela peut vous donner une plus grande confiance dans le traitement de certains des «pièges» d'InnoDB pendant le processus de récupération ou même les transferts de fichiers.

réf

Voici les étapes de la solution:

1. sauvegarder votre base de données (structure avec option de dépôt et données)
2. arrêter le service du moteur mysql
3. supprimer manuellement le répertoire de la base de données depuis mysql / data
4. démarrer le moteur mysql
5. créer une nouvelle base de données avec un nom différent de votre base de données corrompue
6. créer une table unique avec le nom de la table corrompue dans la nouvelle base de données (c'est le secret). et il est préférable de créer la table avec exactement la même structure.
7. renommer la base de données en l'ancienne base de données corrompue
8. restaurez votre sauvegarde et votre table fonctionnera correctement.

Eu ce problème plusieurs fois. Si vous avez une base de données volumineuse et que vous souhaitez éviter la sauvegarde / restauration (avec une table manquante ajoutée), essayez plusieurs fois d'avant en arrière:

DROP TABLE ma_table;

ALTER TABLE ma_table DISCARD TABLESPACE;

-et-

rm my_table.ibd (orphelin sans ma_table.frm correspondant) situé dans le répertoire / var / lib / mysql / my_db /

-puis-

CRÉER UN TABLEAU S'IL N'EXISTE PAS my_table(...)

Supprimer / déplacer tablename.ibd n'a certainement pas fonctionné pour moi.

Comment je l'ai résolu

Puisque j'allais supprimer la table corrompue et inexistante, j'ai pris une sauvegarde des autres tables en allant à phpmyadmin-> base de données-> exportation-> tables sélectionnées à sauvegarder-> exportation (comme .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éation d'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é plus tôt-> cliquez sur importer. Maintenant, j'ai mes anciennes tables de travail et j'ai supprimé la table corrompue. Maintenant, je crée juste la table qui lançait l'erreur.

J'avais probablement une sauvegarde antérieure de la table corrompue.

Cette erreur se produit lorsque vous suspendez certaines fonctions. Comme exécuter la requête ci-dessous avec une clé étrangère incorrecte.

set foreign_key_checks=0

Avait exactement le même problème; Je brasserais ajouté mysql@5.6(après avoir précédemment 5,5).

Les valeurs par défaut pour 5,6 sont innodb_file_per_table=1alors que pour 5,5 elles sontinnodb_file_per_table=0 .

Votre ibdata1fichier existant (les données innodb combinées) aura toujours des références aux tables que vous essayez de créer / supprimer. Soit innodb_file_per_tablerevenir à 0, soit supprimer le fichier de données ibdata1 ( cela vous fera perdre toutes vos données, alors assurez-vous que vous le mysqldumpez d'abord ou que vous avez déjà un vidage .sql ).

L'autre mysql@5.6défaut de brassage qui m'a mordu était le manque de port, donc la mise en réseau était par défaut sur les sockets unix, et le client mysql continuait à rapporter:

ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32

J'ai ajouté <string>--port=3306</string>au .plisttableau, mais vous pouvez également spécifierport=3306 dans votremy.cnf

Exécutez brew services stop mysql@5.6vos modifications puisbrew services start mysql@5.6

Essayer de supprimer le tablespace peut vous donner d'autres erreurs. Pour moi, j'ai eu 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 tous les tablespaces associés et vous permettra de créer à nouveau les tables.

Si vous avez un autre serveur avec une bonne version de la même table, vous pouvez faire une copie (table_copy), transférer la table_copy vers le serveur problématique. Supprimez ensuite la table de problème et renommez table_copy en table.

Pour moi, cela m'a aidé à aller dans le répertoire MYSQL DATA sous / var / lib / mysql / {nom_base} (linux) et à déposer le fichier {nom_table} .ibd qui était le même que le nom du dossier.

Je ne supprime que mon ancienne base de données située dans mon hôte local directement depuis wamp, arrêtez tous les services, allez dans wamp / bin / mysql / mysql [version] / data et j'ai trouvé la base de données avec problemas, je la supprime et redémarre wamp tous les services, recréez votre base de données et c'est fait, maintenant vous pouvez importer vos tables,

La façon dont j'ai trouvé pour "résoudre" ce problème est assez ennuyeuse, mais il existe un script qui le gère.

Essentiellement, vous avez besoin que les fichiers ibdata1et ib_logfile*disparaissent (ils contiennent les mappages de clés étrangères, entre autres). Le seul moyen sûr de le faire est d'exporter toutes vos bases de données, d'arrêter mysql, de supprimer les fichiers, de démarrer mysql, puis d'importer les fichiers.

Le script qui aide à résoudre ce problème est https://github.com/uberhacker/shrink-ibdata1 , même si l'objectif déclaré de ce script est différent, il fait résoudre le problème.

La seule façon dont cela a fonctionné pour moi était:

1. Créer une table similaire
2. Copiez les fichiers .frm et .idb de la nouvelle table similaire au nom de la table corrompue.
3. Autorisations de correctifs
4. Redémarrez MariaDB
5. Supprimer la table corrompue

si vous rencontrez ce problème et que vous n'avez pas d'autre option, remplacez le moteur par un autre moteur comme «myisam», puis essayez de créer la table.

avertissement: ce n'est pas la réponse valable car vous pouvez avoir des contraintes de clé étrangère qui ne seront pas prises en charge par un autre moteur de stockage. Chaque moteur de stockage a sa propre spécialité pour stocker et accéder aux données, ces points doivent également être pris en compte.

Veuillez REJETER le tablespace avant IMPORT

J'ai la même solution de problème ci-dessous

1. Vous devez d'abord supprimer le nom de votre base de données. si votre base de données ne supprime pas, vous avez flow me. Pour le système Windows, votre répertoire sera C: / xampp / mysql / data / yourdabasefolder remove "yourdabasefolder"

2. Encore une fois, vous devez créer une nouvelle base de données et importer votre ancien fichier sql. Ce sera du travail

Merci

J'ai dû localiser mon répertoire de données MySQL:

SHOW VARIABLES WHERE Variable_Name LIKE "% dir"

Puis forcez la suppression de cette base de données:

sudo rm -rf

Vous pouvez exécuter la requête suivante en tant qu'utilisateur root mysql

drop tablespace `tableName`

Hé les développeurs ne perdent pas votre temps. Supprimez simplement la base de données contenant les tables et importez à nouveau des tables entières. Gagnez du temps = le temps c'est de l'argent. À votre santé.