Пошаговая миграция PostgreSQL в облако

Версию PostgreSQL 14 пора переносить: 12 ноября 2026 года она уходит в End-of-life (EOL), то есть её поддержка официально прекращается. Нужно либо обновляться, либо наконец принимать решение о переезде в облако. Самостоятельный апгрейд мажорных версий требует остановки сервиса на десятки минут, ручной правки расширений и последующих недель на настройку автоматических бэкапов, мониторинга, репликации. Managed DBaaS снимает эту работу: версию, резервные копии, реплики и апгрейды берёт на себя платформа. Остаётся вопрос: как перенести production-базу без потери данных и без простоя на часы.

В статье — пошаговый план для DBA, DevOps-инженеров и разработчиков, которые мигрируют PostgreSQL в Managed PostgreSQL в VK Clouds. Команды проверены на PostgreSQL 14–17, акцент — на двух рабочих сценариях: дамп-восстановление для разовых переносов и логическая репликация для миграции без простоя.

Подготовка к миграции: аудит и планирование

Инвентаризация текущей базы данных

До первой команды pg_dump фиксируем шесть параметров: версию PostgreSQL, общий объём данных, количество таблиц и индексов, список расширений, кастомные процедуры и триггеры, внешние зависимости вроде FDW. Это нужно, чтобы реалистично оценить длительность миграции.

sql

-- Размер БД и топ-10 таблиц по объёму
SELECT pg_size_pretty(pg_database_size('mydb'));

SELECT schemaname, relname,
       pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;

-- Установленные расширения
SELECT extname, extversion FROM pg_extension;

-- Список таблиц публичной схемы
SELECT schemaname, tablename FROM pg_tables WHERE schemaname = 'public';

-- Активные соединения и состояния
SELECT pid, usename, state, query_start FROM pg_stat_activity;

Оценка требований к целевой среде

Берём объём хранилища с запасом 2× от текущего: учитываем рост во время миграции, временные WAL-сегменты, индексы после REINDEX. Пиковые IOPS снимаем через pg_stat_io — это показывает не оценочную, а реальную картину нагрузки. Чтобы выбрать корректное значение RAM-инстанса, оцениваем shared_buffers (обычно 25% от RAM инстанса).

Облачный PostgreSQL имеет определенный набор доступных расширений, который может быть расширен по запросу, поэтому совместимость проверяем до миграции, а не во время cutover (переключения между базами).

Выбор стратегии миграции

Есть два рабочих подхода:

• Дамп и восстановление (pg_dump/pg_restore). Окно простоя — от десятков минут до нескольких часов на БД 100–500 ГБ. Подходит для staging, dev-окружений, разовых переносов с согласованным maintenance window.
• Логическая репликация (поддерживается всеми актуальными версиями). Миграция без простоя: cutover-окно меньше минуты при правильной подготовке. Метод для production с жёстким SLA.

Для production-систем с пользовательской нагрузкой подойдёт только логическая репликация. Дамп оставляем для разовых задач и небольших БД.

Шаг 1. Создание целевой базы данных в VK Cloud

Создание инстанса PostgreSQL через панель управления

Раздел «Базы данных» → «Инстансы баз данных», нажимаем «Добавить». Выбираем версию PostgreSQL. Мы рекомендуем версию, совпадающую с исходной или выше. На 2026 год актуальны мажоры 15–17, актуальный список поддерживаемых мажоров уточняйте в DBaaS VK Cloud. При переезде учитывайте, что 14 версия перейдет в EOL с 14 — 12 ноября 2026. Также выбираем конфигурацию vCPU/RAM, объём диска с запасом 2×, зону доступности, виртуальную сеть для подключения.

Конфигурация выбирается на том же шаге: Single (одиночный инстанс), Master-Replica или кластер с автоматическим failover. Для PostgreSQL 16 доступна мультизональная конфигурация с повышенной отказоустойчивостью. PostgreSQL в облаке разворачивается за несколько минут — без ручной установки, настройки репликации и бэкапов.

Настройка сетевого доступа и security groups

