将PostgreSQL导入RDS遇错误：earth类型不存在及pg_restore失败求助

针对你遇到的「earth类型不存在」和pg_restore恢复失败的问题，我给你梳理具体的解决步骤：

一、解决「ERROR: type "earth" does not exist」错误 #

这个错误的核心原因是：你的源PG9.4数据库中安装了earthdistance扩展（该扩展包含earth类型），但目标RDS PG9.6实例中还未创建这个扩展，导致恢复时依赖的类型找不到。

解决步骤：

1. 确认源数据库的扩展情况（可选，但能验证问题）：
   登录到Docker部署的PG9.4实例，执行以下查询：

   SELECT * FROM pg_extension WHERE extname = 'earthdistance';
   

   如果返回结果，说明确实安装了该扩展。

2. 在RDS目标库中创建扩展：
   使用你拥有的RDS超级用户账号（比如你提到的rdspostgresmaster），连接到目标数据库执行创建命令：

   export PGPASSWORD='你的rdspostgresmaster密码'
   psql -h $pgHost -U rdspostgresmaster dbname -c 'CREATE EXTENSION IF NOT EXISTS earthdistance CASCADE;'
   

   加上CASCADE是因为earthdistance依赖cube扩展，这个参数会自动安装所需的依赖扩展。

二、解决pg_restore恢复失败问题 #

你使用了并行目录格式（-Fd + --jobs 2）导出备份，恢复时需要匹配对应的并行模式，同时还要注意权限和版本兼容性问题：

1. 正确的并行恢复命令 #

使用RDS超级用户执行恢复，确保命令参数匹配导出时的设置：

# 设置密码环境变量
export PGPASSWORD='你的rdspostgresmaster密码'
# 执行并行恢复，--jobs参数和导出时保持一致
pg_restore -h $pgHost -U rdspostgresmaster -d dbname --jobs 2 "/pgdump/dbname_fd"

• 如果备份文件不在本地，需要先将/pgdump/dbname_fd目录传输到能访问RDS的服务器（比如EC2）上。

2. 处理所有权问题 #

你重建数据库时，默认所有者是rdspostgresmaster，而源数据库的对象所有者是user，恢复时可能会出现权限冲突。可以添加--no-owner参数跳过所有者设置：

pg_restore -h $pgHost -U rdspostgresmaster -d dbname --jobs 2 --no-owner "/pgdump/dbname_fd"

恢复完成后，你可以手动调整对象的所有者为目标库的业务用户。

3. 排查具体错误 #

如果恢复仍然失败，添加-v（verbose）参数查看详细日志，定位具体出错环节：

pg_restore -v -h $pgHost -U rdspostgresmaster -d dbname --jobs 2 --no-owner "/pgdump/dbname_fd"

常见的失败原因可能是：还有其他未安装的扩展、网络连接中断、RDS实例资源不足（比如CPU/内存不够导致并行恢复超时）。

4. 版本兼容性优化（可选） #

源是PG9.4，目标是PG9.6，虽然跨小版本兼容，但建议使用目标版本的pg_dump工具重新导出数据，再进行恢复，能减少版本差异带来的潜在问题。比如用PG9.6的Docker容器执行导出命令：

docker run --rm -v /本地备份目录:/pgdump postgres:9.6 pg_dump -Fc -h 你的源PG主机 -p 5432 -U user --no-synchronized-snapshot -Fd --jobs 2 dbname --file="/pgdump/dbname_fd"

额外注意事项 #

• 确保RDS实例的安全组允许你的客户端IP访问5432端口；
• 执行操作前，建议先备份RDS实例，避免误操作导致数据丢失；
• 如果你的业务用户需要操作earthdistance扩展的对象，记得给用户授予对应的权限：

  GRANT USAGE ON SCHEMA earthdistance TO user;
  

内容的提问来源于stack exchange，提问作者mrichter