web-dev-qa-db-fra.com

mysqldump: Vous avez obtenu le code d'erreur 32 sur l'écriture

J'ai utilisé ce script pendant des années sur mon VPS. Et ça 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 passe à un autre hébergement. J'essaie d'utiliser le même script (bien sûr, j'ai changé ROOT_PASSWORD avec les nouvelles informations d'identification), 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
mysqlubuntumysqldump
29
MultiformeIngegno
20:47:59 0 ~] $ perror 32
OS error code  32:  Broken pipe

Donc, errno 32 est un "tuyau cassé". Vous dirigez la sortie de mysqldump vers gzip, cela signifie donc que gzip s'est terminé avant que mysqldump ne soit terminé. Pourrait par exemple Cela est dû au fait que votre disque est saturé ou que gzip a dépassé le temps processeur/utilisation maximum que votre hôte a mis en place.

35
nos

Assurez-vous que le dossier/home/backup/db/(que vous utilisez pour stocker la sauvegarde) dispose d'un droit d'accès en écriture (vérification rapide: essayez d'utiliser chmod -R 777 sur ce dossier et exécutez le script pour vous en assurer).

9
Francisco De La Fuente

J'ai eu le même problème en raison de quelques fautes de frappe.

  1. J'ai mal saisi le nom de l'utilisateur de la base de données. J'ai eu "db_user_1" quand il était vraiment "db_user1".

  2. Après le tuyau, j'ai oublié le > dans gzip > myfile.tar.gz.

Mais je vous recommande de mettre à niveau vers MySQL 5.6+ dès que possible, afin que vous puissiez cesser d'exposer les mots de passe de base de données à d'autres utilisateurs.

Découvrez cette réponse sur StackOverflow.

8
Buttle Butkus

Face au même problème ... Je ne sais pas pourquoi, mais si vous ajoutez l'utilitaire PV conclu que tout fonctionne. Peut-être que cela dépend de votre Shell bash/sh.

Sudo apt-get install pv

PipeViewer est un utilitaire très utile, il vous permet de visualiser les processus d’écriture sur disque, par exemple.

Script par exemple

mysqldump ${MYSQLDUMP_OPTIONS} ${DB} | gzip | pv > ${BACKUP_DEST}/${DB}.sql.gz
2
PRIHLOP

C'est un sujet tellement ancien, mais je suis confronté à ce problème et constate que:

Mon nom de fichier: db_26/03.tar.gz sa générant une erreur comme ci-dessus; mais quand j'utilise: db.tar.gz il n'y a pas d'erreur.

Donc, vous devriez vérifier votre nom de fichier

1
Muhammet Arslan

Errno 32 étant un "tuyau cassé", toute erreur survenant avec la destination du tuyau (dans ce cas gzip) provoquera errno 32. Si la structure du répertoire a été modifiée et que votre ${BACKUP_DEST} ne fait plus référence à un répertoire existant, ce problème se produirait.

Je déboguerais ceci en ajoutant quelque chose à votre commande gzip ou en créant une sauvegarde non compressée ne faisant pas appel à gzip.

1
reor

Vérifiez si le dossier existe à votre emplacement,/home/backup/db /

si non, créez chaque sous-dossier.

Commande: Mkdir/home/backup/db /

puis relancez votre commande.

1
Santiago Medina Chaverra

J'étais surpris de ne pas pouvoir faire un vidage de ma DB, j'ai pu le faire la veille. Maintenant, j'ai eu cette erreur.

Comme nos a déclaré, le message d'erreur signifie canal cassé, ce qui signifie que la sortie ne peut pas être écrite sur le disque. Dans mon cas, mon utilisateur SSH n'était pas autorisé à écrire dans le dossier que je visais dans mon instruction mysqldump.

Vous pouvez sortir votre vidage dans votre répertoire/home/votre_utilisateur pour voir que vous obtenez toujours la même erreur. Cela a résolu mon problème.

1
Brac

Je voyais cette erreur lors du piping de la sortie de mysqldump vers s3cmd. Cela a été causé par l’utilisation de la mauvaise version de s3cmd. Sur Ubuntu Trusty et Debian Wheezy, la version empaquetée de la commande s3cmd ne prend pas en charge stdin (car ils ont la version 1.1.0). 

0
Ryan

Ce qui m'a aidé avec ce problème est

export LANG=C

avant d’exécuter mysqldump par https://github.com/netz98/n98-magerun/issues/771

0
Vladimir Strugatsky

J'utilisais mysqldump de la CLI et j'essayais de canaliser vers gzip et/ou un fichier et d'obtenir une erreur "autorisation refusée". 

Même en tant que Sudo, j'obtenais une erreur car bien que j'utilisais mysqldump en tant que Sudo, le tube essayait toujours d'utiliser le compte d'utilisateur pour lequel j'étais connecté au shell pour écrire le résultat. Dans ce cas, mon compte utilisateur Shell n’était pas autorisé à écrire dans le répertoire cible.

Pour résoudre ce problème, vous pouvez utiliser la commande tee 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

Le | Sudo tee /var/backups/... est ce qui nous permet de diriger vers un répertoire uniquement accessible en écriture par root. Le > /dev/null empêche tee de vider sa sortie directement à l'écran.

0
alexw