Intereting Posts

Comment rechercher dans tous les fichiers d’un projet dans IntelliJ Idea? Enum du diagramme de classes UML Pourquoi est-il long plus lent que l’int en Java x64? Créer un type anonyme dynamicment? Comment obtenir l’instance hWnd de Window? Mettre à jour le fragment de ViewPager Filtrer plusieurs valeurs sur une colonne de chaîne dans dplyr rxjs create subscribe once et dispose de la méthode Plus simple fragment de dialog oui / non Comment convertir des jobs cron Linux en “Amazon”? Récupère le corps de requête POST de HttpServletRequest Auto-injection avec le spring notifyDataSetChanged ne fonctionne pas sur RecyclerView Combien de ressources système seront disponibles pour garder 1 000 000 de sites Web ouverts? Comment comprendre le hachage sensible à la localisation?

Erreur: le tablespace pour la table xxx existe. S’il vous plaît annuler le tablespace avant IMPORT

Je suis relativement nouveau sur MySQL et je reçois une erreur très intéressante sur laquelle je ne trouve aucune aide via Google et la recherche stackoverflow.

Je gère un serveur local de MySQL 5.6.10 sur MacOS 10.8.3 et gère ma firebase database via les fondamentaux Navicat pour MySQL.

L’erreur que j’ai est que, après avoir exécuté et géré ma firebase database pendant quelques jours / semaines, quelque chose déclenche (il semble incomplet) supprimer certaines des tables que j’ai créées en utilisant des requêtes de Navicat.

Lorsque j’essaie d’exécuter des requêtes en utilisant ces tables, Navicat m’avertit alors que la table particulière n’existe pas. Jusqu’ici tout va bien – voici la bonne partie:

Lorsque j’essaie 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.

Toutefois, si j’essaie de supprimer la table ou d’essayer de supprimer le tablespace de cette table, utilisez

 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 que je suis invité à supprimer l’espace de la table, mais quand j’essaie de le faire, la table n’existe pas. Est-il possible qu’il y ait un certain type de vestiges de cette table à un endroit différent où la requête DISCARD n’est pas vérifiée? Et quelqu’un a-t-il une idée de ce qui pourrait déclencher tout cela – de manière totalement aléatoire, à ce qu’il semble?

Comme je le disais, je suis nouveau sur le sujet et à peu près complètement désemparé. 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 les droits de permission des utilisateurs, pourrait être lié à cela, mais je fais simplement l’hypothèse ici.

Un peu tard, 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 dans trop de détails (plus ici ), le tablespace du serveur de firebase database 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 se produire avec des requêtes plus importantes et beaucoup (beaucoup de «choses» non-table y sont stockées, annuler les journaux, les caches, etc.).

Quoi qu’il en soit, je trouve 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 tablename.ibd orphelin sans son fichier de compagnon habituel tablename.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 requête longue, une table verrouillée, etc ... a été effacée. Sinon, vous vous retrouvez avec un autre fichier .ibd orphelin lorsque vous essayez une seconde fois.

Utilisateurs Xampp et Mamp

A eu la même erreur lors de l’importation d’une firebase database (après l’avoir vidée) via MySQL. J’ai trouvé que j’avais 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 les utilisateurs de WAMP [Windows 7 Ultimate x64-bit]:

Je suis d’accord avec ce que DangerDave a dit et je propose donc une réponse aux utilisateurs de WAMP .

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

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

Double-cliquez sur le dossier de la firebase database qui contient la table incriminée pour l’ouvrir.
Il ne devrait pas y avoir de fichier [Your offending MySQL table name].frm , à la place, il devrait y avoir un fichier [Your offending MySQL table name].ibd
Supprimez le [Your offending MySQL table name].ibd
Ensuite, supprimez-le également de la corbeille
Ensuite, lancez votre requête MySQL sur la firebase database et vous avez terminé

Si vous récupérez le .idb après l’avoir supprimé, lisez cette réponse.

C’est comme ça que ça a fonctionné avec moi. J’ai eu le fichier .idb sans son .frm correspondant et chaque fois que je supprime le fichier .idb , la firebase database le recrée. et j’ai trouvé la solution dans une ligne dans la documentation de mysql (la table ne existe pas de partie)

1- Créez un fichier .frm correspondant dans un autre répertoire de firebase database et copiez-le dans le répertoire de la firebase database où se trouve la table orpheline.

2- Emettre DROP TABLE pour la table d’origine. Cela devrait réussir à 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 .frm table et nommez-le comme ma table manquante, puis effectuez une requête de table de repository normale. et voalla cela a fonctionné et la table est abandonnée normalement!

mon système est xampp sur windows MariaDB v 10.1.8

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