Порт 5432 открываем только для IP приложений и машины миграции — настраивается в разделе «Виртуальные сети» → «Настройки firewall». Выставлять его в открытый интернет нельзя — это базовое требование безопасности. Между сервисами внутри облака подключение идёт через виртуальную сеть, что снижает задержку и не тарифицируется как исходящий трафик.

Проверка совместимости расширений

Сверяем список расширений из исходной БД (SELECT extname FROM pg_extension) с поддерживаемыми базами данных в VK Cloud. Стандартный набор доступен: PostGIS, pg_trgm, uuid-ossp, hstore, pgcrypto — последние три входят в бандл postgres_extensions. Из специализированных в VK Cloud DBaaS доступны: TimescaleDB (time-series), pg_partman (партиционирование), pg_hint_plan (управление планами запросов), pg_stat_kcache (статистика по системным вызовам), pgBadger (анализ логов), JsQuery. Полный актуальный список и версии — в документации VK Cloud DBaaS.

Шаг 2. Миграция PostgreSQL через pg_dump и pg_restore

Этот метод — основной для разовых переносов с допустимым окном простоя. pg_dump-миграция работает на любых версиях PostgreSQL и не требует настройки репликации, но downtime растёт линейно с объёмом данных.

Создание дампа исходной базы данных

Формат custom (-Fc) — рабочий выбор для БД до ~500 ГБ: один файл, встроенное сжатие, селективное восстановление, возможность параллельного restore через pg_restore -j.

bash

pg_dump -h SOURCE_HOST -U postgres -d mydb -Fc \
  --no-owner --no-privileges \
  --no-publications --no-subscriptions \
  -f mydb_backup.dump

Ключевые параметры:

• -Fc — формат custom: один файл, встроенное сжатие zlib.
• --no-owner --no-privileges — обязательны при миграции в managed DBaaS: в VK Cloud DBaaS роли по умолчанию отличаются от self-hosted, и без этих флагов восстановление прервётся с ошибкой прав на ROLE/GRANT.
• --no-publications --no-subscriptions — отрезаем старые слоты репликации, чтобы не перенести их вместе с дампом и не упереться в конфликт слотов на целевой стороне.
• --schema-only / --data-only — раздельный экспорт схемы и данных. Пригодится для сценария с логической репликацией: схему льём первой, данные приходят через подписку.

Флаг -j N (параллельный дамп) работает только с форматом directory (-Fd), а не с custom (-Fc) — это частая ошибка. Для БД больше 500 ГБ используем directory-формат:

bash

pg_dump -h SOURCE_HOST -U postgres -d mydb -Fd -j 4 \
  --no-owner --no-privileges \
  --no-publications --no-subscriptions \
  -f mydb_backup_dir

Оптимум -j — vCPU - 1 на источнике, или 4–6 для 8-ядерного сервера. max_connections на источнике должен быть не меньше jobs + 1, иначе дамп прервётся на старте.

Передача дампа на целевой сервер

Три рабочих варианта:

• Через pipe (pg_dump | pg_restore) — самый быстрый: не требует промежуточного хранения и двойного дискового бюджета. Но при разрыве сети процесс начинается заново — не подходит для нестабильных каналов и БД больше десятков гигабайт.
• Через объектное хранилище VK Cloud (S3-совместимое) — практичный паттерн для больших БД и нестабильных каналов: загружаем дамп в Object Storage, восстанавливаем в managed DBaaS через временный bastion-инстанс в той же виртуальной сети. Это надёжный, воспроизводимый сценарий, при котором дамп остаётся как артефакт

Прямая передача через pipe: bash

pg_dump -h SOURCE_HOST -U postgres mydb -Fc \
  --no-owner --no-privileges \
  --no-publications --no-subscriptions \
  | pg_restore -h TARGET_HOST -U postgres -d mydb

Восстановление и проверка

bash

pg_restore -h TARGET_HOST -U postgres -d mydb \
  -Fc -j 4 --no-owner --no-privileges \
  mydb_backup.dump

Параллельное восстановление (-j 4) ускоряет процесс в 3–4 раза на 8-ядерном целевом инстансе.

