pg_dump получает ошибку SSL, кажется, истекло время ожидания

Я пытаюсь загрузить базу данных на свой локальный компьютер, используя 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 соответственно).

Приветствуются любые советы по отладке.

У меня ОС Х 10.8.5. Локальный pg_dump — 9.2.4, сервер — Ubuntu Server, на котором работает psql 9.1.9.


postgresql ssl pg-dump
person Alex Ghiculescu    schedule 31.01.2014    source источник

Ответы (1)


arrow_upward
7
arrow_downward

Это может быть проблема повторного согласования SSL.

См. этот параметр на сервере (postgresql.conf) и связанное с ним предупреждение о старых клиентских библиотеках SSL, хотя OS X 10.8 кажется новее этого.

Из документации 9.1:

ssl_reegotiation_limit (целое число)

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

Повторное согласование снижает шансы злоумышленника на выполнение криптоанализа, когда можно проверить большие объемы трафика, но также приводит к значительному снижению производительности. Сумма отправленного и полученного трафика используется для проверки лимита. Если для этого параметра установлено значение 0, повторное согласование отключено. По умолчанию 512 МБ.

Примечание. Библиотеки SSL, выпущенные до ноября 2009 г., небезопасны при использовании повторного согласования SSL из-за уязвимости в протоколе SSL. В качестве временного исправления этой уязвимости некоторые поставщики поставляли библиотеки SSL, неспособные выполнять повторное согласование. Если такие библиотеки используются на клиенте или сервере, повторное согласование SSL должно быть отключено.

ИЗМЕНИТЬ:

Обновление этого параметра в postgresql.conf требует не перезапуска сервера, а перезагрузки сервера с помощью /etc/init.d/postgresql reload или service postgresql reload.

Значение также можно проверить в SQL с помощью show ssl_renegotiation_limit;

Даже если размер дампа меньше 512 Мб, возможно, объем передаваемых данных намного больше, так как pg_dump сжимает данные локально при использовании пользовательского формата (--format custom).

person Daniel Vérité    schedule 31.01.2014
comment
Я попытался установить это значение на 0, но все равно получил ту же ошибку. (Я не перезапускал postgres, так как в файле .conf было указано, что это необходимо, стоит ли мне попробовать?) Дамп базы данных должен быть намного меньше 512 МБ, чего бы это ни стоило. - person Alex Ghiculescu; 02.02.2014
comment
Хорошо, спасибо, я попробую вне часов пик и дам вам знать, как это происходит. - person Alex Ghiculescu; 03.02.2014
comment
+1, потому что он решил для меня ту же проблему, хотя и в гораздо более простой среде (pg_dump и сервер базы данных находились на одной машине с Debian 7.5). Я бы проверил это как правильный ответ, основываясь на почти 1-часовом поиске, который я провел по этому конкретному сообщению об ошибке. - person Marcello Romani; 11.06.2014
comment
Кроме того, FWIW, я бы перенес этот вопрос на сбой сервера. Просто говорю'. - person Marcello Romani; 11.06.2014