Discussion :

[lucho.66]

Bonjour,
nous avons intégré dans une appli une sauvegarde se basant sur mysqldump. On effectue un dump pour chaque table.
Pour la restauration on lance un par un chaque script ainsi généré.

Jusqu'ici tout va bien...

Sauf que chez un client, une table atteint environ 3 000 000 d'enregistrements et qu'en restaurant la base, je n'en retrouve que 500 000.

La taille du fichier généré pour cette table est de ... 1,4Go, ce qui n'est pas pour faciliter la recherche d'erreurs dans le script.

Visiblement, l'import plante en plein milieu à cause d'une erreur dans les requêtes insert du script. En creusant, j'ai pu constater ceci:

dans les valeurs à ajouter, un "$" s'est substitué à une ",":

(....'2008-11-06 17:49:00'$18,'Soutirage',1,....)
au lieu de
'2008-11-06 17:49:00',18,'Soutirage',1,

un ":" s'est substitué à une valeur numérique ;

,353822,2203,2:53,4177,'20081106174904597',
au lieu de
,353822,2203,2953,4177,'20081106174904597',

ou encore un "/" s'est substitué à une "cote" (et au passage un g à la place d'un "o")

,'2008-11-06 17:49:00',18,'Sgutirage/,1,
au lieu de
,'2008-11-06 17:49:00',18,'Soutirage',1,

ces substitutions ne sont pas systématiques sur tout le fichier... et il ne s'agit pas de caractère d'échappement...
Est ce que quelqu'un a déjà eu ce genre de problème?
Est ce que ce problème peut être dû au volume des données trop important?
Si oui, y a t il moyen de saucissonner le "dump" en blocs de n enregistrements ?

[Sivrît]

Bonjour,
nous avons intégré dans une appli une sauvegarde se basant sur mysqldump. On effectue un dump pour chaque table.
Pour la restauration on lance un par un chaque script ainsi généré.

Note à part, ça ne risque pas de poser des problèmes de cohérence ? Genre sauvegarde de la table A, ajouts liés dans les tables A et B, et sauvegarde de la table B ?

Sauf que chez un client, une table atteint environ 3 000 000 d'enregistrements et qu'en restaurant la base, je n'en retrouve que 500 000.

Ça laisse penser qu'il y a eu une erreur. Pour vérifier que la sauvegarde est déjà bien faite, il est possible de chercher la mention "dump completed" (ou un truc dans le genre) sur la dernière ligne avec un "tail".

Sinon, en cas de problème à la restitution, il devrait y avoir une erreur de la part de MySQL.

ces substitutions ne sont pas systématiques sur tout le fichier... et il ne s'agit pas de caractère d'échappement...
Est ce que quelqu'un a déjà eu ce genre de problème?
Est ce que ce problème peut être dû au volume des données trop important?
Si oui, y a t il moyen de saucissonner le "dump" en blocs de n enregistrements ?

Normalement la taille n'est pas un problème. Les gros volumes sont surtout problématique avec mysqldump car, arrivé à un certain volume, la restauration devient très/trop longue.

J'ai des dumps très gros et je n'ai eu qu'un cas de dump invalide, un caractère corrompu. Je soupçonne un problème de transmission. Plus c'est gros, plus il y a de risque de corruption à cause d'un disque défectueux ou d'un réseau de mauvaise qualité. Avec autant d'erreurs, je m'inquièterais peut-être pour le disque.

Ça vaudrait peut-être la peine de calculer des checksums des dumps, pour vérifier que le stockage et le transfert ne pose pas problème.


Pour le découpage, il y aurait peut-être mk-parallel-[dump|restore] dans Maatkit. Il est plutôt fait pour gagner du temps mais ça pourrait peut-être le faire...