mysqldump:编写了errno 32

我在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} 

现在我正在转移到另一个托pipe。 我试图使用相同的脚本(当然,我用新的凭据更改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 

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

所以errno 32是“破管”。 您将mysqldump输出管道输送到gzip ,所以这意味着gzip在mysqldump结束之前终止。 例如可能是因为你的磁盘已满,或者gzip超过了你主机的最大CPU时间/使用率。

确保文件夹/ home / backup / db /(你用来存储备份)具有写访问权限(快速检查:尝试在该文件夹上使用chmod -R 777并运行脚本以确保)。

由于一些错别字,我也遇到了同样的问题。

1.)我错误地键入了db用户的名字。 当他真的是“db_user1”时,我有“db_user_1”。

2.)管道后,我忘了> gzip > myfile.tar.gz

但我建议你升级到MySQL 5.6+,所以你可以停止暴露其他用户的数据库密码。

看看这个答案在stackoverflow。

面临同样的问题。 我不知道为什么,但是,如果你添加公用事业PV的结论,所有的作品。 也许这取决于你的shell bash / sh。

 sudo apt-get install pv 

PipeViewer它是一个非常有用的实用工具,例如,它允许您可视化写入磁盘的过程。

脚本例如

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

它的这个老话题,但即时通讯面临的问题,并发现:

我的文件名:db_26 / 03.tar.gz它引发了上面的错误; 但是当我使:db.tar.gz没有错误。

所以你应该检查你的文件名

我很惊讶,我不能做我的数据库的转储,我前一天能够做到这一点。 现在,我得到这个错误。

正如nos所说的,错误信息意味着Broken pipe,这意味着输出不能写入磁盘。 在我的情况下, 我的SSH用户没有权限写入我在mysqldump指令中定位的文件夹中。

您可以在/ home / your_user目录中输出您的转储,看看它是否仍然有相同的错误。 这样做解决了我的问题。

Errno 32是“破损的管道”,因此任何与管道目标(在本例中为gzip)发生的错误都将导致errno 32.如果目录结构已更改,并且${BACKUP_DEST}不再指向存在此问题的目录会发生。

我会调试这个通过管道别的东西到你的gzip命令或创建一个不涉及gzip的未压缩的备份。

检查文件夹是否存在于你的位置/ home / backup / db /

如果不是,则创建每个子文件夹。

命令:mkdir / home / backup / db /

然后再次运行你的命令。

我看到这个错误,当管道mysqldump输出到s3cmd。 这是由于使用s3cmd的错误版本造成的。 在Ubuntu Trusty和Debian上Wheezy s3cmd命令的打包版本不支持stdin(因为它们的版本是1.1.0)。

我从CLI使用mysqldump并试图管道到gzip和/或文件,并获得“权限被拒绝”的错误。

即使sudo ,我得到一个错误,因为虽然我是sudo运行mysqldump ,但管道仍然尝试使用我登录到shell的用户帐户来写输出。 在这种情况下,我的shell用户帐户没有写入目标目录的权限。

为了解决这个问题,你可以使用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 

| sudo tee /var/backups/... | sudo tee /var/backups/...是什么让我们管道到一个只能由root目录写的root> /dev/null禁止tee将其输出直接转储到屏幕上。