Миграция схемы базы данных без даунтайма для postgresql на примере django
Введение
Привет, Хабр!
Хочу поделиться опытом написания миграций для postgres и django. Речь в основном пойдёт про postgres, django же здесь хорошо дополняет, так как из коробки имеет автоматическую миграцию схемы данных по изменениям модельки, то есть имеет довольно полный список рабочих операций по изменению схемы. Django можно заменить на любой любимый фрэймворк/библиотеку — подходы скорее всего будут похожи.
Не буду описывать как я к этому пришёл, но сейчас читая документацию ловлю на мысли, что нужно было с большей внимательностью и осознанием делать это раньше, поэтому очень рекомендую.
Перед тем как пойти дальше позволю себе сделать следующие предположения.
Можно разделить логику работы с базой данных большинства приложений на 3 части:
- Миграции — изменение схемы базы данных (таблиц), предположим мы всегда запускаем их в один поток.
- Бизнес логика — непосредственная работа с данными (в пользовательских таблицах), работает с одними и теми же данными постоянно и конкурентно.
- Миграции данных — не изменяют схемы данных, работают по сути как бизнес логика, по умолчанию, когда будем говорить про бизнес логику, будем также подразумевать и миграции данных.
Даунтайм — это состояние, когда часть нашей бизнес логики не доступна/падает/грузится на заметное для пользователя время, предположим это пару секунд.
Отсутствие даунтайма может быть критическим для бизнеса условием, которого любыми усилиями нужно придерживаться.
Использовать БД только для складирования данных — это всё равно, что назвать Unix интерфейсом для работы с файлами. Посему, хочу напомнить об известных и не очень функциях БД, которые хотелось бы чаще встречать в боевых веб-приложениях.
Чтобы сделать мониторинг полезным, нам приходится прорабатывать разные сценарии вероятных проблем и проектировать дашборды и триггеры таким образом, чтобы по ним сразу была понятна причина инцидента. 