Представьте: ваша база данных PostgreSQL 13 работает под нагрузкой 10 000 RPS, а вам нужно перейти на PostgreSQL 15 без остановки приложения. Обычный дамп и восстановление — это часы даунтайма. Клиенты потеряны, деньги утекают. Каждый час простоя обходится в сотни тысяч рублей. Мы решаем эту задачу через zero-downtime миграцию — с логической репликацией, батчевым переносом и автоматическим переключением. Наш опыт — более 50 успешных проектов, гарантия целостности данных и индивидуальный план для вашей инфраструктуры.
За последние три года мы провели миграции для проектов с нагрузкой от 1 000 до 50 000 RPS. В этой статье разберём два основных подхода — pg_upgrade и logical replication — и покажем, как безболезненно обновить СУБД с сохранением доступности. Стоимость типового проекта — от 300 000 до 600 000 руб., а экономия от устранения даунтайма может превышать 500 000 руб. за час. Закажите консультацию — и мы подготовим индивидуальный план миграции за 1 день.
Принципы zero-downtime миграций
Любое изменение схемы БД проходит через backward-compatible этапы:
- Добавить новое (колонку, таблицу) — приложение игнорирует новое.
- Задеплоить код, который пишет в оба места.
- Мигрировать существующие данные батчами.
- Задеплоить код, который читает только из нового.
- Удалить старое.
Никаких DROP COLUMN и RENAME COLUMN в production за один шаг.
Как выполнить zero-downtime миграцию PostgreSQL?
Способ 1: pg_upgrade с репликой
pg_upgrade быстрее logical replication в 10 раз по времени выполнения, но требует короткого даунтайма для подготовки и не позволяет отката. "pg_upgrade uses hard links to avoid copying data, making it extremely fast."
# 1. Поднять новую версию PostgreSQL рядом apt install postgresql-15 # 2. Остановить запись (короткий даунтайм для подготовки) pg_ctl -D /var/lib/postgresql/14/main stop # 3. pg_upgrade в режиме --link (без копирования файлов) /usr/lib/postgresql/15/bin/pg_upgrade \ --old-datadir=/var/lib/postgresql/14/main \ --new-datadir=/var/lib/postgresql/15/main \ --old-bindir=/usr/lib/postgresql/14/bin \ --new-bindir=/usr/lib/postgresql/15/bin \ --link \ --check # 4. Выполнить upgrade /usr/lib/postgresql/15/bin/pg_upgrade \ --old-datadir=/var/lib/postgresql/14/main \ --new-datadir=/var/lib/postgresql/15/main \ --old-bindir=/usr/lib/postgresql/14/bin \ --new-bindir=/usr/lib/postgresql/15/bin \ --link Режим --link использует hardlinks вместо копирования — для базы в 100 ГБ занимает секунды вместо часов. Недостаток: старую версию после этого не запустить.
Способ 2: Logical Replication (настоящий zero-downtime)
-- На старом сервере (PG 13) CREATE PUBLICATION migration_pub FOR ALL TABLES; -- На новом сервере (PG 15) — создать ту же схему pg_dump -s -U postgres myapp | psql -U postgres -h new-server myapp -- Подписка на репликацию CREATE SUBSCRIPTION migration_sub CONNECTION 'host=old-server dbname=myapp user=replication password=pass' PUBLICATION migration_pub; -- Следить за прогрессом первоначальной синхронизации SELECT subname, received_lsn, latest_end_lsn FROM pg_stat_subscription; После синхронизации:
-- Проверить лаг (должен быть близок к нулю) SELECT now() - last_msg_receipt_time AS subscription_lag FROM pg_stat_subscription; -- Переключение: остановить запись в старую БД, дождаться лага = 0 -- Обновить connection string в приложении -- Удалить подписку DROP SUBSCRIPTION migration_sub; Сравнение методов миграции
| Метод | Время выполнения | Даунтайм | Откат | Дополнительные ресурсы |
|---|---|---|---|---|
| pg_upgrade | Секунды (100 ГБ) | Да (до 5 мин) | Нет | Минимум |
| Logical replication | Часы (настройка) | Нет | Да | Доп. сервер, диски |
Почему схемные миграции требуют нескольких шагов?
Добавление NOT NULL колонки
Нельзя в один шаг — ALTER TABLE заблокирует таблицу на всё время DEFAULT-вычисления. Правильно:
-- Шаг 1: добавить колонку с DEFAULT (PostgreSQL 11+ — instant) ALTER TABLE users ADD COLUMN phone VARCHAR(20) DEFAULT NULL; -- Шаг 2: заполнить данными батчами DO $$ DECLARE batch_size INT := 1000; offset_val INT := 0; BEGIN LOOP UPDATE users SET phone = '' WHERE id IN ( SELECT id FROM users WHERE phone IS NULL ORDER BY id LIMIT batch_size ); EXIT WHEN NOT FOUND; PERFORM pg_sleep(0.01); END LOOP; END $$; -- Шаг 3: добавить NOT NULL constraint (быстро, если нет NULL) ALTER TABLE users ALTER COLUMN phone SET NOT NULL; Переименование колонки
-- Шаг 1: добавить новую колонку ALTER TABLE orders ADD COLUMN customer_id BIGINT; -- Шаг 2: заполнить данными (+ триггер для новых записей) CREATE OR REPLACE FUNCTION sync_customer_id() RETURNS TRIGGER AS $$ BEGIN NEW.customer_id := NEW.user_id; RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER sync_customer_id_trigger BEFORE INSERT OR UPDATE ON orders FOR EACH ROW EXECUTE FUNCTION sync_customer_id(); -- Батчевое заполнение существующих записей UPDATE orders SET customer_id = user_id WHERE customer_id IS NULL; -- Шаг 3: задеплоить код, читающий customer_id -- Шаг 4: удалить старую колонку и триггер ALTER TABLE orders DROP COLUMN user_id; DROP TRIGGER sync_customer_id_trigger ON orders; Инструменты для online миграций
| Инструмент | СУБД | Особенности |
|---|---|---|
| gh-ost | MySQL | Online schema migration без блокировок, от GitHub |
| pg-osc | PostgreSQL | Аналог gh-ost для Postgres |
| Flyway | PostgreSQL, MySQL | Версионирование миграций, поддержка undo |
| Liquibase | PostgreSQL, MySQL | Чейнджлоги в XML/YAML/JSON |
Пример использования gh-ost:
gh-ost \ --host=db-master \ --database=myapp \ --table=users \ --alter="ADD INDEX idx_email (email)" \ --execute Тестирование плана миграции
# Восстановить production dump в staging pg_restore -U postgres -d myapp_staging production.dump # Проверить план миграции psql -U postgres myapp_staging < migration_plan.sql # Замерить время выполнения \timing on \i migration_plan.sql Дополнительные проверки для logical replication
- Убедитесь, что wal_level = logical на старом сервере. - Проверьте, что у пользователя replication есть права на публикацию. - Мониторьте лаг с помощью pg_stat_replication.Мониторинг и готовность к откату
После запуска логической репликации критично отслеживать лаг репликации и здоровье обоих серверов. Мы настраиваем Prometheus + Grafana с дашбордом для pg_stat_replication: лаг более 100 МБ — сигнал замедлить батчевую миграцию или увеличить ресурсы. Параллельно держим наготове rollback-план: при любой аномалии в течение 30 секунд возвращаем traffic на старый сервер. Типичные метрики для мониторинга: received_lsn vs sent_lsn (лаг по байтам), write_lag, flush_lag и replay_lag в pg_stat_replication. При MySQL — Seconds_Behind_Source из SHOW SLAVE STATUS. Нулевой лаг перед переключением достигается остановкой записи на источнике на 2–5 секунд — это единственный момент «риска». Для крупных БД (от 500 ГБ) предварительная синхронизация через rsync или pg_basebackup ускоряет первоначальную подготовку подписки в 3–5 раз по сравнению с чистой репликацией. Мы документируем каждый шаг в runbook-е и обучаем команду заказчика работать с ним.
Что входит в работу
- Аудит текущей схемы БД и версий СУБД.
- Разработка плана backward-compatible миграции.
- Настройка логической репликации или pg_upgrade.
- Батчевый перенос данных с проверкой целостности.
- Мониторинг лага и автоматическое переключение.
- Документация и обучение команды.
- Гарантия rollback-плана на 30 дней.
Сроки и стоимость
Zero-downtime обновление PostgreSQL с logical replication — 2–3 дня. Комплексная схемная миграция с несколькими шагами — 1–2 недели (включая тестирование на staging). Стоимость рассчитывается индивидуально после оценки вашего проекта. Свяжитесь с нами для бесплатной оценки вашего проекта.