Discussion :

[globule2]

Bonjour,

Je rencontre un très gros problème avec la sauvegarde des bases MySQL
J'ai un gros projet en VB6, qui utilise MySQL en client serveur (réseaux Locaux) via MySQL Essential (derniere version). Mes bases sont en InnoDB

En effet, j'utilise MySQL dump.
mysqldump --opt --hex-blob -hlocalhost " -uUserName -ppassword MABASE > SVG.SQL
et je restaure avec
mysql -hlocalhost -uUserName -pPassword MABASE<SVG.SQL

Ca fonctionne

Sauf sur des grosses bases (1G0 ou plus, c'est aléatoire)
J'obtiens l'erreur suivante lors de la restauration
error 2006 (HY000) at line 1278 : MySQL server has gone away

J'ai essayé de modifier beaucoup de paramètres dans le fichier My.ini (déconnexion après 24h, taille max d'un blob ...), mais cela ne change pas le problème

C'est situation est catastrophique, car mes clients utilisent notre logiciel dans un cadre professionnel, et cela veux dire que certains travaillent sans sauvegarde valide.

J'ai également essayé de sauvegarder le répertoire DATA. Mais la aussi je rencontre beaucoup de problème lorsque je veux le restaurer sur un autre poste.
Parfois, ça marche, parfois non
Souvent je suis également obligé de copier le my.ini pour que ça fonctionne. Et par exemple la copie du répertoire data et du fichier mi.ini d'un poste XP en 2000 ne marche pas (mysql ne se lance plus sur 2000 après cette opération).

[Antoun]

prévoir des rechargements intégraux n'est pas un mécanisme de production normal ; le faire sous forme de dump SQL est encore pire.

Dans l'immédiat, je te conseille d'essayer des dumps table par table plutôt que de l'ensemble de la base. A terme, tu devrais mettre en place une sauvegarde incrémentale sous forme binaire, ou (mieux) une réplication.

[globule2]

La sauvegarde sous forme binaire pose de nombreux problemes
Il faut arreter les serveur MYSQL. Cela pose beaucoup de pb a ma clientelle.
Ils faut egalement tenir compte de l'OS, du my.ini, bref ce n'est pas une solution fiable.
MySQL conseille les DUMP, je voudrais juste savoir pourquoi ca ne fonctionne pas sur des tres grosses bases. Peut etre est-ce simplement un parametrage dans le my.ini (par exemple requete trop longue)
Je pense que le dump fonctionne, c'est la restauration qui ne fonctionne pas

[Antoun]

Techniquement, le dump fonctionne ; simplement il n'est pas très performant. Sur des gros volumes avec des petits serveurs, il n'est pas très étonnant qu'il plante à la restauration.

MySQL AB estime par exemple que le LOAD DATA INFILE est environ 20 fois plus rapide que la restauration d'un dump SQL.

Enfin, ce qui est aberrant, c'est de prévoir un rechargement intégral sur un tel volume. Normalement, on n'enregistre que les modifications du jour pour les reproduire sur la sauvegarde ; cela se fait soit "à la main" avec des triggers, soit (de préférence) en mettant en place une réplication à partir du log binaire. Cf http://dev.mysql.com/doc/refman/5.0/en/replication.html.

[globule2]

Oui, mais je suis dans le cas d'une application professionnelle, qui n'est pas sur le NET, mais sur differents Windows.
Les utilisateurs peuvent copier leurs bases sur leur PC portables, etc ...
C'est pour cela que j'ai besoin de copier les bases.
Ce n'est pas le Dump qui echoue, mais la restauration.
LOAD DATA INFILE me permet de lire dans un fichier texte des données. Mais dans ce cas comment proceder a la sauvegarde ?

[Antoun]

Oui, mais je suis dans le cas d'une application professionnelle, qui n'est pas sur le NET, mais sur differents Windows.

Raison de plus !

Les utilisateurs peuvent copier leurs bases sur leur PC portables, etc ...
C'est pour cela que j'ai besoin de copier les bases.
Ce n'est pas le Dump qui echoue, mais la restauration.

j'ai bien compris, mais elle échoue parce que le dump SQL implique une restauration lente.

LOAD DATA INFILE me permet de lire dans un fichier texte des données. Mais dans ce cas comment proceder a la sauvegarde ?

SELECT INTO OUTFILE