Discussion :

[nounours460]

Bonjour,

Suite à une très longue coupure électrique, notre serveur linux a planté.

Dessus des services web, notamment notre Redmine avec sa base de données.

Le problème: suite à la coupure on a pu récupérer tout ce qui était dans /var/lib/mysql/

Suite à mes recherches, j'ai vu que je pouvais copier mes anciennes bases directement dans une nouvelle installation de mysql-server. J'ai donc copié la base ainsi que le ibdata1 (qu'au passage je trouve plutot petit en taille).

A chaque fois que je veux relancer mysql, il refuse car il me dit que le fichier n'est pas l'original etc....

Est-ce que qqun peut me dire quoi faire et si je vais arriver à récupérer mes données?

Merci par avance !

[Artemus24]

Salut nounours460.

Il fallait laisser en l'état et non pas commencer à bidouiller dans les fichiers systèmes de MySql.

Vous deviez faire un "repair" + "optimize" afin de réparer ce qui doit être réparé dans votre base de données.
C'est une procédure de maintenance que vous devriez faire quotidiennement.

@+

[Christophe]

Vérfie les droits des fichiers (ils doivent être en utilisateur mysql), essayes de prendre le fichier my.cnf

[nounours460]

Salut nounours460.

Il fallait laisser en l'état et non pas commencer à bidouiller dans les fichiers systèmes de MySql.

Vérfie les droits des fichiers (ils doivent être en utilisateur mysql), essayes de prendre le fichier my.cnf

Je n'ai pas bidouiller j'ai sauvegarder ma base, par contre je l'avoue j'ai tenté de réinstaller mysql mais j'ai omis de sauvegarder le my.cnf. Pour les droits j'ai tout remis comme il faut.

Ai-je une autre solution?

[nounours460]

Voici l'erreur que j'ai dans /var/log/mysql/error.log lorsque je tente de démarrer mysql

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
InnoDB: Error: auto-extending data file ./ibdata1 is of a different size
InnoDB: 64 pages (rounded down to MB) than specified in the .cnf file:
InnoDB: initial 640 pages, max 0 (relevant if non-zero) pages!
180611  8:43:08 InnoDB: Could not open or create data files.
180611  8:43:08 InnoDB: If you tried to add new data files, and it failed here,
180611  8:43:08 InnoDB: you should now edit innodb_data_file_path in my.cnf back
180611  8:43:08 InnoDB: to what it was, and remove the new ibdata files InnoDB created
180611  8:43:08 InnoDB: in this failed attempt. InnoDB only wrote those files full of
180611  8:43:08 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
180611  8:43:08 InnoDB: remove old data files which contain your precious data!
180611  8:43:08 [ERROR] Plugin 'InnoDB' init function returned error.
180611  8:43:08 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
180611  8:43:08 [ERROR] Unknown/unsupported storage engine: InnoDB
180611  8:43:08 [ERROR] Aborting

[Artemus24]

Salut Nounours460.

Je n'ai pas bidouiller j'ai sauvegarder ma base

Par un export sous phpmyadmin ou par mysqldump, en ligne de commande ?

je l'avoue j'ai tenté de réinstaller mysql

Pourquoi effectuer une réinstallation du serveur MySql ?
Comme je l'ai dit précédemment, un arrêt brutal du serveur MySql nécessite de faire un repair suivi d'une optimisation sur toutes vos tables.

j'ai omis de sauvegarder le my.cnf.

Et que faites-vous du fichier "ibdata"1 ?

Si vous repartez d'un fichier vierge (celui de ibdata1), vous n'aurez pas accès à tout ce qui est en InnoDB.

Ai-je une autre solution?

Il y a deux solutions pour restaurer votre serveur MySql :
1) soit par une sauvegarde de votre base de données, par l'intermédiaire d'un export en utilisant phpmyadin, soit en utilisant mysqldump, en ligne de commande.
2) soit un backup du disque dur qui contient votre serveur MySql.
Ceci est à faire très régulièrement, histoire de ne pas perdre du temps en cas de réinstallation de votre serveur MySql, mais surtout ne pas refaire une saisie qui pourrait prendre plusieurs jours.
Il est conseillé de faire un sauvegarde ou un backup tous les soirs.

