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

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

  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:
Введите изображенные цифры:
Captcha
Главная
X

youtube.com/watch?v=7hFivbgIEqk

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

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