[Sauvegarde] SELECT * INTO OUTFILE ou bien Mysqldump ?

Bonjour,

J'ai toujours fait mes sauvegardes avec un mysqldump pour produire une sauvegarde au format sql mais dans un message, omiossec à proposer de faire ces sauvegardes à l'aide de "SELECT * INTO OUTFILE" et de récupérer le tout avec "LOAD DATA INFILE ..."

Le problème est que je ne vois pas trop qu'est ce que ca peut apporter comme avantages.
Déjà du point de vue de la taille de la sauvegarde, la sortie de mysqldump est assez proche des informations minimales donc il n'y pas d'efforts de faisable pour cela
enfin je vois surtout un inconvénient : il y un fichier par table ce qui peut être embétant quand on veut faire des sauvegardes automatiques de la base entière

Les avantages sont simple avec SELECT * INTO OUTFILE ou MySqlDUMP --tab.
Si l'on créer un fichiers sql l'on vas avoir autant de commande insert qu'il ya d'enregistrement dans les tables se qui est lourd, generes des erreurs et augmente la charge du serveur pour rien.
Utilisé un format de fichier texte permet de s'affranchir de ces soucis en utilisant un fichier par tables (permet de ne restaurer qu'une table lorsque celle si est marqué comme étant corrompue par example). Permet de n'avoir qu'une instruction (Load Data), La restauration est rapide, simple et ne génere pas d'erreur, en particulier l'on peut désactivé les contrainte de la base.
Ce genre de format et particulièrement adapté lorsque l'on a des gros volume de données. Là où un fichier SQL peut mettre plusieur minutes voir plusieur heure à ce charger, un fichier text sera prise ne charge tres rapidement (23 s pour 48 Mo contre 24 minutes avec un fichiers SQL).

Le format SQL est quant à lui assez verbeux

23 secondes contre 24 minutes ? 8O 8O
merci, j'étais à 2 doigts de commencer à programmer un système de sauvegarde automatique qui utilisait les fichiers sql

je me lance dans les tests et d'ici 2-3 jours je vous dit ce que ca donne à la suite de ce sujet

Suite des événements :
15/04/2004 : j'avais loupé l'informations qui disait que le "select .. outfile" créait le fichier sur le serveur donc ce n'est pas ce que je veux. idem pour "mysqlump --tab" donc je vais me tourner vers "mysql -e"
affaire à suivre ....

intéressant effectivement.

par contre le dump présente les avantages suivants :
- infos sur la structure des tables
- tables verouillées (en write) pendant le dump

mais bon, ça peut très bien se reproduire dans un script...

en fait comme je veux faire de la sauvegarde régulière sur une base qui ne changera pas de structure, je n'ai pas besoin de la structure
par contre il y a un "inconvénient" (de mon point de vue) avec la méthode "tab" c'est qu'il y a un fichier par table et donc cela complique la récupération automatique et ca fait une commande système par table (j'ai ai déjà plus de 10 en ce moment)
de plus la sauvegarde se fera en heures creuses donc je peux utiliser "mysqldump" sans problème mais je vais prevoir ma classe pour que je puisse utiliser l'autre méthode plus tard si jamais la base est trop grosse

pour info voila les commandes que j'ai testé

Code:

---

1 2 3

mysql -e 'SELECT * FROM articles' -N -ptest -utest base > test.txt   LOAD DATA LOCAL INFILE '/chemin/test.txt' INTO TABLE articles

---

Citation:

---

Envoyé par chicobra

intéressant effectivement.

par contre le dump présente les avantages suivants :
- infos sur la structure des tables
- tables verouillées (en write) pendant le dump

mais bon, ça peut très bien se reproduire dans un script...

---

L'on peut verouiller les tables en sql
de plus MySqlDump dipose aussi du format -tab (produit 2 fichiers par tables un de sturcture, un de données)

promis dans ma classe je prévois l'utilisation de l'autre technique :-)

merci omiossec pour toutes ces informations

A noter qu'on peut exécuter un mysqldump sur une base distante :
mysqldump --host=serveur-distant --user=testor --password=testor --opt --all --result-file=/tmp/dump base-distante

Ca marche nickel, je viens de tester. Bien sûr, il faut que l'user testor ait les droits nécessaires sur le serveur distant.
Par contre je le tenterais peut-être pas avec par exemple un client v3 et un serveur v4... (?)

Bonjour,
j'ai un problème de localisation de fichiers lors des commandes SELECT INTO OUTFILE :

