Discussion :

[sumosteph]

Bonjour,

Hier, à la même minute, notre serveur de développement ainsi que son disque de backup ont décidé de faire des erreur Input/Output, s'endommager et devenir inutilisable...

Le serveur ne démarre donc plus, et le disque de backup est corrompu...

J'ai pu récupérer tous les fichiers du serveur, qui possède deux disques, en le pluggant en target mode, ainsi que les fichiers source des bases de données (/usr/local/zend/mysql/data). J'ai pu restaurer les bases MyISAM en mettant le fichiers .frm .MYI et MYD sur ma machine. Par contre, je n'arrive pas à récupérer les fichiers InnoDB.

Si j'ai bien compris, InnoDB ne garde plus que les .frm dans le dossier de la base et place tout le contenu dans le fichier ibdata1 à la racine de data. Mais même en écrasant ce fichier, changeant ses droits pour être identiques aux autre (group wheel, user zend), le serveur ne se lance pas. Il me dit constamment que le fichier steph.local.pid n'a pas été mis à jour à la fermeture de la base... Dans les données du serveur, ce fichier s'appelle ted.sumo.pid, chez moi steph.local.pid (nom de notre serveur...). Lorsque j'arrive à lancer le serveur, je vois mes bases mais ne peux pas les ouvrir ni récupérer leur contenu...

Quelqu'un a-t-il un moyen pour que je puisse ouvrir ces fichiers qui appartenaient à un autre serveur sur ma machine ? Si c'est le cas, votre aide serait extrêmement appréciée!

Merci d'avance...

[Artemus24]

Salut sumosteph.

Hier, à la même minute, notre serveur de développement ainsi que son disque de backup ont décidé de faire des erreur Input/Output, s'endommager et devenir inutilisable...

J'ai déjà eu des problèmes avec mon disque dur, entre autre un atterrissage de la tête de lecture.
Ce n'est pas parce que il est inutilisable avec ton système d'exploitation qui est HS.
Après réparation des pistes/secteurs endommagés, qui comme par hasard sont ceux où se trouve le système d'exploitation, j'ai pu récupérer toutes les données.
Je suis passé par Acronis (sous windows) pour faire ma sauvegarde.

Un conseil qui n'est pas utile puisque j'ai déjà changé trois fois mon disque dur, est de faire des sauvegardes.
Pour ce faire, j'utilise acronis, et cela ma sauvé plus d'une fois.

Il ne faut pas récupérer que les fichier de type innodb, mais aussi les fichiers suivants :
--> ib_buffer_pool
--> ib_logfile0
--> ib_logfile1
--> ibdata1
--> ibtmp1

Je te conseille de lire mon site à la page 'ibdata1'.

@+

[sumosteph]

Merci, j'ai copié les fichiers ib_logfile0,1 et ibdata1 ainsi que le fichier pid renommé. Par contre buffer_pool et ibtmp1 je les ai pas (ni dans le backup ni sur mon local)

mais là j'ai une erreur de socket... ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/zend/tmp/mysql.sock'

Quand je lance mysql avec mon data d'origine, c'est bien cette socket qu'il utilise, et ça fonctionne... mais si je démarre avec les fichiers récupérés du serveur, la socket n'existe plus... tmp est vide

[Artemus24]

Salut sumosteph.

Normalement, tu dois récupérer la totalité du répertoire data et prendre la même version MySql que tu avais précédemment.
Tu dois aussi faire en sorte d'avoir le même fichier 'my.ini' (les mêmes chemins ou bien tu les adaptes).

Code :

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

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/zend/tmp/mysql.sock'

Cela singifie que MySql n'a pas pu démarrer !
As-tu quelque part un compte rendu du démarrage de MySql ? Sous windows, je consulte l'observateur d’événements.
Sinon regarde ton fichier 'my.ini'. Il y a sûrement quelque chose qui n'est pas conforme.

Je suis sous windows, donc difficile de t'aider. J'ai trouvé ce lien : http://forum.ubuntu-fr.org/viewtopic.php?pid=82111

@+

[sumosteph]

Salut et merci,

j'ai effectivement des logs dans le fichier erreur... mais je n'y comprends pas grand chose, je Google un peu partout...

si ce message te parle, je suis preneur :-)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
151019 20:59:38 mysqld_safe Starting mysqld daemon with databases from /usr/local/zend/mysql/data
151019 20:59:38 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/zend/mysql/data/ is case insensitive
151019 20:59:38 [Note] Plugin 'FEDERATED' is disabled.
151019 20:59:38 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151019 20:59:38 InnoDB: Compressed tables use zlib 1.2.3
151019 20:59:38 InnoDB: Initializing buffer pool, size = 128.0M
151019 20:59:38 InnoDB: Completed initialization of buffer pool
151019 20:59:38 InnoDB: highest supported file format is Barracuda.
InnoDB: No valid checkpoint found.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/error-creating-innodb.html
151019 20:59:38 [ERROR] Plugin 'InnoDB' init function returned error.
151019 20:59:38 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151019 20:59:38 [ERROR] Unknown/unsupported storage engine: InnoDB
151019 20:59:38 [ERROR] Aborting
 
151019 20:59:38 [Note] /usr/local/zend/mysql/bin/mysqld: Shutdown complete

edit*: j'ai essayé tous les niveaux de innodb_force_recovery... de 1 à 6 et toujours ce message (plus long en mode 6 si besoin)

[Artemus24]

Salut sumosteph.

Je voie que tu as pu démarrer ton mysql.

Code :

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

[Warning] Setting lower_case_table_names=2 because file system for /usr/local/zend/mysql/data/ is case insensitive

Il semble qu'ici, tu as un problème entre les majuscules et les minuscules ('case sensitive').
Le mieux est de mettre tous tes noms en minuscules.
C'est la grosse différence entre windows (non sensible à la casse) et linux (sensible à la casse).

Pour l'autre erreur, il s'agit en fait de l'initialisation du fichier 'ibdata1'.
La grosse astuce est de supprimer ce fichier physiquement : /data/ibdata1.

Oui mais à quoi cela sert de procéder ainsi ?
Ce fichier 'ibdata1' contient un descriptif de toutes les tables innodb du SGBDR MySql.
Aussi bien ceux interne au SGBDR que ceux qui ont été ajoutées par toi-même.

Mon didacticiel (ibdata1) propose de recréer les tables InnoDB interne au SGBDR de MySql.

Tu as un décalage entre l'absence des descriptifs dans le fichier 'ibdata1' et le fait que tu utilises des table 'innodb'.
Si tu supprimes le fichier 'ibdata1', il faut alors réinstaller toutes les tables 'innodb' dans le SGBDR.
Aussi bien tes tables que celle dans le SGBDR MySql. D'où l'importance de faire régulièrement une sauvegarde.

Je te conseille de faire une sauvegarde du fichier 'ibdata1' avant de le supprimer.

Maintenant si tu n'as pas fait de sauvegardes, je ne sais pas comment réinitialiser correctement ce fichier 'ibdata1'.

@+