💡 Как подготовиться к изменению схемы базы данных

Если вы планируете изменить схему базы данных, то важно тщательно подготовиться к этому процессу. В этом посте мы собрали ключевые шаги, которые помогут вам сделать миграцию безопасной и безболезненной.

1. Определите цель изменения и ожидаемый эффект.

2. Классифицируйте тип изменений

• backward-compatible: добавления, nullable-колонки, индексы
• breaking: переименования, удаления, типовые изменения.

3. Выберите стратегию

• Expand/Contract (двухэтапно: добавляем новое → адаптируем код → удаляем старое)
• Online миграция (pg_repack, gh-ost, pt-online-schema-change)
• Blue-Green или shadow-write/read если критична безостановочность.

4. Спланируйте идемпотентные скрипты миграций и версионирование.

5. Решите, как обрабатывать большие таблицы

• батчи
• lock timeout
• throttling, disable/enable triggers.

6. Найдите все места использования затрагиваемых таблиц/полей: сервисы, джобы, ETL, BI, отчёты, внешние интеграции, функции/триггеры/вьюхи.

7. Проверьте совместимость контрактов API и сериализаций (Protobuf/JSON схемы).

8. Подготовьте репрезентативные объёмы данных в том числе «длинные хвосты», edge-кейсы.

9. Зафиксируйте базовые метрики производительности до изменений: latency, throughput, locks, bloat.

10. Убедитесь в валидном бэкапе: полный + журналы. Сделайте тестовое восстановление.

11. Зафиксируйте точку восстановления: restore point, snapshot, LSN.

12. Для облачных БД — проверьте снапшоты и политику retention.

13. Реализуйте обратную совместимость: код должен работать со старой и новой схемой в переходный период.

14. Обновите ORM-модели/миграции, DTO, валидаторы, GraphQL/REST схемы.

15. Нагрузочное тестирование критичных запросов и миграций: проверка блокировок, регрессий.

16. Обновите диаграммы, спецификации, Confluence/README, схемы событий.

17. Задокументируйте проблемы и фактические времена выполнения, обновите шаблон миграций.

Что бы вы добавили в этот список?

🐸Библиотека шарписта

#буст