web-dev-qa-db-fra.com

MySQL InnoDB a perdu des tables mais des fichiers existent

J'ai un MySQL InnoDB qui contient tous les fichiers de table de base de données, mais MySQL ne les voit pas et ne les charge pas.

Le problème est dû au fait que j'ai supprimé ces trois fichiers: ibdata1, ib_logfile0 et ib_logfile1.

parce que j’avais des problèmes avec le démarrage de mysql, et ce que j’ai lu, c’est de les supprimer parce que MySQL va simplement les régénérer (je sais que j’aurais dû les sauvegarder, mais je ne les ai pas).

Que puis-je faire pour que MySQL revienne sur les tables?

about_member.frm                              site_stories.frm
about_member.ibd                              site_stories.ibd
db.opt                                        stories.frm
FTS_00000000000000bb_BEING_DELETED_CACHE.ibd  stories.ibd
FTS_00000000000000bb_BEING_DELETED.ibd        story_comments.frm
FTS_00000000000000bb_CONFIG.ibd               story_comments.ibd
FTS_00000000000000bb_DELETED_CACHE.ibd        story_likes.frm
FTS_00000000000000bb_DELETED.ibd              story_likes.ibd
FTS_00000000000000f5_BEING_DELETED_CACHE.ibd  story_tags.frm
FTS_00000000000000f5_BEING_DELETED.ibd        story_tags.ibd
FTS_00000000000000f5_CONFIG.ibd               story_views.frm
FTS_00000000000000f5_DELETED_CACHE.ibd        story_views.ibd
FTS_00000000000000f5_DELETED.ibd              story_view_totals.frm
member_favorites.frm                          story_view_totals.ibd
member_favorites.ibd                          tags.frm
members.frm                                   tags.ibd
members.ibd
mysqlinnodb
29
Get Off My Lawn

Voici pourquoi MySQL ne peut pas voir ces fichiers: Le tablespace système (ibdata1) possède un dictionnaire de données spécifique à Storage-Engine qui permet à InnoDB de cartographier les utilisations potentielles des tables:

InnoDB Architecture

Déplacer les tables InnoDB d’un endroit à un autre nécessite des commandes telles que

ALTER TABLE tblname DISCARD TABLESPACE;
ALTER TABLE tblname IMPORT TABLESPACE;

Voici une partie de la Documentation MySQL 5.5 expliquant ce qui doit être considéré

Considérations de portabilité pour les fichiers .ibd

Vous ne pouvez pas déplacer librement des fichiers .ibd entre des répertoires de base de données, contrairement aux fichiers de table MyISAM. La définition de table stockée dans l'espace de table partagé InnoDB inclut le nom de la base de données. Les ID de transaction et les numéros de séquence de journal stockés dans les fichiers d'espace de table diffèrent également d'une base de données à l'autre.

Pour déplacer un fichier .ibd et la table associée d'une base de données à une autre, utilisez une instruction RENAME TABLE:

RENAME TABLE db1.tbl_name TO db2.tbl_name; Si vous avez une sauvegarde «propre» d'un fichier .ibd, vous pouvez le restaurer sur l'installation MySQL d'où il provient:

La table ne doit pas avoir été supprimée ou tronquée depuis la copie du fichier .ibd, car cela modifie l'ID de la table stocké dans l'espace de table.

Émettez cette instruction ALTER TABLE pour supprimer le fichier .ibd actuel:

ALTER TABLE nom_table DISCARD TABLESPACE; Copiez le fichier de sauvegarde .ibd dans le répertoire de base de données approprié.

Émettez cette instruction ALTER TABLE pour indiquer à InnoDB d'utiliser le nouveau fichier .ibd pour la table:

ALTER TABLE nom_table IMPORT TABLESPACE; Dans ce contexte, une sauvegarde de fichier .ibd «propre» est une sauvegarde pour laquelle les conditions suivantes sont remplies:

Il n'y a aucune modification non validée par transaction dans le fichier .ibd.

Il n'y a pas d'entrées de tampon d'insertion non fusionnées dans le fichier .ibd.

Purger a supprimé tous les enregistrements d'index marqués par suppression du fichier .ibd.

mysqld a vidé toutes les pages modifiées du fichier .ibd du pool de mémoire tampon vers le fichier.

Compte tenu de ces mises en garde et protocoles, voici un plan d'action suggéré

Pour cet exemple, essayons de restaurer la table tags dans la base de données mydb

ÉTAPE 1

Assurez-vous que vous avez des sauvegardes de ces fichiers .frm et .ibd dans /tmp/innodb_data

ÉTAPE 2

Obtenez l'instruction CREATE TABLE tags et exécutez-la en tant que CREATE TABLE mydb.tags .... Assurez-vous qu'il s'agit exactement de la même structure que l'original tags.frm

ÉTAPE 3

Supprimez le tags.ibd vide avec MySQL

ALTER TABLE mydb.tags DISCARD TABLESPACE;

ÉTAPE 4

Apportez la copie de sauvegarde de tags.ibd

cd /var/lib/mysql/mydb
cp /tmp/innodb_data.tags.ibd .
chown mysql:mysql tags.ibd

ÉTAPE 5

Ajouter la table tags au dictionnaire de données InnoDB

ALTER TABLE mydb.tags IMPORT TABLESPACE;

ÉTAPE 6

Testez l'accessibilité de la table

SHOW CREATE TABLE mydb.tags\G
SELECT * FROM mydb.tags LIMIT 10;

Si vous obtenez des résultats normaux, nous vous félicitons d’importer une table InnoDB.

ÉTAPE 7

A l'avenir, veuillez ne pas supprimer ibdata1 et ses journaux.

Essaie !!!

J'ai discuté de choses comme ça avant

CAVEAT

Que faire si vous ne connaissez pas la structure de la table de la variable tags?

Il existe des outils pour obtenir l’instruction CREATE TABLE en utilisant simplement le fichier .frm. J'ai également écrit un article à ce sujet: Comment extraire le schéma de table à partir du fichier .frm? . Dans cet article, j'ai copié un fichier .frm sur une machine Windows à partir d'une machine Linux, ai exécuté l'outil Windows et obtenu l'instruction CREATE TABLE.

34
RolandoMySQLDBA

J'ai la même situation, ne peut pas laisser tomber ou créer un nom de tbl spécifique. Ma procédure de réparation est la suivante:

  1. Arrêtez MySQL.

    service mysql stop

  2. Supprimez ib_logfile0 et ib_logfile1.

    cd /var/lib/mysql;
rm ib_logfile0 ib_logfile1

  3. Supprimer les fichiers tblname. ATTENTION: CELA SUPPRIMERA VOS DONNEES 

    cd /var/lib/mysql/dbname;
rm tblname*

  4. Démarrez MySQL.

    service mysql start
9
user293871