SELECT * FROM Matable INTO OUTFILE 'Chemin et nom du fichier récepteur.txt'
j'avais fait des essais sous windows, et effectivement, si l'on donne un
disque et un chemin d'accès, ça fonctionne :
SELECT * FROM CLIENTS INTO OUTFILE 'D:\\NOMAGE\DUMPCLI.txt' crée bien le fichier DUMPCLI.TXT dans le repertoire D:\NOMADE.
Sous Linux, NADA. ça crée un fichier nommé 'D:\\NOMAGE\DUMPCLI.txt, dans le répertoire /var/lib/mysql.
ça ne m'arrange pas du tout.
Comme je dois importer ces fichiers sur une base locale, ça m'oblige à gérer Samba pour partager le rep /var/lib/mysql (un peu dangereux quand même).

Connaissez-vous une parade ?
Merci

:?: tu veux créer ton fichier de sortie DUMPCLI.txt dans D:\NOMAGE sur ton serveur LINUX ?!? 8O hum, tu vois pas un pb là ?...

Non, Non : c'était un exemple. Comme je l'explique, cette commande fonctionne avec Mysql windows 4.0.18.
Ce qui me gène, c'est que sous linux, quelque soit le nom et le répertoire du fichier txt vers lequel on veut exporter, il est toujours créé dans le rep /var/lib/mysql.
J'aimerais savoir si je peux créer le fichier dans un autre répertoire, car ça me gène de partager le rep /var/lib/mysql avec les droits en écriture, en plus :cry:
merci de t'intéresser

Non non, tu peux produire ton fichier de sortie où tu veux !
mysql> select id, nom, prenom into outfile '/tmp/tst' from user;
fonctionne parfaitement bien : il extrait les données dans le fichier tst, dans /tmp

Dans ton cas, mysql ne doit pas trouver pas de chemin valide, et crée donc le fichier dans /var/lib/mysql, c'est-à-dire l'emplacement de l'exécutable mysql ! C'est la seule explication... C'est donc pas un pb avec mysql, mais de syntaxe shell.

:D
Absolument !
je peux donc gérer ces fichiers textes dans un répertoire non sensible.
Merci beaucoup.

Salut !!
J'aimerai un peu plus de précisions si possible concernant ton code mathix

Code:

---

1 2 3 4

mysql -e 'SELECT * FROM articles' -N -ptest -utest base > test.txt   LOAD DATA LOCAL INFILE '/chemin/test.txt' INTO TABLE articles

---

Je cherche moi aussi à faire un dump de ma base, base qui tend à faire plusieurs dizaines de Mo donc cette solution m'intéresse.

J'ai essayé le "mysql -e 'SELECT * FROM articles' -N -ptest -utest base > test.txt " dans une page PHP mais çà me sort une erreur :

Citation:

---

Parse error: parse error, unexpected T_CONSTANT_ENCAPSED_STRING

---

Vous moquez pas hein :roll:
Merci d'avance. ++

bah oui, c'est une ligne de commande shell, ça...

si tu veux vraiment passer par php, utilise system()
mais attention, l'intérêt de cette méthode, c'est de récupérer les données sur ton serveur (où y'a php) à partir d'un autre serveur (où y'a mysql)...

sinon tu peux simplement de connecter sur le serveur en question, et écrire les données dans un fichier sur ton serveur

tt ca est tt a fai interessan quelqu'un a crée un script en php pour sauvagarder les table dans des fichiers??
ou si non kell son les comande utilisable en php pour que je me fasse mon script
merci
GJ

Je rebondis sur une discussion vieille de 7 ans ! mais qui m'intéresse : je voudrais exporter une base MySQL en SQL (pas en ligne de commande, ni avec phpMyAdmin). Si j'ai bien compris, on peut utiliser une commande du type

Code:

---

SELECT * FROM Matable INTO OUTFILE 'Chemin et nom du fichier récepteur.txt'

---

(pour exporter une table), mais quand je fais l'essai, que ce soit sur un répertoire sur le serveur ou sur mon disque, j'ai un message de ce type :

Citation:

---

Access denied for user 'dbo---'@'%' (using password: YES)

---

y a-t-il une solution ?

Vieille question aussi, mais ce message d'erreur indique que ton hébergeur n'autorise pas l'utilisation d'INTO FILE dans les requêtes SQL. C'est souvent un blocage qui est fait, notamment sur les mutualisés.

Cordialement :).