命名管道（fifo）无法实现mysql异地流式备份的可靠落地，因其仅为本地ipc机制，不支持网络传输、断点续传、错误重试或加密，且不具备校验、压缩与进度反馈能力。
命名管道（FIFO）不能用于MySQL异地流式备份的可靠落地——它本质是本地进程间通信机制，不自带网络传输、断点续传、错误重试或加密能力。强行用 mysqldump | ssh ... mysql 这类管道链路，等于把网络稳定性、SSH会话寿命、远端磁盘空间、权限、字符编码全部耦合进单次执行中，一环崩即全废。
为什么 FIFO + mysqldump 无法真正“异地落盘”
命名管道（mkfifo 创建的文件）只存在于本地文件系统，它不跨主机、不持久化、不缓冲。所谓“流式传输”，实际仍是靠 ssh 或 nc 等工具做网络搬运，FIFO 只是中间一个无意义的本地占位符。
- 你无法在远程机器上直接
mysql ，因为 FIFO 没有被创建在那台机器上 - 若用
mysqldump | ssh target "cat > /backup/xxx.sql"，本质是 shell 重定向，不是 FIFO；一旦 SSH 断开，mysqldump收到 SIGPIPE，立即终止，且无任何恢复线索 - FIFO 不提供校验、压缩、进度反馈；出错时连哪一行中断都不可知
真正能落地异地的流式方案：rsync --partial + 压缩中转
要实现“边 dump 边传、断点续传、最终落盘”，必须放弃纯管道思维，改用支持增量同步的传输工具，并让 dump 输出可寻址、可校验。
- 本地生成带时间戳的压缩流：
mysqldump --single-transaction --databases app_db | gzip > /backup/app_db_$(date +%Y%m%d_%H%M%S).sql.gz - 用
rsync --partial --progress -e "ssh -o ConnectTimeout=10" /backup/app_db_*.sql.gz user@remote:/backup/上传 ——--partial允许传到一半断掉后下次继续 - 远端无需运行
mysql导入，先确保文件完整：gunzip -t /backup/app_db_*.sql.gz，再决定是否导入 - 若需自动导入，应在远端脚本里加判断：
if [ $? -eq 0 ]; then zcat /backup/app_db_*.sql.gz | mysql app_db; fi
比 FIFO 更稳的替代：mysqldump 流式 + socat 加密中继
如果你坚持“不落地中间文件”，可用 socat 替代裸 SSH，它支持超时重连、SSL 封装、流控，比 FIFO 更接近“可靠流”语义：
- 本地启动监听：
mysqldump --single-transaction app_db | gzip | socat - SSL:remote.example.com:4433,cert=client.pem,cafile=ca.pem - 远端用 socat 接收并解压落盘：
socat SSL-LISTEN:4433,cert=server.pem,cafile=ca.pem,reuseaddr,fork SYSTEM:"gunzip > /backup/app_db_$(date +\%Y\%m\%d_\%H\%M\%S).sql" - 注意：
socat不自带校验，仍需额外跑sha256sum或用--checksum参数（v1.8+）
真正难的不是“怎么传”，而是“传完怎么确认它没坏、没截断、没乱码”。FIFO 给不了这个确认能力，所有绕过本地落盘的流式路径，都必须在接收端补上完整性校验和原子性落盘逻辑——否则所谓“异地落盘”，只是把风险从网络层转移到了数据一致性层。
