import Dump .sql innoDB sur mysql 5.0.51a corrompt aléatoirement ...

Steph_61 · 01/05/2012, 13h33

Bonjour,

Je suis sur un RPS mais mon problème n'est du à ce rps. C'est pourquoi je me permet de poster pour un souci mysql innodb.

Je tente de restaurer les backups de virtualmin sans succès.
Après avoir réinstallé tout plusieurs fois et testé le rps en mod rescue, je conclus que ce sont les tables de type innoDB qui posent problème.

(J'ai essayé de passer à squeeze sur le rps. ça marche bien mais pas envie de passer en php 5.3 pour le moment. Cela n'a aucune incidence sur le problème des tables qui nous occupe)

Donc les backups fonctionnent sauf pour les tables de type innoDB.

Voila donc une semaine que je cherche comment restaurer des bases de données à partir de fichiers sql. La restauration des tables en MyISAM ne posent aucun problème, par contre les innoDB deviennent corrompues aléatoirement lors de la restauration: Je charge le fichier sql et l'exécute puis d'un coup les innoDB sont illisibles (même des autres tables chargées avant).

J'ai essayé skip_innodb, la base se charge mais remplace le moteur par MyISAM.

Les .sql sont donc issus des backups de virtualmin et les fichiers sont corrects.

