MySQL如何使用SSL传输备份数据_mysqldump结合SSH加密隧道传输-mysql教程-PHP中文网

正确做法是用管道将 mysqldump 输出直连 ssh 隧道加密传输，避免本地落盘；需加 --single-transaction、-c、stricthostkeychecking=no，并通过 ~/.my.cnf 管理密码；ssh 隧道比 mysql ssl 更简单可靠，且全程加密 tcp 流。

mysql如何使用ssl传输备份数据_mysqldump结合ssh加密隧道传输

mysqldump 输出直接走 SSH 隧道，不落地明文

本地 mysqldump 产生的 SQL 流，不该先写到磁盘再 scp，那样既多一步 I/O，又暴露敏感数据。正确做法是用管道直连远程 SSH，让加密发生在传输层。

常见错误是把 mysqldump 和 ssh 当成两个独立命令拼凑，漏掉 -C（压缩）和 -o StrictHostKeyChecking=no（自动化场景下避免交互阻塞），或者忘了加 --single-transaction 导致备份不一致。

实操建议：

用 mysqldump --single-transaction -h localhost -u user -p'pass' db_name | ssh -C -o StrictHostKeyChecking=no user@host "cat > /backup/db_$(date +%Y%m%d).sql"
如果远程磁盘空间紧张，可加 gzip：末尾改成 ssh ... "gzip > /backup/db_$(date +%Y%m%d).sql.gz"
别在命令行里写明文密码；改用 ~/.my.cnf 配置文件，并设权限 chmod 600 ~/.my.cnf

MySQL 服务端没开 SSL？那 mysqldump 自己加不了 TLS

mysqldump 的 --ssl-mode=REQUIRED 只能加密「它连 MySQL 的那条连接」，对后续的 SSH 管道完全没影响。很多人以为加了这个参数就全程加密了，其实只是客户端到数据库这一跳加密，后面走 SSH 还是靠 SSH 自己的密钥协商。

所以：如果 MySQL 本身监听在内网且不暴露公网，--ssl-mode 不是必须的；但若 dump 命令要从不可信网络发起（比如跨云 VPC），那就得配好 MySQL 的 SSL 证书，并确认 require_secure_transport=ON 已生效。

注意点：

mysqldump --ssl-mode=REQUIRED --ssl-ca=/path/to/ca.pem --ssl-cert=/path/to/client-cert.pem --ssl-key=/path/to/client-key.pem
检查 MySQL 服务端是否真启用了 SSL：SHOW VARIABLES LIKE 'have_ssl'; 和 SHOW STATUS LIKE 'Ssl_cipher';
证书路径必须是 mysqldump 所在机器上的路径，不是 MySQL 服务器上的

SSH 隧道比 mysqldump 内建 SSL 更可靠也更简单

当目标只是“不让备份数据裸奔在线路上”，SSH 隧道比折腾 MySQL SSL 更省事：它不依赖 MySQL 版本、不用管证书过期、也不用配置 ssl_ca 等一堆变量。只要 SSH 能通，加密就成立。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

性能上，SSH 的 AES-GCM 或 ChaCha20 加解密开销极小，现代 CPU 几乎无感；而 MySQL SSL 在高并发 dump 场景下可能因握手或证书验证拖慢速度。

关键差异：

SSH 加密的是整个 TCP 流（含 shell 命令、文件名、SQL 内容），MySQL SSL 只加密协议包载荷
SSH 支持密钥登录 + agent forwarding，适合脚本调度；MySQL SSL 依赖文件权限和路径硬编码
遇到 Write failed: Broken pipe 或 Connection reset by peer，优先查 SSH 连接稳定性，而不是怀疑 mysqldump 参数