errno 32 是操作系统级写入失败信号，根本原因是输出流中断，常见于磁盘满、gzip崩溃、ssh断开、timeout终止或selinux/容器权限限制，而非mysql服务端报错；密码和gtid警告不引发该错误。
管道破裂（Broken pipe）在 mysqldump 日志中不是 MySQL 服务端主动报的错，而是操作系统层面的写入失败信号——说明 mysqldump 进程还在往 stdout 写数据，但接收端（比如 gzip、ssh、重定向文件）已经提前关闭或不可用了。
为什么 mysqldump 会触发 errno 32？
根本原因是输出流中断，常见于以下场景：
-
mysqldump正在吐出大量 SQL，但目标磁盘已满（df -h看不到 /tmp 或备份路径剩余空间不足） - 用管道压缩时，
gzip进程崩溃或被 kill，导致管道另一端消失 - 远程备份用
ssh执行mysqldump | gzip，但 ssh 连接超时断开 - 脚本里用了
timeout限制命令执行时间，而 dump 没完成就被强制终止 - SELinux 或容器挂载限制了写权限，
touch测试能写，但大文件写入被拦截
密码警告和 GTID 警告会引发 Broken pipe 吗？
不会。这两类警告（Warning: Using a password on the command line interface can be insecure 和 Warning: A partial dump from a server that has GTIDs...）只是 stderr 输出，不影响 stdout 写入流程。但它们常和 Broken pipe 同时出现，容易误判因果关系。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
真正要盯的是：mysqldump: Got errno 32 on write 这一行——它明确指向写操作失败，和警告无关。
- 密码明文问题应改用
~/.my.cnf或--defaults-extra-file - GTID 警告可加
--set-gtid-purged=OFF消除，但不解决 errno 32
如何验证和修复 Broken pipe？
别急着改 MySQL 配置，先确认是管道哪一端掉链子：
- 去掉所有管道和压缩，直接
mysqldump -u user -p db_name > test.sql，看是否成功 - 如果成功，再逐步加回
| gzip、| ssh等环节，定位故障点 - 检查
ulimit -f（文件大小限制）和ulimit -p（pipe size），尤其在容器或受限 shell 中 - 用
strace -e trace=write,close,pipe mysqldump ... 2>&1 | head -20观察 write 系统调用何时失败
最常被忽略的一点：Broken pipe 是结果，不是原因。它只告诉你“下游没了”，但下游为什么没了——得从磁盘、权限、进程生命周期、网络稳定性这四个维度挨个排除，而不是盯着 mysqldump 参数调来调去。
