怎么通过SSH隧道使用mysqldump远程备份MySQL数据库？

在生产环境中，出于安全规范，数据库服务器通常只监听本地回环地址（127.0.0.1）或置于无公网 IP 的私有子网内，禁止向公网开放 3306 端口。通过 SSH 隧道使用 mysqldump，可以在不破坏现有网络隔离策略的前提下，利用经过加密的 SSH 连接作为安全管道，直接将远程 MySQL 实例中的数据逻辑导出并妥善保存到本地工作站或备份服务器上。

1. 核心架构与数据流向

理解 SSH 隧道备份的关键在于认清“流量由谁发起”以及“凭证由谁校验”。在传统的远程连接中，客户端直接向服务器的 3306 端口发起 TCP 握手，所有数据库账号认证与数据包传输均直接暴露在公网网络链路上。

而采用 SSH 隧道时，本地客户端先与目标主机（或跳板机）的 22 端口建立加密连接。无论采用单行远程调用还是本地端口转发，MySQL 协议数据均被封装在 SSH 报文内传输。在服务器端视角看来，请求由本地进程（或 SSH 守护进程）发起，完全符合 bind-address = 127.0.0.1 的安全限制。

图 1：公网直连与 SSH 加密隧道方案的安全隔离与流量流向对比

2. 实施前的必要准备与权限确认

在开始备份之前，需要在本地和远端分别验证权限与环境，避免因基础网络阻断或权限缺失导致备份中断：

• 本地环境： 拥有 ssh 客户端工具。若采用本地端口转发方式，本地需安装匹配版本的 mysqldump；若采用远程执行管道，本地仅需安装 gzip 等通用压缩工具。
• SSH 鉴权凭证： 推荐使用 SSH 免密密钥对登录，避免执行定时备份或自动化脚本时由于密码交互提示导致管道挂起。
• MySQL 账号权限： 用于备份的 MySQL 账号需要具备目标库的只读及导出权限。最小权限组合通常包含：SELECT、LOCK TABLES、SHOW VIEW、RELOAD（如果需要刷新日志）以及 TRIGGER。

3. 方案一：通过 SSH 远程执行并管道回传（推荐）

这是最推荐、最纯粹的实践方式。它的执行机制是在本地运行 SSH 命令登录到远程服务器，直接在远程服务器上调度远程的 mysqldump 工具生成 SQL 文本流，并通过 SSH 会话的“标准输出”（stdout）流式推送到本地，最后在本地落盘为文件。

图 2：单行命令通过标准输出流将数据经由 SSH 管道回传到本地

完整执行命令

# 语法结构：ssh [连接选项] [用户@远程主机] "[远程mysqldump命令]" | [本地处理或重定向]
ssh -C -p 22 deployer@198.51.100.25 \
  "mysqldump -u db_backup_user -p'SecureP@ssw0rd' \
   --single-transaction --quick --routines --triggers app_production" \
   | gzip -c > /data/backups/app_production_$(date +%Y%m%d_%H%M%S).sql.gz

该命令拆解如下：

• ssh -C -p 22：-C 开启 SSH 传输层压缩，能大幅降低带宽消耗，加速网络回传；-p 指定 SSH 端口。
• "mysqldump ..."：双引号包裹的是在远程机器内部执行的完整命令。因此，该数据库访问实际是在远程本地执行（走远程机器的 localhost）。
• --single-transaction：对 InnoDB 表至关重要。它开启快照读（Snapshot Read），在不锁死线上写操作的情况下获得一致性备份。
• --quick：强制 mysqldump 逐行检索表数据，而不是在导出前将整张表缓存到内存中，防止导出百万级大表时引发 OOM 崩溃。
• | gzip -c > ...：注意竖线右侧是在本地主机执行的操作。SSH 接收远程返回的 SQL 纯文本数据流，在本地通过 gzip 实时压缩并重定向写入本地磁盘。

4. 方案二：建立独立本地端口转发（Port Forwarding）

如果你需要在本地使用图形化工具（如 DBeaver、Navicat），或者希望严格使用本地主机上的 mysqldump 二进制程序执行备份，可以采用 SSH 本地端口转发（Local Port Forwarding）。

图 3：本地端口转发（-L）的标准作业步骤