Voici l'erreur que j'ai dans /var/log/mysql/error.log lorsque je tente de démarrer mysql

Le problème provient de votre fichier ibdata1.
Le message du début indique que la taille déclarée dans le fichier my.cnf n'est pas en conformité avec le fichier réellement présent dans votre répertoire "/data".
Les messages de fin indique que le fichier ibdata1 n'a pas été correctement initialisé pour utiliser le moteur InnoDB au travers de votre base de données.

Avez-vous essayé de récupérer votre ancien fichier ibdata1 ?

@+

[nounours460]

Nous avions deux sauvegardes.

Une .sql via mysqldump datant de janvier, le script de sauvegarde auto qui lance cette commande a planté il faut croire.

Une autre via la copie direct des fichiers (au jour du crash) dans /var/lib/mysql qui contient toutes les bases et tables + ibdata1, ib_log....

La première fois nous avons tenté de suivre un tuto qui conseillé de réinstaller mysql et après arrêt du service, copier les fichiers sauvegardés directement dans le nouveau /var/lib/mysql à la place des autres, après relance du service mysql nous avons eu l'erreur sur ibdata1

Aujourd'hui mon collègue a réussi à réimporter le .sql et on a retrouver la sauvegarde de janvier.

Ma question est désormais de savoir si à partir des fichiers sauvegardés, pouvons nous créer un .sql qui permettra l'import de la sauvegarde la plus récente?

Merci

[Artemus24]

Salut nounours460.

Une .sql via mysqldump datant de janvier, le script de sauvegarde auto qui lance cette commande a planté il faut croire.

C'est pas un peu trop vieux, une sauvegarde .sql datant de janvier 2018 ?
Par "auto", voulez-vous dire par l'intermédiaire de la crontab, qui d"éclenche un script mylsq, contenant la commande "mysqldump" ?
Et quel est l'origine de votre plantage ? Un problème de volumétrie ?

Une autre via la copie direct des fichiers (au jour du crash) dans /var/lib/mysql qui contient toutes les bases et tables + ibdata1, ib_log....

Et c'est là que vous avez oublié le fichier my.cnf.
Comme je l'ai dit, il n'est pas nécessaire d'installer la même version mysql que vous utlisez.
Tout dépend de la nature de votre plantage.
Si c'est juste une coupure électrique, sans déterioration du matériel, c'est-à-dire un atterrissage de la tête de lecture sur le disque dur, vous pouvez effectuer un rapair et un optimize de toutes vos tables.
Dans le cas contraire, il est fort probable que par cette méthode, vous ne puissiez pas tout récupérer car vous aurez des secteurs vérollés.
D'où l'intérêt d'avoir une sauvegarde .sql récente, genre la veille.

La première fois nous avons tenté de suivre un tuto qui conseille de réinstaller mysql et après arrêt du service, copier les fichiers sauvegardés directement dans le nouveau /var/lib/mysql à la place des autres, après relance du service mysql nous avons eu l'erreur sur ibdata1

Il y a beaucoup de bêtises sur internet !
L'une d'elle consiste à récupérer les fichiers système () de votre base de données et de les placer dans la nouvelle version que vous aurez installé.
Sauf que le fichier ibdata1 de la nouvelle version est vide et ne sera pas en mesure de lire vos tables InnoDB.
Il n'existe pas d'outil qui peut récupérer ou remettre en forme un fichier ibdata1.
La seule bonne méthode, après l'installation d'une nouvelle version MySql, est de faire un import à partir de phpmyadmin.

Aujourd'hui mon collègue a réussi à réimporter le .sql et on a retrouver la sauvegarde de janvier.

C'est déjà une bonne chose. Sauf qu'il vous manque tout ce qui a été fait depuis janvier jusqu'à aujourd'hui.

Il est possible de récupérer la partie manquante à partir des fichiers binary log.
Pour cela vous devez identifier la date et l'heure où votre dernière sauvegarde a été faite (je parle celle de janvier 2018).
Ensuite, il s'agit ni plus ni moins d'une importation.

