goagent3.0.2上传时出现errno11004，求指教

Posted 2023-03-22

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了goagent3.0.2上传时出现errno11004，求指教相关的知识，希望对你有一定的参考价值。

电脑是win7系统，网络现在是校园网，应该是ipv6吧。
现在想更新3.0.2版，但是update时输入用户名就提示 errno11004 getaddrinfo failed。试过网上说的关闭防火墙，先改proxy.ini的用户名，然后开着goagent同时上传的方法。没有用。
本人电脑水平有限，哪位大神指导的时候请一定按每一步应该做什么这样教给我。谢谢！
最近有急事需要用脸书，请一定帮帮我！万分谢谢！！

很简单啊,我有很多账号,直接给你个程序包,你打开就可以直接使用了!
请私信联系我! 参考技术A 话说3.0.2不必更新服务端，手痒乎？

这个问题官网FAQ第35条有解答，但这里不让贴链接，你自己去看吧。追问

不用更新，是针对3.0.1的用户的，我之前的版本比较老，是需要上传的

追答

私信给你链接了

mysqldump：写入时出现 errno 32

【中文标题】mysqldump：写入时出现 errno 32【英文标题】：mysqldump: Got errno 32 on write 【发布时间】：2014-04-12 20:29:50 【问题描述】：

我多年来一直在我的 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

现在我要转移到另一个主机。我正在尝试使用相同的脚本（当然我用新凭据更改了 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

【问题讨论】：

【参考方案1】：

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

所以 errno 32 是“断管”。您将 mysqldump 输出传送到 gzip ，因此这意味着 gzip 在 mysqldump 完成之前终止。可以例如是因为您的磁盘已满，或者 gzip 超过了您的主机设置的任何最大 CPU 时间/使用率。

【讨论】：

嗯.. 磁盘未满，CPU 空闲。 :( @MultiformeIngegno 您告诉我们您使用 VPS，您是否确认他们没有限制？ VPS 限制 CPU 使用率并杀死使用过多 CPU 的进程是很常见的。无论如何，你现在有一个迹象表明 gzip 被杀死了，所以你可以玩弄它，例如不将输出通过管道传输到 gzip，而是直接传输到文件中，看看结果如何。 @nos 重新注意到 CPU 限制确实是我在 AWS 上的问题。我通过niceing 转储解决了它。如果磁盘未满且 CPU 空闲，试试这个：创建一个基本的文本文件，然后在上面运行 gzip 命令，你很快就会意识到问题所在（我想它的方式相同的错误信息）【参考方案2】：

由于几个拼写错误，我遇到了同样的问题。

我输入了错误的 db 用户名。我有"db_user_1"，而他真的是"db_user1"。

在管道之后，我忘记了gzip > myfile.tar.gz 中的>。

但我建议您尽快升级到 MySQL 5.6+，这样您就可以停止将数据库密码暴露给其他用户。

在 *** 上查看 this answer。

【讨论】：

【参考方案3】：

确保文件夹 /home/backup/db/（您用于存储备份）具有写访问权限（快速检查：尝试在该文件夹上使用 chmod -R 777 并运行脚本以确保） .

【讨论】：

+1 这是我的问题，文件夹必须有 0777 CHMOD，在我的情况下它有 0755，所以这取决于 mysql 用户的权利【参考方案4】：

我很惊讶我无法转储我的数据库，但我在前一天就可以做到。现在，我收到了这个错误。

正如nos所说，错误信息意味着Broken pipe，这意味着输出无法写入磁盘。在我的例子中，我的 SSH 用户没有权限在我的 mysqldump 指令中写入目标文件夹。

您可以在 /home/your_user 目录中输出您的转储以查看它，您仍然会遇到相同的错误。这样做解决了我的问题。

【讨论】：

【参考方案5】：

面临同样的问题。我不知道究竟是为什么，但如果你添加实用程序 PV 得出的结论是一切正常。也许这取决于你的 shell bash/sh。

sudo apt-get install pv

PipeViewer 它是一个非常有用的实用程序，它可以让您可视化写入磁盘的过程，例如。

例如脚本

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

【讨论】：

【参考方案6】：

我在 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/... 让我们可以通过管道连接到只能由root 写入的目录。 > /dev/null 禁止 tee 将其输出直接转储到屏幕上。

【讨论】：

【参考方案7】：

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

如果没有，则创建每个子文件夹。

命令： mkdir /home/backup/db/

然后再次运行您的命令。

【讨论】：

这也是我们的问题。我在新环境中运行 Deployer，并且不允许创建文件夹。当我手动创建文件夹时，它在后续运行中运行良好。【参考方案8】：

Errno 32 是“损坏的管道”，因此管道目标（在本例中为 gzip）发生的任何错误都将导致 errno 32。如果目录结构已更改并且您的 $BACKUP_DEST 不再引用存在的目录会出现这个问题。

我会通过向您的 gzip 命令传递其他内容或创建不涉及 gzip 的未压缩备份来调试此问题。

【讨论】：