Реалізація міграції даних між версіями бази даних (zero-downtime)

Реалізація міграції даних між версіями бази даних (zero-downtime)

Zero-downtime міграція БД — перехід на нову версію PostgreSQL, MySQL або іншої СУБД без зупинки застосунку. Потребує спеціального підходу до схеми, переносу даних та перемикання трафіку.

Принципи zero-downtime міграцій

Будь-яка зміна схеми БД проходить через backward-compatible етапи:

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

Ніяких DROP COLUMN та RENAME COLUMN у production за один крок.

Оновлення PostgreSQL у мажорній версії (pg_upgrade)

Спосіб 1: pg_upgrade з репліком

# 1. Поставити нову версію PostgreSQL рядом
apt install postgresql-15

# 2. Зупинити запис (короткий downtime для підготовки)
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 замість копіювання — для бази 100GB займає секунди замість годин. Недолік: старину версію після цього не можна запустити.

Спосіб 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;

Схемні міграції без downtime

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

Інструменти

gh-ost (GitHub) — online schema migration для MySQL без блокувань:

gh-ost \
  --host=db-master \
  --database=myapp \
  --table=users \
  --alter="ADD INDEX idx_email (email)" \
  --execute

pg-osc — аналог для PostgreSQL.

Flyway / Liquibase — управління версіями міграцій з підтримкою undo.

Тестування плану міграції

# Відновити 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

Тривалість виконання

Zero-downtime оновлення PostgreSQL з logical replication — 2–3 дні. Комплексна схемна міграція з кількома кроками — 1–2 тижні (включаючи тестування та staging).