Войти

pg_dump / pg_restore

Stable

Практический путь миграции через pg_dump и pg_restore через Gateway с TLS.

Обновлено: 5 марта 2026 г.

Миграция через pg_dump / pg_restore — самый понятный и обычно самый безопасный путь переноса данных в SPG99.

1. Подготовьте целевую БД

Создайте tenant и целевую БД в SPG99. Затем заранее выполните обычное тестовое подключение по DSN, чтобы проверить:

  • что credentials корректны;
  • что TLS работает;
  • что возможный cold start произошёл до большого pg_restore.

2. Сделайте dump источника

pg_dump -Fc -h <source-host> -U <source-user> <source-db> > dump.dump

Для больших баз заранее оцените размер дампа и время передачи.

3. Восстановите в SPG99 через Gateway

Вариант через DSN:

export TARGET_DSN="postgres://<pg_user>:<pg_password>@<gateway-host>:5432/<target-db>?sslmode=require"
pg_restore -d "$TARGET_DSN" dump.dump

Вариант через переменные:

export PGPASSWORD="<pg_password>"
export PGSSLMODE="require"
pg_restore -h <gateway-host> -p 5432 -U <pg_user> -d <target-db> dump.dump

4. Проверьте результат

После restore полезно проверить:

  • что схема и основные таблицы на месте;
  • что приложение может подключиться к целевой БД;
  • что расширения и привилегии перенесены ожидаемым образом;
  • что в дамп случайно не попали лишние служебные секреты и конфигурации.

Практические рекомендации

  • для больших баз используйте --jobs, но контролируйте число соединений;
  • при необходимости упрощайте миграцию флагами вроде --no-owner и --no-privileges, если роли в целевом контуре отличаются;
  • если у вас строгие требования к downtime, заранее подготовьте cutover‑чеклист, а не переключайтесь “с руки”.

Когда этот путь особенно хорош

pg_dump / pg_restore стоит выбирать, если вам нужен максимально предсказуемый и простой процесс без сложной фазы длительной синхронизации.

Почему SPG99АрхитектураПлан развитияДокументацияБлог