Ne trouvant rien de rien, j'aimerais savoir:
-si cette version de mysql est buggé pour les imports innoDB?
-Y'a t'il une option innoDB me permettant d'isoler le processus de mon dump pour que rien d'autre n'intervienne sur les tables? J'ai arrété apache pour qu'il n'y ait aucun accès par les sites.... Mais splash ! (J'ai chargé par virtualmin dans ce cas puisque phpmyadmin était out)

Il faudrait en gros désactiver innoDB sans arrêter mysql bien sur...

Je desespère de trouver une solutions et ça m'arrive rarement quitte à y passer du temps... Mais là, depuis dimanche 22 ...

y peu plus...

Merci

TBC_Ly0n · 01/05/2012, 18h17

show engines
show plugins

Que disent les logs ?

Steph_61 · 01/05/2012, 21h04

Bonjour et merci de prendre le temps ...

Code:

mysql> SHOW PLUGINS\G
*************************** 1. row ***************************
   Name: binlog
 Status: ACTIVE
   Type: STORAGE ENGINE
Library: NULL
License: GPL
*************************** 2. row ***************************
   Name: partition
 Status: ACTIVE
   Type: STORAGE ENGINE
Library: NULL
License: GPL
*************************** 3. row ***************************
   Name: ARCHIVE
 Status: ACTIVE
   Type: STORAGE ENGINE
Library: NULL
License: GPL
*************************** 4. row ***************************
   Name: BLACKHOLE
 Status: ACTIVE
   Type: STORAGE ENGINE
Library: NULL
License: GPL
*************************** 5. row ***************************
   Name: CSV
 Status: ACTIVE
   Type: STORAGE ENGINE
Library: NULL
License: GPL
*************************** 6. row ***************************
   Name: FEDERATED
 Status: DISABLED
   Type: STORAGE ENGINE
Library: NULL
License: GPL
*************************** 7. row ***************************
   Name: MEMORY
 Status: ACTIVE
   Type: STORAGE ENGINE
Library: NULL
License: GPL
*************************** 8. row ***************************
   Name: InnoDB
 Status: ACTIVE
   Type: STORAGE ENGINE
Library: NULL
License: GPL
*************************** 9. row ***************************
   Name: MyISAM
 Status: ACTIVE
   Type: STORAGE ENGINE
Library: NULL
License: GPL
*************************** 10. row ***************************
   Name: MRG_MYISAM
 Status: ACTIVE
   Type: STORAGE ENGINE
Library: NULL
License: GPL
10 rows in set (0.00 sec)

mysql> SHOW ENGINES\G
*************************** 1. row ***************************
      Engine: InnoDB
     Support: YES
     Comment: Supports transactions, row-level locking, and foreign keys
Transactions: YES
          XA: YES
  Savepoints: YES
*************************** 2. row ***************************
      Engine: MRG_MYISAM
     Support: YES
     Comment: Collection of identical MyISAM tables
Transactions: NO
          XA: NO
  Savepoints: NO
*************************** 3. row ***************************
      Engine: BLACKHOLE
     Support: YES
     Comment: /dev/null storage engine (anything you write to it disappears)
Transactions: NO
          XA: NO
  Savepoints: NO
*************************** 4. row ***************************
      Engine: CSV
     Support: YES
     Comment: CSV storage engine
Transactions: NO
          XA: NO
  Savepoints: NO
*************************** 5. row ***************************
      Engine: MEMORY
     Support: YES
     Comment: Hash based, stored in memory, useful for temporary tables
Transactions: NO
          XA: NO
  Savepoints: NO
*************************** 6. row ***************************
      Engine: FEDERATED
     Support: NO
     Comment: Federated MySQL storage engine
Transactions: NULL
          XA: NULL
  Savepoints: NULL
*************************** 7. row ***************************
      Engine: ARCHIVE
     Support: YES
     Comment: Archive storage engine
Transactions: NO
          XA: NO
  Savepoints: NO
*************************** 8. row ***************************
      Engine: MyISAM
     Support: DEFAULT
     Comment: Default engine as of MySQL 3.23 with great performance
Transactions: NO
          XA: NO
  Savepoints: NO
8 rows in set (0.00 sec)

En attendant, j'ai tenté de mettre mysql 5.1 de SID mais je crois que c'est pas une bonne idée pour le moment...

Je vais remettre tout au propre cette nuit et passer à skip-innoDB si je ne peu pas rentrer les dump.

Steph_61 · 01/05/2012, 21h22

Ah, j'oubliais... Rien dans les logs err de mysql!

SAP Team - Loup · 02/05/2012, 00h12

Et via quelle commande se fait cet export?

Steph_61 · 02/05/2012, 09h35

Et bien, j'ai tout essayé.
1-Via la restauration de virtualmin avec le backup complet
2-Via l'interface de virtualmin à partir d'un fichier sql local. (J'avais placé le .sql dans le dossier du serveur virtuel et d'autres fois avec un fichier dans /root)
3-Via phpmyadmin dans importer
4-via ssh avec

Code:

cd /home/VIRTUALSERVER
mysql --user=root --password=PASS database < database.sql

Comme il s'agissait d'une restauration du serveur après réinstallation complète, je les ai lancé à la suite les un des autre et jamais en simultané.
Les bases en myisam passent sans problème, celles qui ont quelques une ou toutes en innoDB, à un moment qui n'est jamais le même, coincent.
En fait, il me semble que c'est le fichier ibddata ou ib_log qui se retrouve corrompu, car sauf erreur de ma part les frm ne sont pas modifiés.
Et du coup, aucune table innoDB n'est plus lisible.

Je sais qu'il est possible de les récupérer avec Innodb_force_recovery à 4 mais le but est tout de même de pouvoir restaurer mes bases sans avoir à y passer une semaine

Désactiver innoDB m'embête car c'est dommage de s'en passer surtout si un script que j'aimerais installer dans le futur le requiert...

Le serveur est en prod (Réinstallé cette nuit, car avec ma tentative d'upgrader mysql pas SID, trop de choses à modifier...)

Une dernière chose: j'ai utilisé les dump en local dans MySQL Workbench 5.2 sur windows et tout c'est bien passé. Les fichiers sont donc bon, en tous cas pour sa version de mysql (5.5). C'est pourquoi je me dis que c'est lié à la version de mysql (5.0.51).

Les bases tournaient sur ce même server et avec la même config avant... C'est juste à l'insertion que ça veut pas

!
Merci

TBC_Ly0n · 02/05/2012, 14h50

Est-ce que tu as le même problème, quand après avoir importé la table en MyISAM, tu fais un alter table ... engine=InnoDB ?

Steph_61 · 02/05/2012, 15h47

Si je rentre les tables "à la main" en copier coller et une par une par phpmyadmin, j'ai pas eu de problème en ne le faisant que sur les plus grosses...

Je viens de passer une table innoDB en MyISAM avec opération de phpmyadmin puis retour par une requete : ALTER TABLE `llx_surveys_answers_summary` ENGINE = MYISAM et pas de plantage.

Il me semble que le problème n'intervienne que sur de grosses requêtes et pour l'instant uniquement quand je restaure un dump.

Pour alter table, je n'ai pas tenté de le faire en masse car je ne suis pas certain que les contraintes des tables initiales soient prises en compte et puis les faire une par une ... (à moins qu'il soit possible de faire une requête pour toutes les tables d'une base. Mais J'ai aussi une base de 175 table dont 155 seulement sont en myIsam à l'origine...ça peut vite être galère)

Ce que je cherche, c'est à faire rentrer le fichier entier d'un coup en innoDB ou MyISAM sans avoir à bidouiller mes sauvegardes après.

Je rappelle ma config au cas ou,
Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ruby/1.2.6 Ruby/1.8.7(2008-08-11) mod_ssl/2.2.9 OpenSSL/0.9.8g et mysql 5.0.51a le tout géré avec virtualmin (non pro)

01/05/2012, 13h33	#1
Steph_61 Membre Date d'inscription: mai 2009 Messages: 18	import Dump .sql innoDB sur mysql 5.0.51a corrompt aléatoirement ... Bonjour, Je suis sur un RPS mais mon problème n'est du à ce rps. C'est pourquoi je me permet de poster pour un souci mysql innodb. Je tente de restaurer les backups de virtualmin sans succès. Après avoir réinstallé tout plusieurs fois et testé le rps en mod rescue, je conclus que ce sont les tables de type innoDB qui posent problème. (J'ai essayé de passer à squeeze sur le rps. ça marche bien mais pas envie de passer en php 5.3 pour le moment. Cela n'a aucune incidence sur le problème des tables qui nous occupe) Donc les backups fonctionnent sauf pour les tables de type innoDB. Voila donc une semaine que je cherche comment restaurer des bases de données à partir de fichiers sql. La restauration des tables en MyISAM ne posent aucun problème, par contre les innoDB deviennent corrompues aléatoirement lors de la restauration: Je charge le fichier sql et l'exécute puis d'un coup les innoDB sont illisibles (même des autres tables chargées avant). J'ai essayé skip_innodb, la base se charge mais remplace le moteur par MyISAM. Les .sql sont donc issus des backups de virtualmin et les fichiers sont corrects. Ne trouvant rien de rien, j'aimerais savoir: -si cette version de mysql est buggé pour les imports innoDB? -Y'a t'il une option innoDB me permettant d'isoler le processus de mon dump pour que rien d'autre n'intervienne sur les tables? J'ai arrété apache pour qu'il n'y ait aucun accès par les sites.... Mais splash ! (J'ai chargé par virtualmin dans ce cas puisque phpmyadmin était out) Il faudrait en gros désactiver innoDB sans arrêter mysql bien sur... Je desespère de trouver une solutions et ça m'arrive rarement quitte à y passer du temps... Mais là, depuis dimanche 22 ... y peu plus... Merci

01/05/2012, 18h17	#2
TBC_Ly0n Membre Date d'inscription: juillet 2007 Messages: 7 462	Re : import Dump .sql innoDB sur mysql 5.0.51a corrompt aléatoirement ... show engines show plugins Que disent les logs ? __________________ (\__/) Ce lapin veut conquerir le monde ! Aidez-le à (='.'=) atteindre son but en le mettant dans votre signature. (")_(") Besoin d'infogérance ? Hebergement-pro.org

01/05/2012, 21h22	#4
Steph_61 Membre Date d'inscription: mai 2009 Messages: 18	Re : import Dump .sql innoDB sur mysql 5.0.51a corrompt aléatoirement ... Ah, j'oubliais... Rien dans les logs err de mysql!

02/05/2012, 00h12	#5
SAP Team - Loup Membre Date d'inscription: février 2009 Messages: 1 095	Re : import Dump .sql innoDB sur mysql 5.0.51a corrompt aléatoirement ... Et via quelle commande se fait cet export?

02/05/2012, 09h35	#6
Steph_61 Membre Date d'inscription: mai 2009 Messages: 18	Re : import Dump .sql innoDB sur mysql 5.0.51a corrompt aléatoirement ... Et bien, j'ai tout essayé. 1-Via la restauration de virtualmin avec le backup complet 2-Via l'interface de virtualmin à partir d'un fichier sql local. (J'avais placé le .sql dans le dossier du serveur virtuel et d'autres fois avec un fichier dans /root) 3-Via phpmyadmin dans importer 4-via ssh avec Code: cd /home/VIRTUALSERVER mysql --user=root --password=PASS database < database.sql Comme il s'agissait d'une restauration du serveur après réinstallation complète, je les ai lancé à la suite les un des autre et jamais en simultané. Les bases en myisam passent sans problème, celles qui ont quelques une ou toutes en innoDB, à un moment qui n'est jamais le même, coincent. En fait, il me semble que c'est le fichier ibddata ou ib_log qui se retrouve corrompu, car sauf erreur de ma part les frm ne sont pas modifiés. Et du coup, aucune table innoDB n'est plus lisible. Je sais qu'il est possible de les récupérer avec Innodb_force_recovery à 4 mais le but est tout de même de pouvoir restaurer mes bases sans avoir à y passer une semaine Désactiver innoDB m'embête car c'est dommage de s'en passer surtout si un script que j'aimerais installer dans le futur le requiert... Le serveur est en prod (Réinstallé cette nuit, car avec ma tentative d'upgrader mysql pas SID, trop de choses à modifier...) Une dernière chose: j'ai utilisé les dump en local dans MySQL Workbench 5.2 sur windows et tout c'est bien passé. Les fichiers sont donc bon, en tous cas pour sa version de mysql (5.5). C'est pourquoi je me dis que c'est lié à la version de mysql (5.0.51). Les bases tournaient sur ce même server et avec la même config avant... C'est juste à l'insertion que ça veut pas! Merci

02/05/2012, 14h50	#7
TBC_Ly0n Membre Date d'inscription: juillet 2007 Messages: 7 462	Re : import Dump .sql innoDB sur mysql 5.0.51a corrompt aléatoirement ... Est-ce que tu as le même problème, quand après avoir importé la table en MyISAM, tu fais un alter table ... engine=InnoDB ? __________________ (\__/) Ce lapin veut conquerir le monde ! Aidez-le à (='.'=) atteindre son but en le mettant dans votre signature. (")_(") Besoin d'infogérance ? Hebergement-pro.org

02/05/2012, 15h47	#8
Steph_61 Membre Date d'inscription: mai 2009 Messages: 18	Re : import Dump .sql innoDB sur mysql 5.0.51a corrompt aléatoirement ... Si je rentre les tables "à la main" en copier coller et une par une par phpmyadmin, j'ai pas eu de problème en ne le faisant que sur les plus grosses... Je viens de passer une table innoDB en MyISAM avec opération de phpmyadmin puis retour par une requete : ALTER TABLE `llx_surveys_answers_summary` ENGINE = MYISAM et pas de plantage. Il me semble que le problème n'intervienne que sur de grosses requêtes et pour l'instant uniquement quand je restaure un dump. Pour alter table, je n'ai pas tenté de le faire en masse car je ne suis pas certain que les contraintes des tables initiales soient prises en compte et puis les faire une par une ... (à moins qu'il soit possible de faire une requête pour toutes les tables d'une base. Mais J'ai aussi une base de 175 table dont 155 seulement sont en myIsam à l'origine...ça peut vite être galère) Ce que je cherche, c'est à faire rentrer le fichier entier d'un coup en innoDB ou MyISAM sans avoir à bidouiller mes sauvegardes après. Je rappelle ma config au cas ou, Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ruby/1.2.6 Ruby/1.8.7(2008-08-11) mod_ssl/2.2.9 OpenSSL/0.9.8g et mysql 5.0.51a le tout géré avec virtualmin (non pro)

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email