Re: Pb MySQL sur Debian
Bonjour,
Comme tu as l'air toujours bloqué, je me lance :
Le 19/02/2016 16:17, Grégoire COUTANT a écrit :
Bonjour à tous,
Notre serveur interne à planté cette nuit lors des dumps de sauvegarde
des DB.
Un de nos logiciels (redmine) a perdu (!) sa base innodb et nous
n'arrivons pas à récupérer les données.
Quelques explications :
- Le script de dump de la nuit à fait planté le serveur MySQL
- Ce plantage à fait perdre des fichiers frm
- Nous avons toujours le fichier ibdata qui fait 80 Go (avec les
données dedans normalement)
- Nous avons récupéré un backup d'il y a deux jours des fichiers frm,
quand on le met en place, ça ne change rien.
On se dit que les données sont dans le ibdata mais tout ce qu'on a
essayé ne fonctionne pas (repair etc...), on n'accède pas à la base.
Avez-vous des idées de comment faire
Quelques remarques :
Tu as l'air d'avoir 2 types de sauvegardes :
- mysqldump (2 dernières sauvegardes à 0 .... mais as-tu d'autres
sauvegardes ? )
- backup des fichiers bruts frm (et ibdata ?)
Si je ne dis pas de bêtises, tes backups de frm et ibdata ne peuvent
être fonctionnels que si leur backup a été effectué en même temps avec
mysql arrêté ... est-ce la cas ?
Comme tes dumps mysql ont l'air HS, il faut que tu utilises tes
sauvegardes de fichiers bruts (frm, ibdata et aussi ib_logfile je suppose).
Si tu possèdes d'autres sauvegardes mysqldump de tes bases, il est
possible que ta config de base de mysql, qui permet pourtant de faire
tourner de gros ibdata, ne soit pas suffisamment taillé pour importer
les mêmes gros ibdata.
Je n'ai plus accès aux valeurs que j'avais modifiées, mais il faudrait
peut-être déjà voir avec :
innodb_flush_method
innodb_buffer_pool_size
innodb_log_file_size
innodb_log_buffer_size
plus d'autres valeurs affectant la gestion de la mémoire par mysql.
Un serveur de test pour tester les réimports de base serait un plus.
Essayer aussi de limiter mysql à localhost le temps des réimports de dumps.
De plus, il est recommandé (si pas déjà fait) d'avoir un ibdata par base :
innodb_file_per_table
Voilà quelques pistes.
Samuel.
Reply to: