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

Question

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

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

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

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

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

Answer 1

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

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

Предложите вам оценить влияние, которое ваши изменения окажут на вашу среду Prod, по:

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

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

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

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

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

Answer 2

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

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

alter table получит эксклюзивный замок доступа. Итак, стол будет заблокирован.

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

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

Answer 3

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

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