pg_dump收到SSL错误,似乎超时了

Question

我正在尝试使用下载数据库到我的本地计算机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错误,我预计它会更早出现.也就是说,超时发生在每次失败后不同的时间(两次最近的测试分别在1300s和1812s之后失败).

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

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

Answer 1

这可能是SSL重新联合问题.

请参阅server(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协议存在漏洞,因此使用SSL重新协商时,2009年11月之前的SSL库不安全.作为此漏洞的一个临时修复,一些供应商提供了无法进行重新协商的SSL库.如果客户端或服务器上正在使用任何此类库,则应禁用SSL重新协商.

编辑:

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

也可以在SQL中检查该值 show ssl_renegotiation_limit;

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