После восстановления — обязательный набор проверок: sql

-- Сверка количества строк по ключевым таблицам
SELECT 'orders' AS t, COUNT(*) FROM orders
UNION ALL
SELECT 'users', COUNT(*) FROM users;

-- Все ли индексы на месте
SELECT schemaname, tablename, indexname
FROM pg_indexes WHERE schemaname = 'public';

-- Обновить статистику планировщика — без этого первые запросы пойдут по плохим планам
ANALYZE VERBOSE;

-- Список sequences (last_value читается напрямую из самой sequence)
SELECT sequence_schema, sequence_name FROM information_schema.sequences;

Шаг 3. Миграция без простоя через логическую репликацию

Этот метод — для production-систем с SLA, где окно простоя измеряется минутами, а не часами. Миграция без простоя через встроенную логическую репликацию PostgreSQL — рабочий стандарт с 2017 года.

Важно для managed-сценария. В VK Cloud изменение параметров wal_level=logical, max_replication_slots, max_wal_senders и доступ к роли с атрибутом REPLICATION не выдается — самостоятельная правка postgresql.conf в managed-сервисе ограничена. Для self-hosted источника на on-premise шаги ниже выполняются полностью.

Принцип логической репликации PostgreSQL

PostgreSQL поддерживает встроенную логическую репликацию с версии 10. Принцип: исходная БД становится publisher, целевая — subscriber. Изменения (INSERT/UPDATE/DELETE/TRUNCATE) реплицируются на основе декодированных записей WAL, без побайтовой репликации файлов — поэтому версии publisher и subscriber могут различаться по мажору (только в направлении младший → старший или равный).

Ограничения, которые нужно знать заранее:

• DDL-изменения не реплицируются автоматически — схему синхронизируем отдельно через pg_dump --schema-only. Все изменения ALTER TABLE и прочий DDL во время миграции сначала применяем на стороне подписчика, потом на стороне паблишера, чтобы не случалось ошибок логической репликации из‑за рассинхрона схем.
• Sequences не реплицируются — значения обновляем вручную через setval перед cutover.
• Large objects (pg_largeobject, lo_*) не реплицируются вовсе — миграция БД с large objects через логическую репликацию невозможна, для них нужен дамп.
• Materialized views не реплицируются — переносим как пустые, обновляем REFRESH MATERIALIZED VIEW после cutover.
• TRUNCATE реплицируется, но падает на subscriber, если на нём нужно усечь группу таблиц с CASCADE а среди этих таблиц есть те, у которых есть внешние ключи к таблицам, не входящим в подписку. В этом случае применение TRUNCATE на подписчике завершается ошибкой проверок FOREIGN KEY и требует ручной обработки.
• Таблицы без PRIMARY KEY требуют REPLICA IDENTITY FULL — иначе UPDATE и DELETE не реплицируются. Это утяжеляет WAL, поэтому до миграции добавляем PK там, где это возможно.

Настройка publisher на исходном сервере

В postgresql.conf:

text

wal_level = logical
max_replication_slots = 10
max_wal_senders = 10

Перезапуск PostgreSQL обязателен — все три параметра требуют рестарта, на лету не подтягиваются. В pg_hba.conf добавляем строку для пользователя репликации с конкретного IP subscriber'а:

text

host    mydb    replicator    SUBSCRIBER_IP/32    scram-sha-256

Создаём роль и publication:

sql

-- Пользователь с правами репликации
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'strong_password';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO replicator;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO replicator;

-- Publication для всех таблиц схемы
CREATE PUBLICATION mypub FOR ALL TABLES;

Настройка subscriber на целевом сервере (VK Cloud)

Сначала переносим схему (без данных) в DBaaS VK Cloud — без этого CREATE SUBSCRIPTION упадёт на отсутствующих таблицах:

bash

pg_dump -h SOURCE_HOST -U postgres -d mydb --schema-only \
  --no-owner --no-privileges \
  --no-publications --no-subscriptions \
  | psql -h TARGET_HOST_VK -U postgres -d mydb

Затем создаём subscription:

sql

