Уявіть: ваша база даних PostgreSQL 13 працює під навантаженням 10 000 RPS, а вам потрібно перейти на PostgreSQL 15 без зупинки додатка. Звичайний дамп і відновлення — це години даунтайму. Клієнти втрачені, гроші витікають. Кожна година простою коштує сотні тисяч гривень. Ми вирішуємо це завдання через zero‑down time міграцію — з логічною реплікацією, батчевим перенесенням та автоматичним перемиканням. Наш досвід — понад 50 успішних проєктів, гарантія цілісності даних та індивідуальний план для вашої інфраструктури.
Ми провели міграції для проєктів з навантаженням від 1 000 до 50 000 RPS. У цій статті розберемо два основні підходи — pg_upgrade та logical replication — і покажемо, як безболісно оновити СУБД зі збереженням доступності. Вартість типового проєкту — від 300 000 до 600 000 грн, а економія від усунення даунтайму може перевищувати 500 000 грн за годину. Замовте консультацію — і ми підготуємо індивідуальний план міграції за 1 день.
Принципи zero‑down time міграцій
Будь-яка зміна схеми БД проходить через backward‑compatible етапи:
- Додати нове (колонку, таблицю) — додаток ігнорує нове.
- Задеплоїти код, який пише в обидва місця.
- Мігрувати існуючі дані батчами.
- Задеплоїти код, який читає тільки з нового.
- Видалити старе.
Жодних DROP COLUMN і RENAME COLUMN у production за один крок.
Як виконати zero‑down time міграцію 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‑down time)
-- На старому сервері (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‑down time оновлення PostgreSQL з logical replication — 2–3 дні. Комплексна схемна міграція з кількома кроками — 1–2 тижні (включно з тестуванням на staging). Вартість розраховується індивідуально після оцінки вашого проєкту. Зв'яжіться з нами для безкоштовної оцінки вашого проєкту.