mysqldump: Got errno 32 à écrire

J'ai utilisé ce script depuis des années sur mon VPS. Et il marche encore.

DBLIST=`mysql -uroot -pROOT_PASSWORD -ANe"SELECT GROUP_CONCAT(schema_name) FROM information_schema.schemata WHERE schema_name NOT IN ('information_schema','performance_schema')" | sed 's/,//g'`
MYSQLDUMP_OPTIONS="-uroot -pROOT_PASSWORD --single-transaction --routines --triggers"
BACKUP_DEST="/home/backup/db/"
for DB in `echo "${DBLIST}"`
do
    mysqldump ${MYSQLDUMP_OPTIONS} ${DB} | gzip > ${BACKUP_DEST}/${DB}.sql.gz &
done
wait
tar -czvf /home/backup/db2/`date +\%G-\%m-\%d`_db.tar.gz ${BACKUP_DEST}

Maintenant, je suis de passage à un autre hébergement. Je suis d'essayer d'utiliser le même script (bien sûr j'ai changé ROOT_PASSWORD avec les nouveaux pouvoirs) mais je ne sais pas pourquoi j'obtiens ceci:

mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write
mysqldump: Got errno 32 on write

InformationsquelleAutor MultiformeIngegno | 2014-03-09

36
```
20:47:59 0 ~] $ perror 32
OS error code  32:  Broken pipe
```
Si errno 32 est "broken pipe". Vous êtes à la tuyauterie de la commande mysqldump sortie de gzip , donc cela signifie gzip résilié avant la commande mysqldump fini. Pourrait par exemple être parce que votre disque est plein, ou gzip dépassé tout max de temps CPU/utilisation de votre hôte a mis en place.
- Uhm.. disque n'est pas plein et le PROCESSEUR est libre. 🙁
- Vous nous dites que vous utilisez un VPS, avez-vous vérifié qu'ils n'ont pas des limites en place ? Il est assez commun pour un VPS pour limiter l'utilisation de votre CPU, et de tuer les processus qui utilisent trop de ressources PROCESSEUR. De toute façon, vous avez maintenant une indication que gzip est se faire tuer, de sorte que vous pouvez vous amuser avec, par exemple, ne PAS rediriger la sortie vers gzip, mais directement à un fichier et de voir comment ça se passe.
- Ressusciter de noter que, en effet, une limite de CPU était ma question sur AWS. Je l'ai résolu en niceing le dump.
- Si le disque n'est pas plein et le PROCESSEUR est libre, essayez ceci: créer une base de fichier texte, et exécutez la commande gzip sur elle, vous vous rendrez vite compte de ce qui est mauvais (la façon dont j'ai pensé à elle d'avoir le même message d'erreur)
InformationsquelleAutor nos
9

Assurez-vous que le dossier /home/sauvegarde/db/(que vous utilisez pour stocker la sauvegarde) a écrire autorisation d'accès (vérification rapide: essayez d'utiliser la commande chmod -R 777 sur le dossier et exécutez le script pour être sûr).
- +1 C'était le problème dans mon cas, le dossier doit avoir un CHMOD 0777, dans mon cas, il avait 0755, donc ça dépend des utilisateurs mysql droit
InformationsquelleAutor Francisco De La Fuente
8

J'ai eu le même problème à cause de quelques fautes de frappe.
1. J'ai tapé le nom de la db utilisateur de manière incorrecte. J'ai eu "db_user_1" lorsqu'il était vraiment "db_user1".
2. Après la pipe, j'ai oublié l' > dans gzip > myfile.tar.gz.
Mais je vous recommande de mettre à niveau vers MySQL 5.6+ le plus vite possible, de sorte que vous pouvez arrêter d'exposer la base de données de mots de passe d'autres utilisateurs.

Découvrez cette réponse sur StackOverflow.

InformationsquelleAutor Buttle Butkus
2

Confrontés au même problème.
Je ne sais pas exactement pourquoi, mais si vous ajoutez de l'utilitaire de PV a conclu que toutes les œuvres. Peut-être que cela dépend de votre shell bash/sh.
```
sudo apt-get install pv
```
PipeViewer un très utile utilitaire, il vous permet de visualiser les processus d'écriture sur le disque, par exemple.

Script par exemple
```
mysqldump ${MYSQLDUMP_OPTIONS} ${DB} | gzip | pv > ${BACKUP_DEST}/${DB}.sql.gz
```
InformationsquelleAutor PRIHLOP
2