CREATE SUBSCRIPTION mysub
CONNECTION 'host=SOURCE_HOST port=5432 dbname=mydb user=replicator password=strong_password sslmode=require'
PUBLICATION mypub;

PostgreSQL автоматически выполнит initial sync (по умолчанию copy_data = true) и перейдёт в режим потоковой репликации. Контроль состояния — на subscriber:

sql

SELECT subname, received_lsn, latest_end_lsn,
       (latest_end_lsn - received_lsn) AS lag_bytes
FROM pg_stat_subscription;

Когда lag_bytes стабильно держится около нуля — репликация догнала источник и готова к cutover.

Переключение трафика: процедура cutover

При правильной подготовке можно добиться окна простоя менее минуты. Для этого нужно:

1. Перевести приложение в режим read-only — через feature flag, переменную окружения или временное отключение write-эндпоинтов.
2. Дождаться полной синхронизации: lag_bytes = 0 в pg_stat_subscription на протяжении 10–30 секунд.
3. Обновить sequences вручную. Без этого первые же INSERT на новой БД упадут с конфликтом по первичному ключу:

sql

-- Список sequences (last_value читается напрямую из самой sequence)
SELECT sequence_schema, sequence_name FROM information_schema.sequences;
-- Текущее значение конкретной sequence:
SELECT last_value FROM mytable_id_seq;
-- На subscriber, для каждой sequence
SELECT setval('mytable_id_seq', (SELECT MAX(id) FROM mytable));

4. Переключить connection string приложения на VK Cloud DBaaS — через ConfigMap, переменные окружения или централизованный secret manager.
5. Проверить работоспособность: тестовая запись, чтение, отсутствие ошибок в логах приложения и метриках.
6. Удалить subscription и роль репликации на источнике:

sql

DROP SUBSCRIPTION mysub;

Сравнение методов миграции

Практическое правило: до 100 ГБ и при окне 1–2 часа — pg_dump/pg_restore. От 100 ГБ или при требовании к минимальному downtime — встроенная логическая репликация.

Типичные ошибки при миграции и как их избежать

Типовые ошибки накапливаются на стыке подготовки и cutover: проблема выглядит безобидно на staging, а в production оборачивается ночным инцидентом. Разберём пять ошибок, которые встречаются чаще всего.

Несовпадение версий PostgreSQL

pg_restore не восстановит дамп из новой мажорной версии в более старую. Если source работает на PostgreSQL 16, а target — на 14, восстановление упадёт на синтаксисе или системных каталогах. Поэтому целевая версия должна быть равна исходной или выше.

Если миграция совпадает со сменой мажорной версии, есть два пути:

• pg_upgrade на исходном кластере с последующим переносом дампа.
• Логическая репликация между разными мажорными версиями: она работает в диапазоне 10 → 18 и снимает совместимость как отдельную проблему.

Для крупных баз второй вариант предпочтителен, так как обновление и переезд совмещаются в одном окне. У managed-сервиса есть нюанс: обновление мажорной версии в DBaaS VK Cloud выполняется последовательно, без пропуска промежуточных версий (10 → 11 → 12 → 13 → 14 и так далее).

Незавершённые транзакции в момент снятия дампа

pg_dump строит консистентный снапшот и ждёт, пока освободятся блокировки. Если в базе висит сессия в состоянии idle in transaction, дамп не стартует. Перед запуском дампа стоит остановить приложение или перевести приложение в read-only после чего проверить активные транзакции:

sql

SELECT pid, usename, state, xact_start, query
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND xact_start < NOW() - INTERVAL '5 minutes';

Зависшие сессии завершаем через SELECT pg_terminate_backend(pid).

Забытые sequences и их сброс

Логическая репликация не реплицирует sequences, а при восстановлении из дампа их значения могут отставать от реальных MAX(id) в таблицах. После переключения (switchover) первая же вставка падает с ошибкой «duplicate key value violates unique constraint» — последовательность автоинкрементного ключа отстаёт от данных и выдаёт уже занятое значение. Для автоинкрементного первичного ключа это критично.

