如何使用Go语言exec调用实现Golang数据库的备份与恢复操作？

本文共计1030个文字，预计阅读时间需要5分钟。

直接调用外部 dump 命令在开发或轻量场景下能快速定位问题，但易绕过 Go 的错误传播机制、权限控制和资源生命周期管理。一旦 dump 过程卡住、超时、输出乱码或被中断，cmd.Run() 可能挂起或静默失败，而您可能无法确切得知 exit code 或 stderr 内容。

• 必须显式设置 cmd.Stdout 和 cmd.Stderr，否则输出丢失，debug 时只能靠日志猜
• 不要用 cmd.Output() 拿大体积 dump 数据，容易 OOM；改用 io.Copy 流式写入文件
• 密码不能拼在命令行里（-psecret），会被 ps aux 看见；应通过配置文件（如 ~/.my.cnf）或环境变量传入
• PostgreSQL 的 pg_dump 默认不带 --no-owner，恢复时可能因用户不存在报错 ERROR: role "xxx" does not exist

MySQL 备份：用 mysqldump 生成 SQL 文件，关键在参数组合

纯 SQL 备份适合小到中型库（

• 必备参数：--single-transaction --routines --triggers --events --set-gtid-purged=OFF（避免 GTID 冲突）
• 排除干扰：--skip-comments --skip-opt 减少注释和冗余语句，降低解析失败风险
• 导出前先检查连接：mysql -h $host -u $user -e "SELECT 1"，别等 dump 到一半才报 Access denied
• 示例片段：

  cmd := exec.Command("mysqldump", "-h", host, "-u", user, "--single-transaction", "--routines", "--triggers", "--events", "--set-gtid-purged=OFF", dbname) cmd.Env = append(os.Environ(), "MYSQL_PWD="+password) // 避免明文密码

PostgreSQL 恢复：用 pg_restore 加 -c -C 清理再建库最稳

如果备份是 pg_dump -Fc（自定义格式），就不能用 psql 导入。直接 pg_restore 并指定目标库名，否则它会试图还原到 dump 里的原库名——而那个库很可能不存在。

• 恢复前确保目标库已存在：createdb -h $host -U $user targetdb，否则 pg_restore -d targetdb 会报 database "xxx" does not exist
• 加 -c（clean）+ -C（create）才能自动删旧库、重建库结构；不加就只往现有库里塞数据，容易主键冲突
• 权限问题常见于 pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of database xxx —— 此时需用 superuser 执行，或提前 ALTER DATABASE xxx OWNER TO $user
• 不要忽略 --if-exists：它能让 -c 更安全，避免 “drop db not exists” 报错中断流程

超时与信号处理：不设 cmd.WaitDelay 就等于没做容错

dump 一个 10GB 的库可能耗时数分钟，Go 默认不会等那么久。更麻烦的是，如果用户 Ctrl+C，子进程还在后台跑，变成僵尸进程。

立即学习“go语言免费学习笔记（深入）”；

• 必须用 context.WithTimeout 包裹 cmd.Start() + cmd.Wait()，否则 Run() 会无限阻塞
• 恢复阶段更要设超时：比如 pg_restore 在网络抖动时可能卡在 COPY 阶段，不超时就永远 hang 住
• 用 os.Interrupt 捕获 Ctrl+C，并主动调用 cmd.Process.Kill()，否则子进程残留
• 注意：cmd.Wait() 返回的 error 不一定是业务错误——要检查 err != nil 后再用 cmd.ProcessState.ExitCode() 判断是否真失败

备份脚本真正难的不是调通命令，是搞清每条参数在什么条件下生效、什么错误会被吞掉、以及恢复时哪些权限和上下文必须提前准备好。漏掉任意一个，都会让“一键恢复”变成手动翻日志修半天。