步骤 1：在本地建立 SSH 转发隧道

# 将本地 3307 端口通过远端 SSH 映射到远端的 127.0.0.1:3306
ssh -N -f -L 3307:127.0.0.1:3306 -p 22 deployer@198.51.100.25

参数解释：

• -N：告诉 SSH 客户端不执行任何远程命令，仅用于端口转发。
• -f：让 SSH 命令在完成认证后立即转入系统后台运行。
• -L 3307:127.0.0.1:3306：转发映射定义。格式为 [本地监听端口]:[目标访问地址]:[目标端口]。建议将本地端口设为 3307 等非默认端口，避免与本地正在运行的 MySQL 实例冲突。

步骤 2：在本地运行 mysqldump 抓取数据

隧道建立成功后，本地的 3307 端口就相当于远端数据库的入口：

mysqldump -h 127.0.0.1 -P 3307 -u db_backup_user -p \
  --single-transaction --quick app_production > /data/backups/local_dump.sql

关键细节： 连接主机必须显式指定为 -h 127.0.0.1，绝不能写成 -h localhost。在 MySQL 官方客户端中，若主机名为 localhost，客户端会强制尝试使用本地 Unix Socket 文件通信（例如 /tmp/mysql.sock），从而忽略 -P 3307 端口参数并报错退出。

步骤 3：关闭隧道

导出任务结束后，关闭占用该端口的后台 SSH 进程：

# 查找并终止监听 3307 端口的 SSH 进程
kill $(lsof -t -i:3307)

5. 两种方案深度对比与选型考量

面对具体业务场景时，可以根据两端的工具链分布与网络带宽情况选择最适合的路径：

6. 常见故障与关键排查方法

在实际操作过程中，最容易在以下三个环节出现故障，请依据具体现象依次定位：

故障 1：提示“Host 'xxx' is not allowed to connect to this MySQL server”

原因： MySQL 用户的授权 host 限制与实际接入途径不匹配。若使用方案一，MySQL 校验的是 'db_backup_user'@'localhost'（或 127.0.0.1）；若远端是通过多层跳板机访问内网独立数据库节点，则需确认跳板机 IP 是否在 MySQL 的白名单内。

排查确认： 在目标数据库中执行 SELECT user, host FROM mysql.user;，确保你的备份账户具有从连接来源访问的授权。

故障 2：执行时报“mysqldump: Got errno 32 on write”或管道提前终止

原因： 常见于备份几十 GB 以上的大型数据库时。SSH 会话因长时间无数据来回流动被中间路由器断开，或者本地磁盘已满导致管道写入失败。

解决办法： 在 SSH 连接时加入心跳参数保持通道活性，同时检查磁盘空间：

ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5 -C deployer@198.51.100.25 "mysqldump ..."

故障 3：通过本地端口转发报“ERROR 2002 (HY000): Can't connect to local MySQL server through socket”

原因： 如前文所述，在 mysqldump 中错误地使用了 -h localhost，触发了本地 socket 查找机制，而非通过 TCP 端口走 3307 转发。

解决办法： 严格使用 -h 127.0.0.1 -P 3307 --protocol=TCP 明确强制走网络套接字。

7. 操作全景与生产实践总结

为了保障备份结果万无一失，务必将“备份完成”与“备份有效”区分开来。导出的 SQL 文件大小大于 0 并不代表没有语法错误或中间崩溃。每次备份任务结束之后，应加入文件校验逻辑。

图 4：覆盖准备、执行、校验、归档的标准化生产作业全流程

验证备份完整性的两个简单技巧：

1. 对于未压缩的 .sql 文件，使用 tail -n 20 dump.sql 查看文件底部，确认存在类似 -- Dump completed on 2026-09-18 12:00:00 的注释标记。若不存在该行，说明 dump 进程中途意外退出。
2. 对于压缩的 .sql.gz 文件，可以通过 gzip -t filename.sql.gz 进行解压校验，若退出状态码为 0，则表明数据压缩块完整无损。

将上述经过验证的命令写入本地的 Shell 脚本并加入定时调度任务（crontab），即可在完全不改变生产环境网络安全隔离的前提下，建立起自动化、可复查的远程备份闭环。