From 741b2f2d2d3c107d06408f6083c3f8f61238c298 Mon Sep 17 00:00:00 2001
From: pashko <pm@pm.org.ru>
Date: Tue, 21 Jul 2026 00:52:15 +0800
Subject: [PATCH] Add move_psql03.md

---
 move_psql03.md | 102 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 move_psql03.md

diff --git a/move_psql03.md b/move_psql03.md
new file mode 100644
index 0000000..d503b5a
--- /dev/null
+++ b/move_psql03.md
@@ -0,0 +1,102 @@
+Да, вы абсолютно правы! Обычный одиночный файл (`-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 параллельными потоками:
+
+```bash
+# Создаем папку под дамп
+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)
+
+Создаем базовые объекты: таблицы, типы, последовательности. Внешних ключей и триггеров на этом этапе нет.
+
+```bash
+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`):
+
+```bash
+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)
+
+Данные уже на месте. Теперь параллельно накатываем индексы, первичные и внешние ключи, триггеры и представления.
+
+```bash
+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 знал о размерах таблиц:
+
+```bash
+psql -h localhost -p 5432 -U postgres -d edemo_ehd1 -c "VACUUM ANALYZE;"
+
+```
\ No newline at end of file