Бесшовное обновление Azure при изменении схемы базы данных

Допустим, у меня есть производственное и промежуточное развертывание, использующее собственные базы данных (SQL Azure). Если схема в промежуточной стадии изменилась и ее необходимо развернуть в рабочей среде, существует ли определенный способ обновления базы данных в рабочей базе данных (без простоев)?

например Если я поменяю VIP-сценой & lt; - & gt; производство (и в то же время автоматизировать изменение строк подключения), что является лучшим процессом для автоматизации обновления базы данных sql azure.

Я хотел бы определить изменение среды в RoleEnvironmentChanging (хотя не уверен, что своп VIP даже запускает RoleEnvironmentChanginng) и запустить сценарий sql для будущей базы данных (т.е. prod) в этот момент, однако мне нужно убедиться, что сценарий только запустить один раз, и будет несколько переходов экземпляров.

 astaykov15 мая 2012 г., 11:43
Хороший вопрос. Вещи, которые я знаю (почти) наверняка, это то, что: (1) VIP-свопинг не вызовет RoleEnvironmentChanging. (2) Единственный способ изменить строку подключения - это программно отредактировать файл web.config и получить эту новую строку подключения где-нибудь еще (?). (3) Пока нет автоматизации для изменения строки подключения. Вот почему я вообще не использую поэтапное развертывание. Таким образом, вы могли бы лучше жить с некоторыми простоями и / или ошибками во время обновления сервиса (обновите его с новой версией непосредственно до рабочей / после прохождения тестов на стадии подготовки).

Ответы на вопрос(2)

ка это то, что я делаю:

Deploy to staging (Production is already running) Copy app_offline.htm file to the web root on Production. This way I block users from using the application, thus blocking changes to the database. I am using only one instance. Backup the database. Run DDL, DML and SP scripts. This updates the production database to the latest schema. Test application on Staging. Swap VIP. This brings the application back online since the app_offline.htm file is not present on Staging (new Production). If something goes wrong, swap VIP again, restore database and delete app_offline.htm.

При таком подходе у меня время простоя ~ 5 минут; моя база данных небольшая, что лучше, чем ждать создания виртуальной машины и получения пользователями ошибок.

Решение Вопроса

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

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

If you write any code inside the role to do "ONCE and only ONCE" action, there is no guarantee that that this will happen only ONCE. It will happen multiple time depend on several scenario such as

1.1 In any situation you VM needs to be reimage by the system and this CODE will do the exactly same what it did during last reimage

1.2 You might protect it to not happen at role start or VM start by some registry method of some external key but there is full proof mechanism that not to happen.

Because of it I would suggest when you are ready to SWAP your deployments you can:

2.1 Run the script to update to the production related SQL Azure schema (This will have no impact on application download because it is not touched but while your database schema is updated, you may know better how it impact your application)

2.2 Change the configuration in staging deployment to point to production SQL Azure (This will not have any production application downtime at all)

2.3 SWAP the deployment (This will also have no application downtime)

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

 Ian197122 мая 2012 г., 12:24
Спасибо за это. Я думаю, что ваши предложения в 2 - это то, что мы будем делать (конечно, вначале) Однако, что касается проблем в 1, я думал об использовании таблицы версий чего-либо в базе данных, чтобы база данных всегда знала, в какой версии она находится, чтобы предотвратить запуск сценариев дважды (на самом деле, если я использую EF-миграцию, то я 'll уже есть эта таблица __MigrationHistory ... хммм). Я должен смягчить два случая, начинающихся, конечно, в одно и то же время.
 23 мая 2012 г., 19:11
да, если вы используете что-то вне машины, то это будет работать. Вариант 1) был проблемой, только если вы сделали код зависимым от чего-то в самой виртуальной машине, что не будет сохраняться.

Ваш ответ на вопрос