Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Recupération de bdd d'après les .frm

PoiroOnLinux

Bonjour,

Je cherche à récupérer une bdd qui n'a pas de sauvegarde récente.je n'ai accès qu'a une sauvegarde des fichiers du systèmes.
En lisant cette page, j'ai cru pouvoir redéployer les bases : https://www.thibautsoufflet.fr/restaurer-bdd-mysql-partir-des-fichiers-frm/
mais cela ne fonctionne pas pour moi :
quand je copié les dossiers des mes bases qui contiennent pour les fichiers .frm et .idb et .opt , je peux relancer mysql mais même si les bases et leurs tables sont présentes dans mysql, ce dernier m'indique que les tables sont vides.
Et lorsque j'ajoute le fichier ibdata1 (et les fichiers ib-logfile0 ib-logfile1) dans /var/lib/mysql. je ne peux plus redemarrer mysql :

Job for mysql.service failed because the control process exited with error code.

Quelqu'un aurait une idée pour remedier au problème SVP ?

Vobul

Regarde les logs de mysql dans /var/log.

bruno

Bonjour,

Quelle version d'Ubuntu utilises-tu ? Avec maraiadb ou mysql ?
La récupération des données à partir des fichiers frm et ibd peut s'avérer complexe voire impossible, c'est pourquoi il faut toujours avoir des sauvegardes logiques de ses bases de données (au format SQL).
Je doute que la procédure décrite dans le lien indiqué puisse fonctionner avec des tables utilisant INNODB.

Installe le paquet mysql-utilities et essaie la procédure décrite ici :
https://hoststud.com/resources/steps-to-restoring-table-structure-from-frm-and-ibd-files.465/

PoiroOnLinux

Oui pardon, il manquait quelques infos : la bdd est en mysql
Les fichiers en questions ont été récupéré sur un ubuntu 18.04 et le serveur où je tente de les redéployer est un ubuntu 20.04.

(donc passage de MySQL 5.7 à la version mysql 8.0.20, si je ne me trompe pas)

Concernant les logs :

2020-06-19T15:18:33.438987Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.20-0ubuntu0.20.04.1) starting as process 15220
2020-06-19T15:18:33.467818Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2020-06-19T15:18:34.659854Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2020-06-19T15:18:35.070383Z 0 [ERROR] [MY-011300] [Server] Plugin mysqlx reported: 'Setup of socket: '/var/run/mysqld/mysqlx.sock' failed, can't create lock file /var/run/mysqld/mysqlx.sock.lock'
2020-06-19T15:18:35.071592Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060
2020-06-19T15:18:35.422150Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2020-06-19T15:18:35.460372Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/tmp' in the path is accessible to all OS users. Consider choosing a different directory.
2020-06-19T15:18:35.610756Z 7 [System] [MY-013172] [Server] Received SHUTDOWN from user boot. Shutting down mysqld (Version: 8.0.20-0ubuntu0.20.04.1).

je vais commencer par tenter la procédure indiquée sur hoststud

En tout cas merci pour vos réponses messieurs

bruno

PoiroOnLinux a écrit Les fichiers en questions ont été récupéré sur un ubuntu 18.04 et le serveur où je tente de les redéployer est un ubuntu 20.04.

Est-ce que le serveur sous Ubuntu 18/.04 est toujours en fonction ?

Vobul

Nan mais déjà utilise la même version de MySQL, ne t'ajoute pas des difficultés supplémentaires !

PoiroOnLinux

et non justement le serveur en question ne demarre plus, je n'y ai pas accès physiquement et en plus pas de kvm sur ip donc je sais même pas ce qui l'empechait de booter correctement. ref , j'ai juste une copie des fichiers du system.
donc oui je pense que je vais suivre le conseil de vobul et me faire une VM avec ubuntu 18.04 pour tenter de générer un .sql si j'arrive à redéployer mes bases sur celui-ci
Encore merci messieurs
je vous ferai un retour en fin de manip

bruno

PoiroOnLinux a écritet non justement le serveur en question ne demarre plus, je n'y ai pas accès physiquement et en plus pas de kvm sur ip

Tous les hébergeur proposent une procédure de démarrage de secours. Cela vaut le coup d'essayer.

PoiroOnLinux a écrit donc oui je pense que je vais suivre le conseil de vobul et me faire une VM avec ubuntu 18.04 pour tenter de générer un .sql si j'arrive à redéployer mes bases sur celui-ci

Cela ne changera rien à la difficulté de la procédure pour récupérer les données à partir d'une copie physique (fichiers frm et ibd).

PoiroOnLinux

Bon j'avance mais c'est pas encore ca :
avec la procédure donnée utilisant mysqlfrm j'arrive a reconstruire les tables avec les champs mais par contre meme en copiant les .ibd de la source vers le dossier de la base (dans /var/lib/mysql/nomdemabase) j'ai toujours des tables sans données...

dans ma source j'ai aussi des fichiers ibdata1 , ib_logfile0 et ib_logfile1 dans /var/lib/mysql. j'ai tenté en les copiant vers ma cibles mais là encore cela fait planter mysql (ne redemarre plus avec le même msg d'erreur qu'au début)

bruno

Si tu as réussi a récupérer la structure et que tu as une erreur sur tablespace id dans le fichier error.log, tu peux essayer une des deux méthodes décrites ici :

https://www.chriscalender.com/tag/innodb-error-tablespace-id-in-file/