Безопасно ли выполнять миграцию в живой базе данных?

Question

У меня есть простое приложение с поддержкой рельсов, работающее на 2-3 миллиона просмотров в день с базы данных Heroku Ronin. Нагрузка на базу данных довольно легкая, и она может обрабатывать намного больше, чем мы бросаем на нее.

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

Время простоя неприемлемо даже на несколько минут.

Если текущие миграции в реальном времени нецелесообразны, то, что я, вероятно, сделаю, это создать новую базу данных, запустить миграцию на ней, написать сценарий для синхронизации двух баз данных, а затем указать приложение на новое ,

Но я предпочел бы избежать этого, если это возможно. :)

Answer 1

Похоже, ваша миграция включает в себя:

• добавления новых таблиц (возможно, индексы Если да, то это может занять немного больше времени, чем вы могли бы ожидать?)
• добавление новых столбцов (значения по умолчанию и/или обнуляемым ?)
• оберточной изменения в транзакции()

Предлагаем Вам оценить влияние, что ваши изменения будут оказывать на окружающую среду Prod по:

• принимая резервную Prod (со всеми данными Prod внутри)
• работают скрипты изменений против этого. Время каждой операции

Баланс на 2 пункта выше против типичного чтения & нагрузки записи в то время, что вы ожидали, чтобы запустить это (02:00, верно?).

Рассмотрите «мягкий» простоя, отключив (как-то) операции записи к выполняемым таблицам.

В целом (или вообще) добавление n таблиц и новых столбцов с нулевым значением в существующую таблицу могло бы/могло бы быть выполнено без какого-либо простоя или воздействия производительности.

Всегда измерьте влияние ваших изменений на копию продукта Prod. Измените «отзывчивость» на момент внесения изменений в эту копию. Разумеется, это означает также развертывание другой копии вашего приложения Prod, но это было бы полезно.

Answer 2

Добавление таблиц не должно вызывать беспокойства, так как ваше приложение не будет знать о них до тех пор, пока не будут выполнены соответствующие обновления. Что касается добавления столбцов в основную таблицу, я не уверен. Если вам действительно нужно предотвратить время простоя, возможно, лучше добавить дополнительную таблицу, которая (связанная идентификатором с основной таблицей) добавляет дополнительные столбцы.

Только мои два цента.

Answer 3

Предполагая, что это база данных pg (что должно быть для Heroku).

http://www.postgresql.org/docs/current/static/explicit-locking.html

alter table приобретет доступ монопольную блокировку. Таким образом, таблица будет заблокирована.

Кроме того, вам потребуется перезапустить приложение Rails, чтобы он знал о любых новых моделях. Если вы собираетесь добавлять таблицы в приложение или модифицировать код модели каким-либо образом.

Что касается указания на новое приложение со свежей измененной базой данных, как вы собираетесь выполнять синхронизацию данных, а также синхронизировать изменения данных между двумя базами данных за время, которое занимает синхронизация?