mysqldump: Got errno 32 à l’écriture

J’ai utilisé ce script pendant des années sur mon VPS. Et ça marche toujours.

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 --sortingggers" 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

 20:47:59 0 ~] $ perror 32 OS error code 32: Broken pipe

Donc, errno 32 est “pipe cassée”. Vous faites passer la sortie de mysqldump à gzip , donc cela signifie que gzip est terminé avant que mysqldump ne soit terminé. Peut-être par exemple parce que votre disque est plein ou que gzip a dépassé tout temps / utilisation maximum de processeur que votre hôte a mis en place.

Assurez-vous que le dossier / home / backup / db / (que vous utilisez pour stocker la sauvegarde) dispose d’une autorisation d’access en écriture (pour une vérification rapide: essayez d’utiliser chmod -R 777 sur ce dossier et exécutez le script pour vous en assurer).

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 firebase database. 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 passer à mysql 5.6+ dès que possible, afin de ne plus exposer les mots de passe des autres utilisateurs.

Découvrez cette réponse sur stackoverflow.

Face au même problème Je ne sais pas pourquoi exactement, mais si vous ajoutez l’utilitaire PV conclu que tous les travaux. 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 par exemple de visualiser les processus d’écriture sur disque.

Script par exemple

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

C’est tellement vieux sujet, mais je suis confronté à ce problème et trouve que:

mon nom de fichier: db_26 / 03.tar.gz il soulève une erreur comme ci-dessus; mais quand je fais: db.tar.gz il n’y a pas d’erreur.

Donc, vous devriez vérifier votre nom de fichier

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

Si non, créez chaque sous-dossier.

Commande: mkdir / home / backup / db /

puis relancez votre commande.

J’ai été surpris de ne pas pouvoir faire un dump de ma DB, j’ai pu le faire la veille. Maintenant, je recevais cette erreur.

Comme nous l’avons déjà dit, le message d’erreur signifie «Pipe brisée», 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 afficher votre vidage dans votre répertoire / home / your_user pour voir que vous obtenez toujours la même erreur. Cela a résolu mon problème.

Errno 32 est “pipe cassée”, donc toute erreur qui se produit avec la destination du tube (dans ce cas, gzip) provoquera une erreur 32. Si la structure du répertoire a changé et que votre ${BACKUP_DEST} ne fait plus référence à un répertoire existant qui se produirait.

Je déboguerais ceci en apportant quelque chose d’autre à votre commande gzip ou en créant une sauvegarde non compressée n’impliquant pas gzip.

Je voyais cette erreur, lors de la diffusion 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 packagée de la commande s3cmd ne supporte pas stdin (car elles ont la version 1.1.0).

J’utilisais mysqldump partir de l’interface de ligne de commande et essayais de diriger vers gzip et / ou un fichier et d’obtenir une erreur de “permission refusée”.

Même en tant que sudo , je recevais une erreur car, bien que j’utilisais mysqldump tant que sudo , le canal essayait toujours d’utiliser le compte d’utilisateur auquel j’étais connecté pour écrire la sortie. Dans ce cas, mon compte d’utilisateur shell ne disposait pas des permissions nécessaires pour écrire dans le répertoire cible.

Pour contourner ce problème, vous pouvez utiliser la commande tee en conjonction avec sudo :

 mysqldump --single-transaction --routines --events --sortingggers --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/... | sudo tee /var/backups/... est ce qui nous permet de diriger vers un répertoire accessible en écriture uniquement par root . Le > /dev/null supprime le tee du vidage de sa sortie directement à l’écran.

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