psql_tasks/move_psql03.md

Да, вы абсолютно правы! Обычный одиночный файл (-F c) дампится в один поток, и на больших объемах (десятки/сотни гигабайт) это может происходить очень долго.

Использование -F d (Directory format) с флагом -j (jobs / параллельность) ускорит и создание дампа, и его анализ, так как данные таблиц будут выгружаться параллельно в несколько потоков.

Более того, формат каталога (-F d) намного удобнее для выполнения нашей задачи:

1. Вы можете дампить в -j4 или -j8 (по количеству ядер CPU).
2. Вы по-прежнему можете использовать pg_restore с секциями --section=pre-data, --section=data и --section=post-data без ручного редактирования файлов .list!

Ниже обновленный, максимально быстрый пошаговый план.

---

Этап 1. Быстрое создание дампа на dc01-srv01 (в параллельном режиме)

Создаём дамп в виде директории с 4 параллельными потоками:

# Создаем папку под дамп
mkdir -p /opt/pg_dumps/edemo_ehd1.dir

# Запускаем параллельный дамп
pg_dump -h localhost -p 5436 -U postgres -d edemo_ehd1 \
  -F d \
  -j 4 \
  --no-tablespaces \
  --no-owner \
  -f /opt/pg_dumps/edemo_ehd1.dir

Совет: Количество потоков -j выбирайте исходя из доступных ядер процесора на сервере (например, -j 4 или -j 8). Нагрузка на CPU и диски вырастет, но дамп выполнится в разы быстрее.

---

Этап 2. Быстрое восстановление на dc02-srv02 (без ручной нарезки файлов)

Перенесите всю папку /opt/pg_dumps/edemo_ehd1.dir на целевой сервер.

Формат -F d позволяет pg_restore самому разделить процесс на 3 этапа с помощью флага --section. Это избавляет от необходимости вручную правильные листы через .list файлы!

Шаг 2.1. Восстанавливаем структуру (Pre-Data)

Создаем базовые объекты: таблицы, типы, последовательности. Внешних ключей и триггеров на этом этапе нет.

pg_restore -h localhost -p 5432 -U postgres -d edemo_ehd1 \
  -F d \
  --no-tablespaces \
  --no-owner \
  --section=pre-data \
  /opt/pg_dumps/edemo_ehd1.dir

---

Шаг 2.2. Загружаем данные в параллельном режиме (Data)

Отключаем триггеры (--disable-triggers), чтобы исключить ваши ошибки (дедлоки, вызовы функций для несуществующих связей) и включаем многопоточность (-j 4):

pg_restore -h localhost -p 5432 -U postgres -d edemo_ehd1 \
  -F d \
  -j 4 \
  --no-tablespaces \
  --no-owner \
  --section=data \
  --disable-triggers \
  /opt/pg_dumps/edemo_ehd1.dir

Важно: Флаг --disable-triggers сработает корректно только под суперпользователем (postgres).

---

Шаг 2.3. Создаем индексы, ключи, триггеры и вьюхи (Post-Data)

Данные уже на месте. Теперь параллельно накатываем индексы, первичные и внешние ключи, триггеры и представления.

pg_restore -h localhost -p 5432 -U postgres -d edemo_ehd1 \
  -F d \
  -j 4 \
  --no-tablespaces \
  --no-owner \
  --section=post-data \
  /opt/pg_dumps/edemo_ehd1.dir

---

Шаг 2.4. Финальная сборка статистики

После завершения накатывания пост-данных обновляем статистику, чтобы оптимизатор Postgres знал о размерах таблиц:

psql -h localhost -p 5432 -U postgres -d edemo_ehd1 -c "VACUUM ANALYZE;"