Миграция поля — готовим правильно

Многие из нас, делают миграцию по схеме:

  1. создаем бэкап таблицы в которой будет изменено поле и его значения
  2. изменяем значение в поле
  3. изменяем тип поля

Хочется заметить, что это неплохая схема, но она не работает для CI, ведь мы понимаем, что в тот момент, когда мы будем делать миграцию, часть нод все еще может работать с данными до миграции, а часть уже захочет работать с данными после миграции. Как же быть в этом случае? Ответ прост - нужна правильная схема миграции.

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

— Все мы знаем, что такое Кластер и его ноды (Node), а для тех, кто не знал, вот простая схемка:

Миграция поля — готовим правильно

— У нас в компании все делается через PR (Pull Request) в битбакете, Вы для удобства можете рассматривать PR как отдельные коммиты, каждый из которых попадает на ноды с неким промежутком времени.

— Каждый PR выкатывается сначала в директорию tmp, и именно в tmp запускается миграция (таким образом миграция выполняется до выкатки кода на ноду). 

— Важное правило: никаких переименований полей, т.е. мигрированное поле получает новое имя (с номером версии изменения, например field_name_v2) и никогда более не изменяется. Т.е. при следующей итерации миграции будет создано новое поле с именем field_name_v3, а field_name_v2 будет удалено.

Правильная схема миграции данных

1-ый PR (не содержит задачу)

     1. содержит миграцию, которая создает новое поле с именем field_name_v2

     2. теперь код должен сохранять данные в оба поля (field_name и field_name_v2) Обратите внимане, в поле field_name_v2 новые данные должны сохраняться в новом формате данных

2-ой PR

     1. мигрирует данные из поля field_name в поле field_name_v2 (в новый формат)

     2. теперь код начинает читать данные из поля field_name_v2 при этом все еще пишет данные в поле field_name. При этом если говорить о Entity, то setFieldName теперь устанавливает значение полю field_name_v2, а setFieldName теперь устанавливает значение полю field_name

3-ий PR

     1. содержит миграцию, которая удаляет поле field_name (т.к. оно более нигде не используется)

     2. теперь код не работает с полем field_name (данные сохраняются только в поле field_name_v2). 

Готово.

Возможно у Вас возникнут вопросы и я заблаговременно постараюсь на них ответить.


Q: почему миграция 2.1 не может быть выполнена в пункте 1.1

A: потому что в момент между 1.1 и 1.2. часть нод может добавить данные в базу данных только в старом формате. Подробнее:

     1.1. код находится в директории tmp, запускается миграция, дожидаемся создания нового поля

     1.2. последовательно выкатываем код на ноды, и в этот момент некоторые ноды все еще сохраняют данные только в поле field_name, они еще не знают, что нужно также сохранять данные в поле field_name_v2


Q: зачем в 2.2 код все еще пишет данные в поле field_name

A: выкатка кода на ноды выполняется последовательно, поэтому те ноды, на которые еще не пришел PR 2.2., все еще будут читать данные из поля field_name


Как видите, все просто, но если возникли вопросы - пишите в комментариях, удачки.

Оцени публикацию:
  • 0,0
Оценили человек: 0

Похожие статьи:

Справочники и учебники:


Предложения и пожелания:
Ваше имя:
Ваш E-mail:
Сколько будет Οдин + Τри
Главная
X

Новые заметки:

Про что мы забываем когда делаем оценку задачи по времени

Список вопросов для собеседования разработчика по телефону

Symfony2 авторизация без Doctrine2 для чайника

Phpstorm7 LiveEdit

Жесткий хабр или не хабр, тогда кто?

Яндекс.Деньги мошенничество

Как узнать какие страницы в поиске яндекса или это секрет

Последние комменты:

Yapro CMS:

Здравствуйте, Гость | Войти | Регистрация | Карта сайта | RSS ленты | Ошибка в тексте? Выделите её мышкой и нажмите: Ctrl + Enter

youtube.com/watch?v=7hFivbgIEqk

При полном или частичном использовании материалов данного сайта, ссылка на сайт "yapro.ru" обязательна как на источник информации.
Автоматический импорт материалов и информации с сайта запрещен.
Copyrights © 2007 - 2018 YaPro.Ru

Главная » Веб-мастеру » MySQL »