J'ai été en utilisant mysqldump de la CLI et essayer de tuyau pour gzip et/ou d'un fichier et d'obtenir une erreur "autorisation refusée".

Même que sudo, j'ai été faire une erreur, car bien que j'étais en train de mysqldump comme sudo, la conduite était encore en train d'essayer d'utiliser le compte d'utilisateur, j'ai été connecté à la coquille comme d'écrire la sortie. Dans ce cas, ma coquille compte d'utilisateur n'a pas les autorisations d'écrire dans le répertoire cible.

Pour contourner ce problème, vous pouvez utiliser le tee commande en conjonction avec sudo:
```
mysqldump --single-transaction --routines --events --triggers --add-drop-table --extended-insert -u backup -h 127.0.0.1 -p --all-databases | gzip -9 | sudo tee /var/backups/sql/all_$(date +"%Y_week_%U").sql.gz > /dev/null
```
La | sudo tee /var/backups/... est ce qui nous permet de pipe à un répertoire accessible en écriture root. Le > /dev/null supprime tee de dumping sa sortie directement à l'écran.
- grâce alexw, qui fonctionne très bien!
InformationsquelleAutor alexw
1

Vérifier si le dossier existe pas dans votre région, /home/sauvegarde/db/

si non, créer chaque sous-dossier.

Commande:
mkdir /home/sauvegarde/db/

puis exécutez votre commande à nouveau.
- Ce fut aussi le problème pour nous. J'étais en train de Deployer sur un nouvel environnement et il n'était pas autorisé à créer des dossiers. Quand j'ai créé le dossier manuellement, il s'est bien passé dans les passages suivants.
InformationsquelleAutor Santiago Medina Chaverra
1

J'ai été surpris, je ne pouvais pas faire un dump de ma DB, j'ai été capable de le faire la veille. Maintenant, j'ai été faire cette erreur.

Comme nos dit, le message d'erreur signifie bris de tuyau, ce qui signifie que la sortie ne peut pas être écrites sur le disque. Dans mon cas, mon SSH de l'utilisateur avait pas l'autorisation d'écrire dans le dossier, j'ai été ciblage dans mon mysqldump instruction.

Vous pouvez la sortie de votre cliché dans votre /home/your_user répertoire de voir ce que vous obtenez toujours la même erreur. Ce faisant résolu mon problème.

InformationsquelleAutor Brac
1

Errno 32 est "broken pipe" de sorte que toute erreur qui se passe avec le tuyau de destination (dans ce cas, gzip) sera la cause de errno 32. Si la structure de répertoire a changé et votre ${BACKUP_DEST} ne fait plus référence à un répertoire qui existe ce problème pourrait se produire.

Je déboguer ce par la tuyauterie quelque chose à votre commande gzip ou de la création d'une sauvegarde non compressée n'impliquant pas de gzip.

InformationsquelleAutor reor
1

Son si vieux sujet, mais je suis confronté à ce problème et de trouver que:

Mon nom de fichier: db_26/03.tar.gz son lever une erreur comme ci-dessus; mais lorsque j'utilise: db.tar.gz il n'y a pas d'erreur.

De sorte que vous devriez vérifier le nom de votre fichier
- Je suis +1-ing-ce parce qu'il a travaillé pour nous, mais j'aimerais vraiment que quelqu'un pourrait expliquer POURQUOI il la corrige. Pour nous, l'ancien nom de fichier fonctionne si la commande a été exécuté par cron, mais pas dans la ligne de commande.
- Vous avez un / barre oblique dans votre nom de fichier, de sorte qu'il est d'essayer d'utiliser 03.tar.gz à l'intérieur de l' (inexistante) répertoire db_26
InformationsquelleAutor Muhammet Arslan
0

J'ai vu cette erreur, lorsque la tuyauterie mysqldump sortie de s3cmd. Il a été causé par l'utilisation de la mauvaise version de s3cmd. Sur Ubuntu Trusty et Debian Wheezy, la version de paquet de s3cmd commande ne prend pas en charge l'entrée standard stdin (parce qu'ils ont la version 1.1.0).

InformationsquelleAutor Ryan
0

Ce qui m'a aidé avec ce problème est
```
export LANG=C
```
avant l'exécution de la commande mysqldump par https://github.com/netz98/n98-magerun/issues/771

InformationsquelleAutor Vladimir Strugatsky

Vous devez vous connecter pour publier un commentaire.