Решение — пересчитать все sequences по фактическим максимумам. Скрипт, который сгенерирует SQL для всех колонок с привязанной sequence:

sql

-- Сгенерировать setval-команды для всех serial/identity-колонок
SELECT format(
  $$SELECT setval(%L, (SELECT COALESCE(MAX(%I), 1) FROM %I.%I));$$,
  pg_get_serial_sequence(quote_ident(n.nspname)||'.'||quote_ident(c.relname), a.attname),
  a.attname, n.nspname, c.relname
)
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_attribute a ON a.attrelid = c.oid
WHERE c.relkind = 'r'
  AND n.nspname = 'public'
  AND pg_get_serial_sequence(quote_ident(n.nspname)||'.'||quote_ident(c.relname), a.attname) IS NOT NULL;

Сгенерированный набор setval прогоняем сразу после восстановления и перед тем, как пустить трафик приложения. Для миграций с большим числом таблиц без PK дополнительно проверяем REPLICA IDENTITY FULL — без него UPDATE и DELETE не реплицируются через логический поток.

Недостаточные права у пользователя репликации

При неверных правах подписчик просто молча не получает данные. У пользователя репликации должны быть:

• запись в pg_hba.conf с правом replication;
• SELECT на все таблицы публикации;
• атрибут REPLICATION у самой роли.

Команды для подготовки:

sql

GRANT SELECT ON ALL TABLES IN SCHEMA public TO replicator;

Параллельно проверьте, что в дампе не остались чужие subscriptions и publications с исходного кластера.

Несовместимые расширения в целевой DBaaS

В managed-окружении список расширений ограничен политикой провайдера. Если приложение опирается на postgis, pgvector или pg_cron, а в целевой DBaaS их нет, об этом стоит узнать до миграции, а не в момент pg_restore. Запрос на исходной базе:

sql

SELECT extname, extversion FROM pg_extension;

Полученный список сверяем с документацией. Для каждого неподдерживаемого расширения есть три стратегии: найти альтернативу (например, заменить pg_cron на внешний планировщик), отказаться от функционала, если он не критичен, или поднять самостоятельный инстанс на IaaS. Большие объекты реплицировать через логический поток тоже не получится: для таблиц с lo-полями придётся использовать pg_dump или физическую репликацию.

Чек-лист проверки после миграции

Чек-лист имеет смысл прогнать сначала на staging-копии, а затем повторить в production-окружении — расхождения между средами выявляются именно так.

Настройка PostgreSQL в облаке после миграции

Миграция не заканчивается командой pg_restore. Облачный PostgreSQL работает на инстансах с заранее заданным CPU, RAM и IOPS — параметры, скопированные с on-premise сервера, в этой среде дадут либо OOM (Out Of Memory), либо недозагрузку ресурсов. Адаптировать конфигурацию под облако нужно сразу после переезда, иначе production столкнётся с непредсказуемой латентностью под нагрузкой.

Ключевые параметры конфигурации

Стартовая конфигурация для инстанса 16 ГБ RAM выглядит так:

text

# postgresql.conf — стартовые значения для 16 GB RAM инстанса
shared_buffers = 4GB
effective_cache_size = 12GB
work_mem = 8MB
maintenance_work_mem = 1GB
max_connections = 200
wal_level = replica
autovacuum_vacuum_scale_factor = 0.05
track_io_timing = on

Здесь:

• shared_buffers — 25% от RAM. Базовая рекомендация сообщества, проверена на большинстве OLTP-нагрузок.
• effective_cache_size — 75% от RAM. Подсказка планировщику о том, сколько данных реально лежит в page cache.
• work_mem — 4–16 МБ старт. Память выделяется на каждый сортировочный/хеш-узел запроса. Считать нужно по формуле work_mem × max_connections × среднее число параллельных операций — иначе при пике база уйдёт в своп.
• max_connections — держим в разумных пределах. Большие значения снижают производительность из-за переключения контекста на сотнях параллельных backend-процессов. Для масштабирования используем встроенный в DBaaS VK Cloud PgBouncer в режиме pool_mode = transaction: лимит клиентских подключений задаётся параметром max_client_conn и держит за пулом сотни клиентов на десятке физических коннектов к БД.
• wal_level = replica — минимум для физической репликации и резервных копий. Значение logical нужно, только если планируется логический поток наружу.
• autovacuum_vacuum_scale_factor = 0.05 — снижаем порог запуска autovacuum для крупных таблиц. На дефолтных 0.2 autovacuum приходит слишком поздно, и таблицы успевают раздуться.
• track_io_timing = on — нужен для адекватной статистики в pg_stat_statements (по умолчанию off из-за оверхеда на вызов системного таймера).