CREATE TABLE bad_table ENGINE = MyISAM …
rm bad_table.ibd
DROP TABLE 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 mêmes étapes répertoriées au début du post. De cette façon, l’identifiant du tablespace sur le dictionnaire de données et le fichier correspondant; l’importation du tablespace a donc réussi.

Cela peut vous donner une plus grande confiance dans la gestion de certaines “sockets” d’InnoDB pendant le processus de récupération ou même les transferts de fichiers.

ref

Supprimer / déplacer tablename.ibd ne fonctionnait pas pour moi.

Comment je l’ai résolu

Comme j’allais supprimer la table corrompue et non existante, j’ai fait une sauvegarde des autres tables en allant dans phpmyadmin-> database-> export-> selected tables to backup-> export (en .sql).

Après cela, j’ai sélectionné l’icône de la firebase database à côté du nom de la firebase database, puis je l’ai supprimée. Création d’une nouvelle firebase database. Sélectionnez votre nouvelle firebase database-> import-> 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 j’ai supprimé la table corrompue. Maintenant, je crée juste la table qui émettait l’erreur.

J’ai probablement déjà eu une sauvegarde de la table corrompue.

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

 set foreign_key_checks=0

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 firebase database. Cela supprimera tous les espaces de table associés et vous permettra de créer les tables à nouveau.

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

Voici les étapes de la solution:

sauvegarder votre firebase database (structure avec option de repository et données)
arrêter le service de moteur mysql
supprimer le répertoire de firebase database manuellement à partir de mysql / data
démarrer le moteur mysql
créer une nouvelle firebase database avec n’importe quel nom différent de votre firebase database corrompue
créer une table unique avec le nom de la table endommagée dans la nouvelle firebase database (c’est le secret). et il est préférable de créer la table avec exactement la même structure.
renommer la firebase database à l’ancienne firebase database corrompue
restaurez votre sauvegarde et votre table fonctionnera correctement.

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 le principal que je suppose est

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

avec table de repository 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

Créer une table échoue également comme ça:

 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_base_de_données, j’ai effectué les opérations suivantes en tant que root en reconnaissant le remplacement de innodb_table.ibd, ce qui nous a causé des problèmes

 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 de retour dans la console mysql, j’ai émis une commande de repository 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 carré et je peux recréer la seule table …

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

Eu ce problème plusieurs fois. Si vous avez une firebase database volumineuse et que vous souhaitez éviter la sauvegarde / restauration (avec ajout de la table manquante), essayez plusieurs fois dans les deux sens:

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 my_table (…)

Je supprime uniquement mon ancienne firebase database située dans mon localhost directement de wamp, Arrêtez tous les services, Allez dans wamp / bin / mysql / mysql [version] / data et j’ai trouvé la firebase database avec problemas, je la supprime et redémarre wamp tous les services, créer à nouveau votre firebase database 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 des ibdata1 et ib_logfile* (ils contiennent notamment les mappages de clés étrangères). 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 lancer 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 le but déclaré de ce script est différent, il résout le problème.

S’il vous plaît annuler le tablespace avant IMPORT

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

Vous devez d’abord supprimer le nom de votre firebase database. Si votre firebase database ne supprime pas, vous êtes en train de me transférer. Pour le système Windows, votre répertoire sera C: / xampp / mysql / data / yourdabasefolder supprimer “yourdabasefolder”
Encore une fois, vous devez créer une nouvelle firebase database et importer votre ancien fichier SQL. Ce sera du travail

Merci

Eu exactement le même problème; J’avais ajouté mysql@5.6 (après avoir déjà eu 5.5).

Les innodb_file_per_table=1 par défaut pour 5.6 sont innodb_file_per_table=1 alors que dans 5.5 ils sont innodb_file_per_table=0 .

Votre fichier ibdata1 existant (les données innodb combinées) aura toujours des références aux tables que vous essayez de créer / supprimer. Changez le innodb_file_per_table à 0 ou supprimez le fichier de données ibdata1 ( cela vous fera perdre toutes vos données, alors assurez-vous de le faire commencer par mysqldump ou d’avoir déjà un dump .sql ).

L’autre brew mysql@5.6 par défaut était le manque de port, donc la mise en réseau était par défaut sur les sockets unix, et le client mysql continuait à signaler:

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

J’ai ajouté --port=3306 au tableau .plist , mais vous pouvez également spécifier le port=3306 dans votre my.cnf

Les brew services stop mysql@5.6 apportent vos modifications, puis les brew services start mysql@5.6

Si vous avez ce problème et que vous n’avez pas d’autre option, changez le moteur en un autre moteur tel que «myisam», puis essayez de créer la table.

disclaimer: ce n’est pas la réponse valide car vous pouvez avoir des contraintes de clé étrangère qui ne seront pas supscopes 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.