web-dev-qa-db-fra.com

Erreur ne peut pas trouver ou ouvrir la table?

  • Version MySQL: 5.5.24

En raison du problème suivant:

mysql> desc reportingdb.v3_zone_date_cpm7k;       
ERROR 1146 (42S02): Table 'reportingdb.v3_zone_date_cpm7k' doesn't exist

/ var/journal/mysqld.log

120927 16:57:04 [ERROR] Cannot find or open table reportingdb/v3_zone_date_cpm7k#P#pcurrent_2012926 from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn't support.
See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html
how you can resolve the problem.

(Je n'ai pas encore trouvé la raison)

Les fichiers de la table existent toujours dans le Datadir:

-rw-rw---- 1 mysql mysql    8932 Sep 26 16:50 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k.frm
-rw-rw---- 1 mysql mysql      84 Sep 26 16:50 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k.par
-rw-rw---- 1 mysql mysql 9437184 Sep 13 17:56 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k#P#MERGER_2012828.ibd
-rw-rw---- 1 mysql mysql 1048576 Sep 27 15:42 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k#P#MERGER_2012926.ibd

C'est la table DDL à partir d'une sauvegarde antérieure d'un mois (afin que les partitions ont changé), mais pour référence:

CREATE TABLE `v3_zone_date_cpm7k` ( 
 `campaignid` mediumint(9) NOT NULL DEFAULT '0' COMMENT 'sub_campaignid', 
 `zoneid` smallint(6) NOT NULL DEFAULT '0', 
 `bannerid` mediumint(9) NOT NULL DEFAULT '0', 
 `totalclick` mediumint(9) unsigned NOT NULL DEFAULT '0', 
 `realclick` mediumint(9) unsigned NOT NULL DEFAULT '0', 
 `clickcharge` mediumint(9) NOT NULL DEFAULT '0', 
 `totalview` mediumint(9) unsigned NOT NULL DEFAULT '0', 
 `viewcharge` mediumint(9) unsigned NOT NULL DEFAULT '0', 
 `dt` date NOT NULL DEFAULT '0000-00-00', 
 `partnerid` smallint(6) unsigned NOT NULL DEFAULT '0', 
 KEY `ix_zoneid` (`zoneid`,`dt`), 
 KEY `ix_dt` (`dt`), 
 KEY `ix_campaignid` (`bannerid`) 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 
/*!50100 PARTITION BY RANGE (TO_DAYS(dt)) 
(PARTITION p00 VALUES LESS THAN (0) ENGINE = InnoDB, 
PARTITION p04 VALUES LESS THAN (734965) ENGINE = InnoDB, 
PARTITION p05 VALUES LESS THAN (735025) ENGINE = InnoDB, 
PARTITION MERGER_2012822 VALUES LESS THAN (735102) ENGINE = InnoDB, 
PARTITION pcurrent_2012822 VALUES LESS THAN (735103) ENGINE = InnoDB, 
PARTITION pcurrent_2012823 VALUES LESS THAN (735104) ENGINE = InnoDB)*/

Je vais récupérer cette table Suivre this guide. Mais à 2c. Étape, je reçois les erreurs ci-dessous:

mysql> alter table v3_zone_date_cpm7k_restore discard tablespace;
ERROR 1031 (HY000): Table storage engine for 'v3_zone_date_cpm7k_restore' doesn't have this option

http://bugs.mysql.com/bug.php?id=52422

Que puis-je faire maintenant?

MISE À JOUR

Je restaure de la sauvegarde, quelle est la bonne procédure pour se débarrasser de ce problème?

Ce que j'ai essayé (sur le serveur d'un autre):

  1. Table de chute -> Toujours obtenir le "n'existe pas"

  2. Arrêter mysql

    • Déplacez toutes les fichiers de la table vers un autre emplacement

    • Copier les fichiers de sauvegarde sur la base de données correspondante

    • Démarrer mysql:

    120927 19:12:07  InnoDB: Error: table 'reportingdb/v3_zone_date_cpm7k#P#MERGER_2012828'
    InnoDB: in InnoDB data dictionary has tablespace id 741528,
    InnoDB: but tablespace with that id or name does not exist. Have
    InnoDB: you deleted or moved .ibd files?
    InnoDB: This may also be a table created with CREATE TEMPORARY TABLE
    InnoDB: whose .ibd and .frm files MySQL automatically removed, but the
    InnoDB: table still exists in the InnoDB internal data dictionary.
    InnoDB: Please refer to
    InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html
    InnoDB: for how to resolve the issue.
    InnoDB: We removed now the InnoDB internal data dictionary entry
    InnoDB: of table `reportingdb`.`v3_zone_date_cpm7k` /* Partition `MERGER_2012828` */.
    120927 19:12:07  InnoDB: error: space object of table 'reportingdb/v3_zone_date_cpm7k#P#MERGER_2012926',
    InnoDB: space id 921829 did not exist in memory. Retrying an open.
    120927 19:12:07  InnoDB: Error: table `reportingdb`.`v3_zone_date_cpm7k` /* Partition `pcurrent_2012926`
*/ does not exist in
     the InnoDB internal
    InnoDB: data dictionary though MySQL is trying to drop it.
    InnoDB: Have you copied the .frm file of the table to the
    InnoDB: MySQL database directory from another database?
    InnoDB: You can look for further help from
    InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html

Mise à jour du vendredi 28 septembre 08:21:49 ICT 2012

Suivez votre suggestion, j'ai:

  • arrêté le mysql
  • déplacé v3_zone_date_cpm7k * à un autre endroit
  • a commencé le mysql

  • a importé le fichier .SQL et a obtenu l'erreur:

    Erreur 1050 (42S01) à la ligne 25: Tableau 'reportingdb.v3_zone_date_cpm7k /* Cloison p00 */' existe déjà

le journal d'erreur indique:

120928  8:26:42  InnoDB: Warning: trying to init to the tablespace memory cache
InnoDB: a tablespace 932889 of name './reportingdb/v3_zone_date_cpm7k#P#p00.ibd',
InnoDB: but a tablespace 932783 of the same name
InnoDB: already exists in the tablespace memory cache!
InnoDB: We assume that InnoDB did a crash recovery, and you had
InnoDB: an .ibd file for which the table did not exist in the
InnoDB: InnoDB internal data dictionary in the ibdata files.
InnoDB: We assume that you later removed the .ibd and .frm files,
InnoDB: and are now trying to recreate the table. We now remove the
InnoDB: conflicting tablespace object from the memory cache and try
InnoDB: the init again.

et le .idb Le fichier est créé automatiquement après le redémarrage:

# ls -l /var/lib/mysql/reportingdb/v3_zone_date_cpm7k#P#p00.ibd 
-rw-rw---- 1 mysql mysql 65536 Sep 28 08:35 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k#P#p00.ibd
mysqlinnodbrecovery
5
quanta

J'ai passé un peu de temps à essayer de reproduire l'erreur sur le schéma de partition, mais je ne peux pas obtenir l'erreur exacte avec la table orpheline.

120927 16:57:04 [Erreur] Impossible de trouver ou d'ouvrir la table Reportingingdb/v3_zone_date_cpm7k # p # pcurrent_2012926 à partir du dictionnaire de données interne de Innodb bien que le fichier .frm pour la table existe.

En déplaçant le fichier .ibd pour la partition hors du répertoire de données (ce qui semble en quelque sorte est arrivé), je reçois une erreur attendue:

[Erreur] MySQL tente d'ouvrir une poignée de table mais le fichier .ibd pour la table FOO/v3_zone_date_cpm7k # p # pcurrent_2012822 n'existe pas.

D'une discussion de discussion, je sais que vous avez un fichier de sauvegarde obsolète. En réalité en train de pouvoir forcer la partition 'pcurrent_2012926' (une perte de données), les étapes à suivre pour restaurer cette sauvegarde sont les suivantes (par mois de perte de données malheureusement):

  • Prenez une sauvegarde de votre serveur principal (juste au cas où!)
  • Restaurer la sauvegarde sur un autre serveur
  • Prenez un mysqldump de la table: mysqldump -uuser -p reportingdb v3_zone_date_cpm7k > v3_zone_date_cpm7k.sql
  • copier v3_zone_date_cpm7k.sql sur le serveur principal
  • Sur le serveur principal, essayez de le faire: DROP TABLE reportingdb.v3_zone_date_cpm7k
  • Si cela fonctionne, importez votre DUMPLILE: mysql -uuser -p reportingdb < v3_zone_date_cpm7k.sql Qui devrait restaurer ce tableau (avec une table omble de mois)
  • Si le DROP TABLE Ne fonctionne pas, essayez de déplacer le v3_zone_date_cpm7k.frm Et d'autres fichiers à un emplacement différent et redémarrez le serveur. Puis importer le fichier de vidage

La dernière étape concerne le message d'erreur vous indiquant que vous avez une table orphelinée:

Cela signifie qu'il y a un fichier orphelin .frm sans une table correspondante à l'intérieur de l'innovation. Vous pouvez déposer le fichier orpheliné .frm en le supprimant manuellement. [SRC]

J'espère vraiment que cela n'est pas nécessaire et vous pouvez restaurer la partition par un autre moyen. Ceci est une dernière méthode du complexe.

J'ai finalement reproduit votre erreur initiale. Bien qu'il faudra peu pour restaurer la partition, il peut être utile de comprendre que cela se produise à l'avenir (problème potentiel dans la manière dont le processus de sauvegarde/restauration est manipulé ou comment les partitions sont créées):

  • J'ai copié le v3_zone_date_cpm7k vers un autre emplacement (comme sauvegarde).
  • émettre un DROP TABLE v3_zone_date_cpm7k

  • copiez les fichiers v3_zone_date_cpm7k à la suite du Datadir

    desc v3_zone_date_cpm7k;

    ERROR 1146 (42S02): Table 'v3_zone_date_cpm7k' doesn't exist

[Erreur] Impossible de trouver ou d'ouvrir la table v3_zone_date_cpm7k # p # p00 du dictionnaire de données interne de Innodb Bien que le fichier .frm pour la table existe.

3
Derek Downey

Il existe un numéro spécial enregistré avec chaque table InnoDB. Ça s'appelle l'ID de tablespace. C'est un nombre attribué à la création de table et enregistré dans le dictionnaire de données à l'intérieur d'IBDATA1.

Il y a un moyen de faire disparaître ce problème, mais vous devez sauter à travers de nombreux cerceaux pour y parvenir. N'oubliez pas que si vous copiez une table InnoDb sur un autre disque, effectuez n'importe quel type de DDL et essayez de recopier les données de la table, il existe une petite possibilité de provoquer une incompatibilité des ID de tampon.

La seule personne que j'ai jamais lue à propos de cette récupération est Chris Calender , qui est le guide que vous avez fait référence à. J'ai déjà écrit cela auparavant.

Je pense que votre problème peut avoir à voir avec l'ID de table lui-même. Dans le 28 septembre, j'ai mentionné, j'ai aidé un client d'hébergement de DB qui a trouvé cette même référence. Son problème était ceci:

Le tablespace_id de cette table était de 912. Il a essayé de restaurer une ancienne copie de l'.ibd fichier. Il avait unespace_id de table de tables de 912. Voici ce que je l'ai aidé à faire:

  • Créé une instance mysql séparée
  • A écrit la procédure stockée pour créer et déposer la table InnoDB 911 fois.
  • Table InnoDB créée (maintenant tablepace_id était 912)
  • Espace à table rejetée
  • Commuté dans la sauvegarde .ibd fichier
  • Espace de table importé
  • Mysqldumped the Table
  • Importé le mysqldump dans le serveur d'origine

Le client avait 30 tables qu'il a dû faire. J'ai seulement écrit la procédure stockée pour lui. Je n'ai pas tenu pour les détails de Gory. Pourtant, le client a récupéré toutes les tables InnoDb, correspondant correctement à tous les tables de table.

Dans votre cas, je ne sais honnêtement pas si la méthode de Chris Calender fonctionnerait correctement sur une table partitionnée. Je suppose que l'idée serait d'obtenir tout .ibd Fichiers dans la partition d'avoir des espaces de table identiques.

1
RolandoMySQLDBA