<p>aws s3 cp - 支持从 stdin 读取，是流式上传的前提；而 s3cmd put - 不支持，会报“Invalid source: '-'”错误。</p>
aws s3 cp - 是否支持从 stdin 读取？
支持。这是流式上传的前提，aws s3 cp - 明确接受标准输入，而 s3cmd put - 不支持——这是最常混淆的点。如果你看到 Invalid source: '-' 错误，基本可以断定你误用了 s3cmd。
mysqldump 管道直传 S3 的最小可行命令长什么样？
必须满足三个条件：一致性导出、压缩输出、目标 CLI 支持 stdin。缺一不可：
-
--single-transaction：对 InnoDB 表保证快照一致性；不用--skip-lock-tables，它不防并发写入 -
gzip -c：-c才把压缩结果输出到 stdout；漏掉会静默写入本地文件或报错 -
aws s3 cp - s3://bucket/path.sql.gz：末尾的-是关键，表示从管道读
示例命令：
mysqldump -u root -p'pass' --single-transaction --routines --triggers mydb | gzip -c | aws s3 cp - s3://my-backup-bucket/mysql/mydb-$(date +%F_%H%M%S).sql.gz
为什么 mysqldump 流式上传中途经常报 ERROR 2013？
这不是网络问题，而是 MySQL 主动断开连接。根本原因有两个：
-
net_read_timeout默认仅 30 秒：mysqldump 在 dump 大表时，若单次读取间隔超时，连接就被 kill -
wait_timeout虽然默认 8 小时，但实际受net_read_timeout制约更紧
解决办法不是调大超时，而是优化导出本身：
- 加
--single-transaction减少锁等待 - 避免导出
information_schema或系统库（它们可能触发慢查询） - 如仍失败，可分库导出，或改用
mysqlpump（MySQL 8.0+），它对大表分片更友好
恢复时能不能直接 aws s3 cp s3://xxx.sql.gz - | gunzip | mysql -u...？
不能。这种“对称管道”看似简洁，实则高危：
- 网络中断导致部分 SQL 执行后中断，MySQL 不会自动回滚已执行语句
- gzip 流损坏时，
gunzip可能静默输出乱码，mysql会继续执行直到报错（比如ERROR 1064） - pipe buffer 溢出或 Ctrl+C 中断，可能残留未关闭的连接，影响后续操作
正确做法永远是两步：先下载，再解压导入。
真正容易被忽略的是：流式上传看似省磁盘，但一旦中间任一环节（如网络抖动、S3 权限变更、gzip 缓冲区满）出错，整个备份就无声失败——它不像落地文件那样有明确的状态可检查。