Ma question est désormais de savoir si à partir des fichiers sauvegardés, pouvons nous créer un .sql qui permettra l'import de la sauvegarde la plus récente?

Elle se présente comment la sauvegarde la plus récente ? Si c'est un fichier .sql, il n'y a aucun problème.
Si vous me parlez de vos fichiers systèmes, c'est impossible.

@+

[Christophe]

Tentes ceci :
https://askubuntu.com/questions/9644...-database-fold

[nounours460]

C'est pas un peu trop vieux, une sauvegarde .sql datant de janvier 2018 ?
Par "auto", voulez-vous dire par l'intermédiaire de la crontab, qui d"éclenche un script mylsq, contenant la commande "mysqldump" ?
Et quel est l'origine de votre plantage ? Un problème de volumétrie ?

Non c'est juste que le cron n'était pas bon donc ne pouvait pas fonctionnait.

Et c'est là que vous avez oublié le fichier my.cnf.
Comme je l'ai dit, il n'est pas nécessaire d'installer la même version mysql que vous utlisez.
Tout dépend de la nature de votre plantage.
Si c'est juste une coupure électrique, sans déterioration du matériel, c'est-à-dire un atterrissage de la tête de lecture sur le disque dur, vous pouvez effectuer un rapair et un optimize de toutes vos tables.
Dans le cas contraire, il est fort probable que par cette méthode, vous ne puissiez pas tout récupérer car vous aurez des secteurs vérollés.
D'où l'intérêt d'avoir une sauvegarde .sql récente, genre la veille.

Oui on l'a zappé enfin c'est surtout quand on a réinstallé Mysql qu'il a dégagé.
Il y a eu une coupure de 12h dans l'établissement avec une dizaine de réamorcage successif (pdt un week-end, on était pas là).

Comment on fait le repair et optimize? En ligne de commande? Mais maintenant ce n'est plus possible vu qu'on a que les fichiers systemes sauvegardés et que mysql plante si on les copie/colle

Il y a beaucoup de bêtises sur internet !
L'une d'elle consiste à récupérer les fichiers système () de votre base de données et de les placer dans la nouvelle version que vous aurez installé.
Sauf que le fichier ibdata1 de la nouvelle version est vide et ne sera pas en mesure de lire vos tables InnoDB.
Il n'existe pas d'outil qui peut récupérer ou remettre en forme un fichier ibdata1.

