Миграции могут уронить проект, как быть?

Question

[123 123]

В моем проекте я пользуюсь yii/migrate, как то раз во время деплоя я поднял миграции и тут случилось оно. Из за миграций бд залочилась, после чего вообще упал MySQL. Причиной была слишком большая таблица с большим кол-во записей, а в миграциях был ADD COLUMN Как быть, как можно подстраховаться в таких случаях, кроме тестирования?

Answer 1

[Александр Аксентьев]

кроме тестирования

а причем здесь тестирование?

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

Comments

[Андрей Токмаков]

Ну речь то не о том, будет работать сайт или нет, я так понял речь о падающей MySQL.
Мне тоже всегда интересно было как добавлять столбец в большую таблицу

[Александр Аксентьев]

Андрей Токмаков: так оно не падает, а лочит наглухо таблицу пока процесс не завершится.

[Андрей Токмаков]

Александр Аксентьев: ну так то это правильно

[123 123]

Речь не данной ситуации, а как в дальнейшем подстраховаться. Проблемы могут быть разные не только большая таблица. Просто до миграций в проекте был просто update.sql и я руками от туда выполнял команды. Теперь перешли на миграции это удобно, но как то не безопасно. Т.к я из начинаю выполнять и не могу контролировать.

[Fortop]

Илья Тетерин: Пишите миграции атомарно. Не забывайте прописывать операцию отката для них

И с контролем все будет ок.

Answer 2

[Евгений Вольф]

Из за миграций бд залочилась, после чего вообще упал MySQL.

Это MySQL, с ним такое бывает.

Причиной была слишком большая таблица с большим кол-во записей, а в миграциях был ADD COLUMN Как быть, как можно подстраховаться в таких случаях, кроме тестирования?

Я не уверен на 100% (ещё не проснулся, что бы слишком трезво соображать), но мне кажется тут есть 2 основных варианта решения проблемы:
1. Не использовать MySQL
2. Использовать репликацию в MySQL

Причиной была слишком большая таблица с большим кол-во записей

Мне кажется, наиболее вероятной проблемой был слишком слабая машина (память, процессор, диск), для такого объёма данных БД, а не слишком большая таблица :)

Comments

[123 123]

О причине это 100%, вопрос о другом. Как юзать миграции более безопасно. См. мой коммент выше.

[Евгений Вольф]

Илья Тетерин:

Теперь перешли на миграции это удобно, но как то не безопасно.

Это удобно максимум, на этапе проектирования БД и её активной разработки, я пока ещё не встречал ни одного программиста в здравом уме, который бы работал в большой компании (над большим проектом) и будучи ответственным за БД - использовал миграции. К тому же, миграции не покрывают даже половины возможностей, даже такой ущербной (в плане возможностей) БД как MySQL, по крайней мере я не видел миграций, которые бы позволяли хотя бы MySQL использовать на полную.

И Ваш вопрос/ситуация, в принципе, прямое подтверждение того, что миграции использовать не стоит. То что удобно, не редко бывает не практично.

P.S. На счёт остановки сайта на тех. обслуживание, которую Вам советуют - мне кажется не актуально, т.к. на остановленной БД вряд ли можно чего-то добавить... А если БД работает, глобального смысла останавливать сайт я не вижу, т.к. если пользовтаелей сайта мало - особой нагрузки они не создадут, а если их много, то резервная копия/зеркало/реплика БД должны быть просто по определению.

Последний совет (ответ), с переименованием таблиц и копированием данных, для MySQL, на мой взгляд, выглядит актуально, сам так делал, но кроме актуальности он так же и добавляет ряд проблем, и в большей степени годится для тех случаев, когда Вы безпроблемно можете отключить БД от нагрузки и заняться переносом данных.

Answer 3

[Fortop]

Не нужно ничего останавливать.
Есть таблица Т.

Схема простая.
1. Сначала создаём пустую таблицу Т1 с нужной структурой. Т.е с уже добавленным столбцом.
2. Затем копируем данные из Т в Т1.
3. Если запись в Т очень активная, то возможно придётся повторить процесс копирования для данных, что добавились пока мы копировали исходные.
4. Когда период копирования станет небольшим отключить запись данных в Т.
5. Сделать финальную синхронизацию.
6. Переименовать Т в Т_OLD.
А T1 переименовать в T
7. Включить запись в Т

Comments

[123 123]

Копирование данных займет уйму времени, там более 100 миллионов записей.

[Fortop]

Илья Тетерин:
Зато сайт у вас будет рабочим практически все время.

ALTER TABLE на такой таблице да еще под нагрузкой гарантированно положит вам сайт на несколько часов.
Если для вас это не критично - то кладите его.