Zero‑down time міграція PostgreSQL та MySQL: покрокове керівництво

Уявіть: ваша база даних 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 етапи:

1. Додати нове (колонку, таблицю) — додаток ігнорує нове.
2. Задеплоїти код, який пише в обидва місця.
3. Мігрувати існуючі дані батчами.
4. Задеплоїти код, який читає тільки з нового.
5. Видалити старе.

Жодних 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;

Порівняння методів міграції

Чому схемні міграції потребують кількох кроків?

Додавання 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:

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

Моніторинг та готовність до відкату

Після запуску логічної реплікації критично відстежувати лаг реплікації та здоров'я обох серверів. Ми налаштовуємо 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). Вартість розраховується індивідуально після оцінки вашого проєкту. Зв'яжіться з нами для безкоштовної оцінки вашого проєкту.

Редизайн та міграція сайту: зміна CMS, збереження SEO

Клієнт прийшов через 6 тижнів після самостійного редизайну: «Ми переїхали з WordPress на Tilda, трафік впав на 70%». Відкриваю Google Search Console — 847 сторінок віддають 404, URL-структура повністю змінилася, жодного 301-редиректу. Яндекс ще не переіндексував новий сайт, позиції впали. Відновлення зайняло 4 місяці та призвело до значних фінансових втрат. Наш досвід — понад 7 років та 80+ успішних міграцій. Клієнти, які замовляють професійну міграцію, відновлюють трафік у 3 рази швидше, ніж ті, хто виконує її самостійно.

Чому міграції ламають SEO?

Пошуковики проіндексували конкретні URL. Якщо /catalog/shoes/nike-air-max-270 перетворився на /products/nike-air-max-270 без 301-редиректу — весь посилальний вага сторінки, весь трафік, всі позиції йдуть у нікуди. Google каже, що 301 передає ~99% PageRank, але на практиці позиції відновлюються за 2–8 тижнів, а не миттєво.

Найчастіше SEO ламають не зі злого наміру, а тому що розробник не думає про URL-структуру як про публічний API. Ось типові поломки:

Як відновити трафік після невдалої міграції?

Якщо трафік впав — дійте негайно:

1. Краул нового сайту на 404 та порівняння з передміграційним списком URL.
2. Створення редиректів для всіх втрачених сторінок з трафіком >0.
3. Перевірка структурованих даних та мета-тегів на тестовій вибірці.
4. Щоденний моніторинг Coverage в Search Console та позицій за топ-50 запитами.
5. Якщо через 2 тижні трафік не відновлюється — глибокий аудит редиректів (транзитивність, ланцюжки, цикли).

У нашій практиці такий випадок: великий інтернет-магазин втратив 50% трафіку при переїзді з Бітрікса на React + Strapi. За три дні відновили 95% редиректів, через 3 тижні трафік повернувся на 90% від початкового.

Як підготувати сайт до міграції: що не можна пропустити?

До початку розробки нового сайту потрібно:

1. Повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексованих URL з трафіком з Google Search Console.
2. Вивантажити всі сторінки з органічним трафіком >0 за останні 6 місяців — це пріоритет для редиректів.
3. Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
4. Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
5. Зберегти Core Web Vitals з Search Console за попередні 90 днів.

Таблиця для фіксації:

Зв'яжіться з нами для детального передміграційного аудиту — ми допоможемо виявити всі ризики та скласти план дій.

Мапінг URL та редиректи

Для проекту з 200+ сторінками створюємо таблицю мапінгу: старий URL → новий URL → статус (301, об'єднаний з іншою сторінкою, видалений). Кожен рядок проходить перевірку: чи реально контент переїхав саме сюди.

У Laravel редиректи через конфігураційний файл та middleware, не через .htaccess — це швидше та керованіше. Для WordPress → Next.js: редиректи налаштовуються в next.config.js (статичні) та на рівні Nginx/CDN для динамічних. Старий .htaccess на shared хостингу з 500+ рядками редиректів — особливий ад. Кожен редирект перевіряється послідовно, продуктивність падає. Переносимо в Nginx map директиву або Redis-кеш для динамічного пошуку.

Міграція контенту з різних CMS

WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API або WP All Export для експорту постів, метаполів, медіафайлів. Скрипт міграції на Node.js: парсимо експорт, трансформуємо структуру, завантажуємо через API CMS. Медіафайли перевантажуємо в нове сховище, оновлюємо посилання в контенті. Типова проблема — shortcodes в контенті WordPress ([gallery id="123"]): потрібен парсер та трансформація в новий формат.

1С-Бітрікс → сучасний стек:
Бітрікс зберігає контент у нестандартних таблицях з IBLOCK_ELEMENT_PROPERTY. Прямий SQL-експорт через phpMyAdmin або Bitrix API. Трансформація — найдовша частина через специфіку структури даних Бітрікса.

Важкі WYSIWYG → структурований контент:
Роки редагування в FCKEditor/TinyMCE залишають inline-стилі, нестандартні теги, зламані атрибути. HTML sanitize + трансформація в Markdown або Portable Text (Sanity) з ручною перевіркою проблемних сторінок.

SEO-збереження технічних елементів

Структуровані дані (Schema.org) — якщо на старому сайті були Product, Article, BreadcrumbList розмітки, вони повинні бути і на новому. Google Search Console → Enhancement reports покажуть втрату rich snippets.

Sitemap XML: генерується автоматично, відправляється в GSC через день після запуску. Старий sitemap залишається до повної переіндексації.

hreflang для багатомовних сайтів: якщо теги загубилися при міграції, через кілька тижнів почнуться конфлікти між мовними версіями у видачі.

Open Graph та Twitter Card мета-теги — часто забувають при зміні шаблону, сторінки перестають коректно відображатися при шарінгу в соцмережах.

Як контролювати сайт після запуску?

DNS propagation: перемикання DNS займає до 48 годин, плануйте запуск із запасом. Cloudflare як DNS-провайдер — propagation займає хвилини, не години.

Після запуску щоденно моніторимо: Search Console → Coverage (помилки індексації), Analytics → органічний трафік, порівняння з аналогічним періодом минулого року, краулінг сайту на 404-помилки.

Перші 2 тижні — критичний період. Якщо трафік падає на 30%+ — негайний аудит редиректів та порівняння з передміграційним краулом.

Що входить в роботу

Результати, які ви отримуєте:

1. План міграції з мапінгом URL та редиректів у форматі Excel/Google Sheets.
2. Налаштовані 301 редиректи на серверному рівні (Nginx/Cloudflare/Vercel).
3. Перенесений контент з перевіркою цілісності: зображення, мета-поля, посилання.
4. Структуровані дані (Schema.org) на новому сайті, ідентичні старим або покращені.
5. Звіт по SEO: динаміка позицій через 1, 3 та 6 тижнів після запуску.
6. Моніторинг Coverage в Search Console з повідомленнями про помилки.
7. Гарантія збереження позицій: якщо трафік падає більш ніж на 15% протягом першого місяця — безкоштовний аудит та корекція.

Терміни та орієнтири

• Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів.
• Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів.
• Тільки технічна частина міграції (редиректи, метадані) без редизайну: 1–3 тижні.

Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.

Отримайте консультацію по вашому проекту — ми відповімо протягом дня. Замовте передміграційний аудит вашого сайту та отримайте точний кошторис з планом редиректів. Зв'яжіться з нами, щоб обговорити деталі.