У меня есть сжатый дамп PostgreSQL на 15 ГБ (как pgbackup), который при извлечении приближается к 60 ГБ. У меня есть облачный сервер только с 69 ГБ свободного места (54 ГБ после того, как pgbackup скопирован в коробку), и мне было интересно, есть ли хитрый способ, которым я мог бы разделить pgbackup на множество меньших сжатых файлов pgbbackup, удалить исходный большой pgbackup, а затем перебирать более мелкие pgbackups, распаковывая, выполняя их и затем удаляя, так что я могу получить весь набор данных в базе данных PostgreSQL с учетом дисковых ограничений.
Вот несколько возможных обходных путей. Выберите тот, который соответствует вашим требованиям.
Ответ довольно прост - используйте трубу:
xzcat dumpFile.xz | pg_restore ....
Таким образом, вам не потребуется дополнительное дисковое пространство для распаковки сжатого файла дампа.
Видеть man pg_restore:
-f имя файла, --file = имя файла
Укажите выходной файл для сгенерированного сценария или для списка при использовании с -l.
По умолчанию - стандартный вывод.
Если у вас заканчивается место на диске, чтобы скопировать сжатый файл дампа на сервер, используйте ssh для вызова:
xzcat dumpFile.xz |ssh -T user@dbserver pg_restore ...
Также альтернативой является изменение конфигурации вашей базы данных postgreSQL, чтобы разрешить соединение с вашей локальной рабочей станции. В этом случае вы можете использовать pg_restore в вашей локальной системе с настройкой PGHOST, PGPORT, PGUSER к правильным значениям.
split команду (или любой аналогичный инструмент), чтобы разрезать его на более мелкие части.На сервере базы данных создайте такое задание, как ожидание получения файлов частичного дампа, например
while sleep 10
do
if [ -r dumpPart ]
then
cat dumpPart
echo "next part is loaded" >&2
rm -f dumpPart
fi
done | pg_restore ....
Загрузите шаг за шагом свои части дампа с именем назначения dumpPart. Убедитесь, что скорость разумно ниже, чем указано выше.