On a aussi le ibdata1 original (je ne sais pas si c'était bien clair) qu'on a copié/collé à la place de l'ancien sans résultat.

La seule bonne méthode, après l'installation d'une nouvelle version MySql, est de faire un import à partir de phpmyadmin.

Ca on l'a fait à partir de celle de janvier et ca n'a pas marché au début.

Il est possible de récupérer la partie manquante à partir des fichiers binary log.
Pour cela vous devez identifier la date et l'heure où votre dernière sauvegarde a été faite (je parle celle de janvier 2018).
Ensuite, il s'agit ni plus ni moins d'une importation.

C'est à dire? On parle d'autre fichiers encore que ceux sauvegardés?

Elle se présente comment la sauvegarde la plus récente ? Si c'est un fichier .sql, il n'y a aucun problème.
Si vous me parlez de vos fichiers systèmes, c'est impossible.

Donc c'est mort?

Pour apporter plus de précision, on a copié ces fichiers quand on a vu que notre seule sauvegarde .sql était de Janvier, on s'est dit qu'on arriverait peut-être à en faire qqch. Et suite à tuto, plusieurs tuto de ce type : https://www.jejemaes.net/2012/10/res...-database-sql/ ou celui là http://resources.fabien-haddadi.info/fr/21/74 on s'est dit qu'on avait une chance.

[Artemus24]

Salut nounours460.

Comment fait-on le repair et optimize ? En ligne de commande ?

Pour le repair :
--> https://dev.mysql.com/doc/refman/8.0...air-table.html

et pour l'optimize :
--> https://dev.mysql.com/doc/refman/8.0...ize-table.html

Cela se fait avec un serveur MySql qui a démarré.

C'est à dire? On parle d'autre fichiers encore que ceux sauvegardés?

A vous de me dire si vos fichiers "binary log" ont été activés ou pas.

Est-ce que vous avez ceci dans votre fichier "my.cnf" ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
# -------------------#
#     Binary Log     #
# -------------------#
 
binlog-expire-logs-seconds = 0
expire_logs_day            = 0
 
log-bin              = f:/Wamp/logs/mysql_binary_log
log-bin-index        = f:/Wamp/logs/mysql_binary_log.index
 
binlog-cache-size    = 10M
binlog-format        = mixed
binlog-do-db         = test

Ici, il s'agit de ma base "test".
Si vous êtes débutant, la manipulation est complexe, surtout quand on ne l'a jamais fait avant.

Donc c'est mort?

Sans sauvegarde .sql, je ne sais pas si c'est mort, mais cela sera une mission impossible.

En ce qui concerne vos liens, le premier traite des base de données de type "MyIsam" dont les fichiers systèmes se terminent par *.frm, *.MYD et *.MYI.
Comme le moteur MyIsam n'utilise pas le fichier ibdadta1, il est possible de restaurer vos tables.
Utilisez-vous le moteur MyIsa ?

En ce qui concerne le second lien, il s'agit bien du moteur InnoDB, mais quasiment rien n'est expliqué de ce qu'il faut faire pour restaurer une base de données.

@+

[Drone]

Bonjour,

Si dans votre config mysql votre variable innodb_file_per_table était activée, vous devriez pouvoir récupérer vos données grâce au différents fichiers ibd
qui devraient se trouver dans (./var/lib/mysql/databasename/tablename.ibd)

Si vous avez des fichiers ibd d'une taille assez grandes, vos données sont à l'intérieur et je pourrais vous expliquer comment tenter de les récupérer.

[Artemus24]

Salut Drone.

Non, ce n'est pas possible car d'après ce que j'ai pu comprendre, nounours460 a écrasé le fichier ibdata1.
De ce fait, quand il utilise le moteur InnoDB, il ne peut plus accéder aux tables utilisant ce moteur.

@+

[nounours460]

En tout cas aujourd'hui on a tout essayé, rien ne marche avec les fichiers systèmes, pas de binary log sinon. Le seul truc qui marche c'est la sauvegarde en .sql où on le gros de nos fichiers (le plus important).

Bref merci quand même.

Je clotûre

[Christophe]

T'as essayé le lien que j'ai donné ?

[nounours460]

T'as essayé le lien que j'ai donné ?

Oui en fait j'avais déjà testé innodb_force_recovery=5 et =1, puis 2, 3 ,4, 6

Mysql n'a jamais voulu démarré

[Drone]

Bonjour,

En innodb, sans fichier ibdata, juste avec les fichiers ibd, si la configuration est en file per table on peut recréer la base de données, je l'ai déjà fait plusieurs fois.

Nounours460 quel était ta version de mysql ?

A partir d'une certaine version de mysql la variable file per table est activé par défaut.

[Artemus24]

Salut Drone.

Cela dépend de la version mysql que vous utilisez.

@+

[Drone]

Salut Arthemus24,

Oui c'est ce que je venais de dire d'ou ma question de connaitre la version mysql qu'il utilisait.
Comme dans son premier post il dit avoir un fichier ibdata de petite taille, je pense qu'il était en file_per_table et qu'il peut récupérer ses données en utilisant un procédure adaptée..

[Artemus24]

Salut drone.

J'ai déjà fait des tests de restaurations (pas de réinstallation) en partant d'un fichier ibdata1 vide et je ne suis pas arrivé à faire fonctionner à nouveau MySql.
Comme je l'ai dit précédemment, c'est le fichier ibdata1 qui met le bordel en cas de plantage.

Pour une réinstallation à partir d'une sauvegarde, aucun problème.

Vous dites que votre configuration est en "file_per_table". Je suis aussi dans ce cas.
Si vous avez une astuce, je suis preneur et je peux tester cela !

@+