5

我正在尝试使用pg_dump. 我正在使用的命令是：

pg_dump --host xx.xx.xx.xx --port xxxx --username "xxx" --password  --format custom --blobs --verbose --file "testing.db" "xxx"

当它转储数据库中的最后一个表时，它总是会因以下错误而崩溃：

pg_dump: Dumping the contents of table "versions" failed: PQgetCopyData() failed.
pg_dump: Error message from server: SSL error: sslv3 alert handshake failure
pg_dump: The command was: COPY public.xxx (columns) TO stdout;

我通过 SSH 连接到一个离我正在下载的服务器更近的服务器（我在布里斯班，它在旧金山），并且能够pg_dump毫无问题地做到这一点。所以我知道数据库服务器很好。我怀疑这是超时，因为它在失败之前到达了最后一张桌子；如果它实际上是一个 SSL 错误，我预计它会更快出现。也就是说，每次失败都会在不同的时间后发生超时（最近的两个测试分别在 1300 秒和 1812 秒后失败）。

欢迎任何有关如何调试的提示。

我在 OS X 10.8.5 上。本地 pg_dump 是 9.2.4，服务器是运行 psql 9.1.9 的 Ubuntu Server。

4

1 回答 1

7

这可能是SSL 重新协商问题。

请参阅服务器上的此参数 ( postgresql.conf) 以及有关旧 SSL 客户端库的相关警告，尽管 OS X 10.8 似乎比这更新。

从9.1 文档：

ssl_renegotiation_limit（整数）

Specifies how much data can flow over an SSL-encrypted connection before
renegotiation of the session keys will take place.

当可以检查大量流量时，重新协商会降低攻击者进行密码分析的机会，但也会带来很大的性能损失。发送和接收流量的总和用于检查限制。如果此参数设置为 0，则禁用重新协商。默认值为 512MB。

注意：由于 SSL 协议中的漏洞，2009 年 11 月之前的 SSL 库在使用 SSL 重新协商时是不安全的。作为此漏洞的权宜之计，一些供应商提供了无法重新协商的 SSL 库。如果客户端或服务器上正在使用任何此类库，则应禁用 SSL 重新协商。

编辑：

在中更新此参数postgresql.conf不需要重新启动服务器，但需要使用/etc/init.d/postgresql reload或重新加载服务器service postgresql reload。

该值也可以在 SQL 中使用show ssl_renegotiation_limit;

即使转储的大小小于 512Mb，也可能是传输的数据量更大，因为pg_dump使用自定义格式 ( --format custom) 时会在本地压缩数据。

于 2014-01-31T18:32:24.560 回答