Как безопасно провести выкладку проекта с миграциями?

Question

[Zhandos M]

Здравствуйте!
Столкнулся с проблемой недееспособности проекта во время выкладки с новыми миграциями. Допустим надо накатить новый билд с изменениями в базе в виде миграций, выкладываемый код естественно использует новую структуру БД. Т.к. некоторые миграции могут исполняться значительное время (добавление полей в большую таблицу), проект по сути в это время не работает корректно. Миграции у нас лежат как часть проекта и выкладываются вместе с кодом.
Стало интересно, как эту проблему решают на практике? Первое, что приходит в голову, создавать миграции в отдельном бранче (используем git), сперва применять эту ветку, сделать миграции и только потом заливать билд. Не слишком ли велосипедно?

Answer 1

[Fortop]

Для интенсивного изменения структуры большой базы используйте реплики.

Имеем пару мастер-слейв. При необходимости обновления схемы:

• отключить слейв
  
• провести миграции на нем
  
• сделать его мастером и подключить к нему новый слейв
  
• обновить код проекта при необходимости
  
• переключить его на новый мастер
  
• отключить бывший мастер
  

Comments

[Fortop]

Забыл упомянуть. После длительных миграций естественно скорее всего потребуется дополнительно синхронизировать накопившиеся изменения. Сделать это лучше в полуавтоматическом режиме. То есть собрать дельту и применить её на слейв руками.

[Дэн Иванов]

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

[Fortop]

Дэн Иванов: останавливайте кроны, демоны и прочее. И необходимо не "держать в голове", а иметь чёткий список тех, кто работает с БД.

[Дэн Иванов]

Это конечно вариант, но эта задача может быть не всегда тривиальной.

[Fortop]

Дэн Иванов: будут конкретные вопросы - будет более конкретное решение.

Answer 2

[Дэн Иванов]

Полагаю универсального решения здесь нет. Все зависит от того, сколько "сервисов" пользуются вашей базой, насколько допустим простой каждого из них и насколько гибок Ваш код.
Можно представить себе, что миграция это изменение представления данных. Таким образом, у нас открывается потенциальная возможность использовать view, и работа из кода не напрямую с данными, а с этими самыми view. Т.о. Вы можете создавать новые временные столбцы, нацеливать на них view, а заполнять их при помощи триггера к примеру.
В mysql 5.6 (не прошло и 10 лет !, или прошло ?), в случае если Вы просто меняете имя столбца, копирование во временную таблицу, с соответствующим локом, не происходит.
Т.о. если вы обернете в единую транзакцию (с локом) переименование столбца, и нацеливание view обратно на "изначальное" имя, столбца, вероятно Вам удастся добиться минимального даунтайма.
Миграция, т.о. становится многоходовочкой, но Вы избавляете себя от страха за потерю данных после кривой миграции и упрощаете себе переключение между старыми \ новыми данными, т.к. вы управляете этим из кода миграций.

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

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