Настройка автоматических резервных копий

• При создании инстанса в managed Databases VK Cloud выбираем Point-in-time recovery (PITR — полные копии + WAL-архивы) а также частоту бэкапирования и глубину хранения. Что задаём при настройке:
• Окно бэкапа. Сдвигаем на ночные часы или период минимальной нагрузки — снимок снижает доступные IOPS.
• Периодичность и количество хранимых копий. Задаются при создании инстанса. Для production-нагрузок разумная отправная точка — копии за 2–4 недели на случай восстановления после человеческой ошибки.
• PITR через WAL-архивы. Восстанавливает на любую секунду внутри окна хранения — критично, когда нужно откатиться к состоянию «за минуту до того, как уронили таблицу».

Главное правило: бэкап, который ни разу не восстанавливали, не существует. Тестовое восстановление в отдельный инстанс — регулярная процедура, а не разовая галочка при запуске. Минимум — раз в квартал, для критичных баз — ежемесячно.

Ключевые метрики мониторинга

Минимальный набор метрик, по которому видно состояние базы:

• Connections. Количество активных и idle-сессий из pg_stat_activity. Сигнал тревоги — приближение к max_connections или рост idle in transaction.
• Cache hit ratio. При корректно подобранном shared_buffers держится выше 99%. Падение ниже — сигнал к анализу запросов или увеличению инстанса.
• Replication lag. Для физической репликации — pg_stat_replication, для логической — pg_stat_subscription. Лаг свыше нескольких секунд означает, что подписчик не успевает.
• Slow queries. Запросы с mean_exec_time > 100 мс из pg_stat_statements — первоочередные кандидаты на оптимизацию.
• Bloat. Раздувание таблиц и индексов оценивается через pgstattuple и анализ pg_freespace. При bloat выше 30% индекс стоит перестроить через REINDEX CONCURRENTLY.
• WAL generation rate. Объём WAL в секунду показывает реальную интенсивность записи и помогает планировать ёмкость дисков и пропускную способность реплик.

Быстрые SQL-запросы для регулярной проверки: sql

-- Cache hit ratio (должен быть > 99%)
SELECT sum(blks_hit) * 100.0 / NULLIF(sum(blks_hit + blks_read), 0) AS cache_hit_ratio
FROM pg_stat_database;

-- Топ-10 самых долгих запросов
SELECT query, calls, mean_exec_time, total_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

В управляемых базах данных VK Cloud базовые метрики уже выведены на дашборд, но pg_stat_statements и кастомные SQL-проверки стоит подключить к собственной системе алертинга — например, через Prometheus postgres_exporter. Так инцидент будет виден раньше, чем о нём сообщит пользователь.

Заключение

Миграция PostgreSQL в облако перестала быть проектом на месяцы. Логическая репликация переносит нагруженную базу без простоя, дамп закрывает staging и небольшие инстансы за пару часов. Ключевые риски — забытые sequences, несовпадение мажорных версий, неполные права у роли репликации — отсекаются чек-листом перед началом работ по миграции. Managed DBaaS снимает дальнейшее обслуживание: обновления, резервные копии, настройку реплик берёт на себя платформа.

12 ноября 2026 года заканчивается поддержка PostgreSQL 14. После этой даты патчи безопасности выходить не будут. Миграция в облако решает сразу две задачи: закрывает проблему EOL и передаёт администрирование провайдеру. Остаётся настроить мониторинг, прогнать чек-лист после переезда и адаптировать конфигурацию под облачный инстанс.