Восстановление базы данных PostgreSQL из резервной копии без ограничения внешнего ключа

Question

У меня есть база данных postgresql с более чем 85 таблицами. Я регулярно делаю резервные копии, используя pg_dump (через php-pgadmin) в режиме копирования, а размер файла резервной копии составляет почти 10-12 МБ. Теперь проблема, с которой я сталкиваюсь, заключается в том, что всякий раз, когда я пытаюсь восстановить базу данных, возникает проблема ограничения внешнего ключа. Сценарий выглядит следующим образом:

Существует две таблицы: 1) users и 2) zones. Я сохранил идентификатор зоны в таблице users, чтобы определить зону пользователя, и установил ее как внешний ключ.

Когда я беру дамп базы данных, записи для таблицы zones появляются только после таблицы users. Я думаю, что это связано с первой буквой имени таблицы: u предшествует z, и поэтому, когда я восстанавливаю базу данных, возникает проблема ограничения внешнего ключа, и выполнение останавливается. Та же проблема возникает, когда я пытаюсь восстановить структуру базы данных, она говорит, что таблица zones не существует в базе данных, поскольку структура zones идет после структуры users в файле дампа.

Есть ли какое-то решение для этого? Есть ли другой способ резервного копирования?

Answer 1

Похоже, вы получаете дамп SQL, а не двоичный дамп из pg_dump.Это дало бы вам большую кучу SQL со схемой (включая FK) вверху, а затем кучу INSERT для перезагрузки данных.Двоичный дамп из pg_dump будет вам полезнее, похоже, вам нужно немного дополнительной настройки, чтобы сообщить PhpPgAdmin, где pg_dump.Затем вы передадите этот двоичный дамп в pg_restore, а pg_restore перестроит все в правильном порядке, чтобы избежать проблем ссылочной целостности (или, точнее, pg_restore восстановит все данные и добавит ограничения).

Кажется, PhpPgAdmin хочет работать с простыми дампами SQL , а не pg_restore.Мне трудно в это поверить, но я не могу найти ничего в документации о вызове pg_restore.Если это так, то вам, вероятно, придется вручную отредактировать дамп SQL и переместить все FK до конца.

Вы также можете попробовать добавить SET CONSTRAINTS ALL DEFERRED; вверхуваш дамп SQL, который должен задерживать проверку ограничений до конца транзакции, вы также должны убедиться, что весь блок INSERT содержится в транзакции.

Если PhpPgAdmin действительно не может вызвать pg_restore, тогда лучше использовать вручную pg_dump и pg_restore, чтобы иметь необходимый контроль над процедурами резервного копирования.Извините, но любой инструмент администратора базы данных, который не может выполнить резервное копирование базы данных с помощью FK, хуже, чем бесполезен.Надеемся, что кто-то, кто знает, как обойти PhpPgAdmin, появится и расскажет, как использовать pg_restore с PhpPgAdmin.

Answer 2

Если это кому-нибудь поможет: ни одно из предыдущих предложенных решений не сработало для меня (было несколько INSERT, сделавших ссылку на данные, которые впоследствии были выгружены, независимо от того, были ли они в двоичном формате или простые запросы SQL).

Что я сделал: я использовал schemaspy , скрипт, который - среди других функций, таких как действительно полезная HTML-диаграмма базовой модели ER - он генерирует два очень полезных списка: «порядок вставки» (гдевсе ваши таблицы перечислены как оптимальный порядок для выполнения вставок с учетом существующих ограничений и зависимостей), а также «порядок удаления» (очень полезен для таблиц DROP).

Если вы хотите образец, отметьте это http://schemaspy.sourceforge.net/sample/. В частности, есть два примера списков, которые я упомянул выше (пытался публиковать прямые ссылки, но механизм предотвращения спама позволяет публиковать только 2 ссылки).

Answer 3

Я обнаружил, что вы можете добавить в начале sql (это остановит проверку внешнего ключа):

SET session_replication_role = replica;

и в конце (для восстановления чеков):

SET session_replication_role = origin;

Answer 4

с использованием pgdump (через php-pgadmin)

Вы уверены, что PhpPgAdmin использует pg_dump для создания резервных копий? Я никогда не видел ни одного дампа, созданного pg_dump, у которого были проблемы с внешними ключами при восстановлении дампа.

PhpPgAdmin - это всего лишь PHP-скрипт, и в большинстве случаев у него нет прав на запуск программы, такой как pg_dump.

Answer 5

Я бы удалил создание fk заранее и добавил его в конец скрипта.