MySQL mysqldump：写入时出现 errno 32
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/22288271/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
mysqldump: Got errno 32 on write
提问by MultiformeIngegno
I used this script for years on my VPS. And it's still working.
我在我的 VPS 上使用这个脚本多年。它仍在工作。
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}
Now I'm moving to another hosting. I 'm trying to use the same script (of course I changed ROOT_PASSWORD with the new credentials) but I don't know why I get this:
现在我要搬到另一个主机。我正在尝试使用相同的脚本（当然，我使用新凭据更改了 ROOT_PASSWORD），但我不知道为什么会得到这个：
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
回答by nos
20:47:59 0 ~] $ perror 32
OS error code 32: Broken pipe
So errno 32 is "broken pipe". You're piping the mysqldump output to gzip, so this means gzip terminated prior to mysqldump finished. Could e.g. be because your disk is full, or gzip surpassed any max CPU time/usage your host has in place.
所以 errno 32 是“破管”。您将 mysqldump 输出通过管道传输到gzip，因此这意味着 gzip 在 mysqldump 完成之前终止。例如，可能是因为您的磁盘已满，或者 gzip 超过了您的主机的任何最大 CPU 时间/使用率。
回答by Buttle Butkus
I had the same problem due to a couple of typos.
由于几个错别字，我遇到了同样的问题。
I typed the name of the db user incorrectly. I had
"db_user_1"when he was really"db_user1".After the pipe I forgot the
>ingzip > myfile.tar.gz.
我错误地输入了 db 用户的名称。我有
"db_user_1"当他真的"db_user1"。在管道之后我忘记了
>ingzip > myfile.tar.gz。
But I recommend you upgrade to MySQL 5.6+ asap, so you can stop exposing database passwords other users.
但我建议你尽快升级到 MySQL 5.6+，这样你就可以停止将数据库密码暴露给其他用户。
Check out this answeron StackOverflow.
在 StackOverflow 上查看这个答案。
回答by Francisco De La Fuente
Make sure the folder /home/backup/db/ (which your are using to store the backup) has write access permission (to quick check: try using chmod -R 777 on that folder and run the script to make sure).
确保文件夹 /home/backup/db/ （您用来存储备份的）具有写访问权限（快速检查：尝试在该文件夹上使用 chmod -R 777 并运行脚本以确保）。
回答by PRIHLOP
Faced with the same problem. I do not know why exactly, but if you add the utility PV concluded that all works. Maybe it depends on your shell bash/sh.
面临同样的问题。我不知道究竟是为什么，但是如果添加实用程序 PV 得出的结论是，一切正常。也许这取决于您的 shell bash/sh。
sudo apt-get install pv
PipeViewer it a very usefull utility, it allows you to visualize processes of writing to disk, for example.
PipeViewer 它是一个非常有用的实用程序，例如，它允许您可视化写入磁盘的过程。
Script for example
例如脚本
mysqldump ${MYSQLDUMP_OPTIONS} ${DB} | gzip | pv > ${BACKUP_DEST}/${DB}.sql.gz
回答by Brac
I was surprised I couldn't do a dump of my DB, I was able to do it the day before. Now, I was getting this error.
我很惊讶我不能转储我的数据库，我能够在前一天完成。现在，我收到了这个错误。
As nossaid, the error message means Broken pipe, which means the output cannot be written to disk. In my case, my SSH user had no permission to write in the folder I was targetingin my mysqldump instruction.
正如nos所说，错误消息意味着管道损坏，这意味着输出无法写入磁盘。就我而言，我的 SSH 用户无权写入我在 mysqldump 指令中定位的文件夹。
You can output your dump in your /home/your_user directory to see it you still get the same error. Doing so solved my problem.
您可以在 /home/your_user 目录中输出转储以查看它，但您仍然会遇到相同的错误。这样做解决了我的问题。
回答by alexw
I was using mysqldumpfrom the CLI and trying to pipe to gzip and/or a file and getting a "permission denied" error.
我正在mysqldump从 CLI使用并尝试通过管道传输到 gzip 和/或文件并收到“权限被拒绝”错误。
Even as sudo, I was getting an error because although I was running mysqldumpas sudo, the pipe was still trying to use the user account I was logged in to the shell asto write the output. In this case, my shell user account did not have permissions to write to the target directory.
即使作为sudo，我也遇到了错误，因为尽管我以mysqldump身份运行sudo，但管道仍在尝试使用我登录到 shell 的用户帐户来写入输出。在这种情况下，我的 shell 用户帐户没有写入目标目录的权限。
To get around this, you can use the teecommand in conjunction with sudo:
要解决此问题，您可以将该tee命令与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
The | sudo tee /var/backups/...is what lets us pipe to a directory that is only writable by root. The > /dev/nullsuppresses teefrom dumping its output directly to the screen.
这| sudo tee /var/backups/...就是让我们通过管道传输到只能由root. 该> /dev/null禁止显示tee直接倾倒其输出到屏幕上。
回答by reor
Errno 32 is "broken pipe" so any error that is happening with the pipe destination (in this case gzip) will cause errno 32. If the directory structure has changed and your ${BACKUP_DEST}no longer refers to a directory that exists this problem would occur.
Errno 32 是“管道损坏”，因此管道目标（在本例中为 gzip）发生的任何错误都将导致 errno 32。如果目录结构已更改并且您${BACKUP_DEST}不再引用存在的目录，则会发生此问题。
I would debug this by piping something else to your gzip command or creating an uncompressed backup not involving gzip.
我会通过将其他内容传递给您的 gzip 命令或创建一个不涉及 gzip 的未压缩备份来调试它。
回答by Santiago Medina Chaverra
Check if the folder exist in your location, /home/backup/db/
检查文件夹是否存在于您的位置，/home/backup/db/
if no, create every subfolder.
如果没有，请创建每个子文件夹。
Command: mkdir /home/backup/db/
命令：mkdir /home/backup/db/
then run your command again.
然后再次运行您的命令。
回答by Muhammet Arslan
Its so old topic, but I'm facing that problem and find that:
它是如此古老的话题，但我正面临这个问题并发现：
My file name: db_26/03.tar.gzits raising an error like above; but when I use: db.tar.gzthere is no error.
我的文件名：db_26/03.tar.gz它引发了上述错误；但是当我使用时：db.tar.gz没有错误。
So you should check your file name
所以你应该检查你的文件名
回答by Ryan
I was seeing this error, when piping mysqldump output to s3cmd. It was caused by using the wrong version of s3cmd. On Ubuntu Trusty and Debian Wheezy the packaged version of s3cmd command doesn't support stdin (because they have version 1.1.0).
在将 mysqldump 输出通过管道传输到 s3cmd 时，我看到了这个错误。这是由于使用了错误版本的 s3cmd 引起的。在 Ubuntu Trusty 和 Debian Wheezy 上，s3cmd 命令的打包版本不支持 stdin（因为它们的版本是 1.1.0）。
