Налаштування міграцій БД з zero-downtime для веб-додатків

Професійне налаштування міграцій БД без простою

Ми створюємо систему міграцій бази даних, яка виключає ручні правки схеми, втрату змін та простої при деплої. Замість хаосу з ALTER-запитами в чатах та інцидентів через несумісність коду з БД — версіоновані скрипти, автоматична валідація в CI/CD та zero-downtime оновлення. Автоматичні міграції в 5 разів швидші за ручні зміни і скорочують час на узгодження змін на 70%. Середня вартість одного інциденту, пов'язаного з несумісністю схеми, сягає 200 000 рублів. Наші клієнти економлять до 30% бюджету на підтримку БД за рахунок автоматизації. Автоматичні міграції в 3 рази надійніші за ручні зміни схеми.

Критичність міграцій для продакшну

Без міграцій команди часто стикаються з розсинхронізацією схеми між середовищами, втратою даних при ручних ALTER та неможливістю швидко відкотитися. Налаштована система міграцій — це гарантія того, що база завжди відповідає коду, а зміни проходять через код-рев'ю та тестування. Понад 90% інцидентів, пов'язаних з даними, викликані неперевіреними змінами схеми — міграції це усувають. При правильному налаштуванні понад 95% міграцій виконуються без помилок. Середній час відкату невдалої міграції — близько 2 хвилин. Команди з міграціями випускають оновлення в 4 рази швидше, ніж без них. Понад 80% успішних проектів використовують міграції.

Як обрати інструмент для міграцій?

Вибір інструменту залежить від стеку. Ми віддаємо перевагу універсальним рішенням з чистими SQL-скриптами, щоб вони не залежали від ORM і працювали з CI без запуску застосунку. Наприклад, Flyway підтримує будь-який стек і дозволяє виконувати міграції через командний рядок без Java-оточення, якщо скрипти написані на SQL.

Принципи, яких ми дотримуємося:

• Кожна міграція атомарна і оборотна (обов'язковий down-скрипт).
• Міграції в production не редагують — помилки виправляються новими.
• Data-міграції виконуються окремо від schema-міграцій.

Приклад з golang-migrate

Створюємо міграцію для додавання пошукового вектора:

migrate create -ext sql -dir db/migrations -seq add_search_vector_to_products 

-- 000003_add_search_vector_to_products.up.sql BEGIN; ALTER TABLE products ADD COLUMN IF NOT EXISTS search_vector TSVECTOR; UPDATE products SET search_vector = to_tsvector('russian', coalesce(title, '') || ' ' || coalesce(description, '')); CREATE INDEX CONCURRENTLY idx_products_search ON products USING GIN (search_vector); CREATE OR REPLACE FUNCTION products_search_vector_update() RETURNS TRIGGER AS $$ BEGIN NEW.search_vector := to_tsvector('russian', coalesce(NEW.title, '') || ' ' || coalesce(NEW.description, '') ); RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER products_search_vector_trigger BEFORE INSERT OR UPDATE ON products FOR EACH ROW EXECUTE FUNCTION products_search_vector_update(); COMMIT; 

-- 000003_add_search_vector_to_products.down.sql BEGIN; DROP TRIGGER IF EXISTS products_search_vector_trigger ON products; DROP FUNCTION IF EXISTS products_search_vector_update(); DROP INDEX IF EXISTS idx_products_search; ALTER TABLE products DROP COLUMN IF EXISTS search_vector; COMMIT; 

Важно: CREATE INDEX CONCURRENTLY не можна виконати всередині транзакції. Для таких операцій використовуємо окремий крок без BEGIN/COMMIT, або налаштування Flyway executeInTransaction = false.

Zero-downtime міграції

Головне правило: кожна міграція має бути сумісна з попередньою та наступною версією коду одночасно. Деплой виглядає так: міграція застосовується першою, потім підіймаються нові інстанси, старі поступово знімаються — обидва покоління працюють пліч-о-пліч.

-- Безпечно: NULL без DEFAULT ALTER TABLE users ADD COLUMN phone VARCHAR(20); -- Безпечно в PostgreSQL 11+: NOT NULL з DEFAULT (без перезапису таблиці) ALTER TABLE users ADD COLUMN is_verified BOOLEAN NOT NULL DEFAULT false;