Récupérer base de données : fichier frm et ibd

Support Debian
Tags: #<Tag:0x00007fc9dbc5c810>
#1

Salut
j’ai perdu une base de données
j’ai un dossier avec les fichiers ibd er frm mais mysql ne voit pas les tables :

#1932 - Table ‹ combes.data › doesn’t exist in engine

malheureusement ma sauvegarde ne contient pas cette base de données

j’ai essayé quelques trucs à base de ibdata, iblog , installation toute neuve et copie du dossier mais pour l’instant rien :
si vous avez une idée à base de configurations, réinstalaltions ou autre du même genre …

PS
je crée un autre sur le même problème mais avec une autre approche plus programmation :

#2

Jamais testé mais regarde avec mysqlfrm pour récupérer le schema, ensuite tu pousse le schéma et tes fichiers frm et ibdata à la place de ceux créer sur une instance tout propre.

Pour frm et ibdata c’est à dire du mysql avant la 8.0, le fichier .frm a disparu au passage en 8.0

Articles de chez Perconna : MySQL 8 and The FRM Drop... How To Recover Table DDL

PS : bon courage ça va être galère cette histoire :wink:

#3

salut
j’ai vu les posts sur mysqlfrm , mais il n’existe pas sur debian , alors j’ai laissé tomber, mais sais-tu s’il existe, où le trouver?
merci

#4

Salut,

quelle est la version mariadb / mysql ? Toutes les tables sont en InnoDB ? Et question naïve, mais les fichiers ibd et frm appartiennent bien au user qui exécute le serveur mysql (par défaut mysql) ?

J’ai utilisé un autre outil pour migrer une grosse bdd mariadb vers un nouveau serveur en utilisant « seulement » les fichiers de la base de données (au lieu de dumps sql), mariabackup (dispo dans le paquet mariadb-backup), tu peux tenter de l’utiliser en te référant à la doc, même si tu n’as pas pu effectuer l’étape préliminaire de mariabackup --backup ça peut se tenter. Par contre il faut que la version mariadb-server soit strictement la même que sur le serveur duquel tu as récupéré les fichiers ibd et frm, si tu les restaures sur une autre machine

#5

salut, merci

erreur trouvée :, voir en bas

2024-12-11 3:52:28 0 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace: ./Joel142/MDP.ibd uses space ID: 383. Cannot open filepath: ./dolibarr2001/llx_expeditiondet_batch.ibd which uses the same space ID.

difficile à comprendre ce qui s’est passé
selon toute vraissemblance, une corruption est arrivée sur mes fichiers qui devaient marcher avant.
J’ai essayé un mysqlfrm sur une debian stretch mais ça n’a pas marché

Ta proposition de backup me semble inutile : il s’agit simplement d’une copie de fichiers :

For example, you could also execute the following to restore the backup:
$ rsync -avrP /var/mariadb/backup /var/lib/mysql/

mais en utilisant mariabackup
mariabackup --backup --target-dir=/tmp/hh/ --user=root --password=…
j’obtiens une erreur

[00] 2024-12-11 03:50:41 Connecting to MariaDB server host: localhost, user: root, password: set, port: not set, socket: /run/mysqld/mysqld.sock
[00] 2024-12-11 03:50:41 Using server version 10.11.6-MariaDB-0+deb12u1
mariabackup based on MariaDB server 10.11.6-MariaDB debian-linux-gnu (x86_64)
[00] 2024-12-11 03:50:41 uses posix_fadvise().
[00] 2024-12-11 03:50:41 cd to /var/lib/mysql/
[00] 2024-12-11 03:50:41 Loading plugins
[00] 2024-12-11 03:50:41 open files limit requested 0, set to 1024
[00] 2024-12-11 03:50:41 mariabackup: using the following InnoDB configuration:
[00] 2024-12-11 03:50:41 innodb_data_home_dir = 
[00] 2024-12-11 03:50:41 innodb_data_file_path = ibdata1:12M:autoextend
[00] 2024-12-11 03:50:41 innodb_log_group_home_dir = ./
[00] 2024-12-11 03:50:41 InnoDB: Using liburing
2024-12-11  3:50:41 0 [Note] InnoDB: Number of transaction pools: 1

Ces trois lignes finales sans sudo :
2024-12-11 3:50:41 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
2024-12-11 3:50:41 0 [ERROR] InnoDB: The error means mariadbd does not have the access rights to the directory.
[00] 2024-12-11 03:50:41 Error: cannot read redo log header

Ces lignes finales avec sudo :

2024-12-11  3:52:28 0 [Note] InnoDB: Buffered log writes (block size=512 bytes)
[00] 2024-12-11 03:52:28 mariabackup: Generating a list of tablespaces
2024-12-11  3:52:28 0 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace: ./Joel142/MDP.ibd uses space ID: 383. Cannot open filepath: ./dolibarr2001/llx_expeditiondet_batch.ibd which uses the same space ID.
[00] FATAL ERROR: 2024-12-11 03:52:28 Failed to validate first page of the file dolibarr2001/llx_expeditiondet_batch, error 40
#6

suite à l’erreur trouvée au dessus

2024-12-11 3:52:28 0 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace: ./Joel142/MDP.ibd uses space ID: 383. Cannot open filepath: ./dolibarr2001/llx_expeditiondet_batch.ibd which uses the same space ID.

si je détruis la base avec DROP DATABASE Joel42

#1010 - Erreur en effaçant la base (rmdir './Joel42', erreur 39 "Directory not empty")
  1. la base Joel142 ne lit pas les tables alors qu’on a les fichiers ibd et frm mais phpmyadmin et mysql les voit quand même ( un show tables montre table1 mais un select * from table1 ne marche pas )
  2. une fois la base « droppée », la références aux tables a disparu mais les fichiers ibd et frm y sont encore d’où le « Directory not empty »
#7

OK, les tablespace posent problème. La procédure que je ferais est la suivante:

  1. (re)création de la base de données vierge, avec seulement la structure (tables, fonctions, procédures, vues…), comme si tu avais un dump avec l’option --no-data, ou alors tu peux récupérer le schéma de BDD à partir des fichiers d’installation de l’appli (Dolibarr) par exemple
  2. pour chaque table de la BDD, faire un alter table $matable discard tablespace ;
  3. copier dans /var/lib/mysql/ma_bdd les fichiers .ibd et .frm récupérés, en faisant attention qu’ils appartiennent bien au user mysql
  4. pour chaque table de la BDD, faire un alter table $matable import tablespace ;
#8

salut
j’ai déjà essayé ça mais sans sans le point 1 :
pour préciser ,
Tu proposes de détruire la base, puis de recréer les tables , puis de faire un alter … sur chaque table, puis copier les fichiers et alter … ?
ok je vais essayer

#9

après la craétion des tables les fichiers frm apparaissent

  1. essai : garder les nouveaux frm et ne copier que les ibd :

  2. essai : virer les nouveaux frm et copier les ibd et frm :
    #1815 - Internal error: Drop all secondary indexes before importing table PHOTOS_9_1/commentaires when .cfg file is missing.