CODEWITHSUNDEEP
azureazure-web-app-service
SB2055
SB2055

Reputation: 12862

Azure Web Site Migrations & Concurrency

I have two Azure Websites set up - one that serves the client application with no database, another with a database and WebApi solution that the client gets data from.

I'm about to add a new table to the database and populate it with data using a temporary Seed method that I only plan on running once. I'm not sure what the best way to go about it is though.

Right now I have the database initializer set to MigrateDatabaseToLatestVersion and I've tested this update locally several times. Everything seems good to go but the update / seed method takes about 6 minutes to run. I have some questions about concurrency while migrating:

What happens when someone performs CRUD operations against the database while business logic and tables are being updated in this 6-minute window? I mean - the time between when I hit "publish" from VS, and when the new bits are actually deployed. What if the seed method modifies every entry in another table, and a user adds some data mid-seed that doesn't get hit by this critical update? Should I lock the site while doing it just in case (far from ideal...)?

Any general guidance on this process would be fantastic.

Upvotes: 1

Views: 164

Answers (2)

ElvisLives
ElvisLives

Reputation: 2275

I agree with the maintenance window idea from Fernando. But here is the approach I would take given your question.

  1. Make sure your database is backed up before doing anything (I am assuming its SQL Azure)
  2. Put up a maintenance page on the Client Application
  3. Run the migration via Visual Studio to your database(I am assuming you are doing this through the console) or a unit test
  4. Publish the website/web api websites
  5. Verify your changes.

The main thing is working with the seed method via Entity Framework is that its easy to get it wrong and without a proper backup while running against Prod you could get yourself in trouble real fast. I would probably run it through your test database/environment first (if you have one) to verify what you want is happening.

Upvotes: 1

Fernando Correia
Fernando Correia

Reputation: 22355

Operations like creating a new table or adding new columns should have only minimal impact on the performance and be transparent, especially if the application applies the recommended pattern of dealing with transient faults (for instance by leveraging the Enterprise Library).

Mass updates or reindexing could cause contention and affect the application's performance or even cause errors. Depending on the case, transient fault handling could work around that as well.

Concurrent modifications to data that is being upgraded could cause problems that would be more difficult to deal with. These are some possible approaches:

Maintenance window

The most simple and safe approach is to take the application offline, backup the database, upgrade the database, update the application, test and bring the application back online.

Read-only mode

This approach avoids making the application completely unavailable, by keeping it online but disabling any feature that changes the database. The users can still query and view data while the application is updated.

Staged upgrade

This approach is based on carefully planned sequences of changes to the database structure and data and to the application code so that at any given stage the application version that is online is compatible with the current database structure.

For example, let's suppose we need to introduce a "date of last purchase" field to a customer record. This sequence could be used:

  1. Add the new field to the customer record in the database (without updating the application). Set the new field default value as NULL.
  2. Update the application so that for each new sale, the date of last purchase field is updated. For old sales the field is left unchanged, and the application at this point does not query or show the new field.
  3. Execute a batch job on the database to update this field for all customers where it is still NULL. A delay could be introduced between updates so that the system is not overloaded.
  4. Update the application to start querying and showing the new information.

There are several variations of this approach, such as the concept of "expansion scripts" and "contraction scripts" described in Zero-Downtime Database Deployment. This could be used along with feature toggles to change the application's behavior dinamically as the upgrade stages are executed.

New columns could be added to records to indicate that they have been converted. The application logic could be adapted to deal with records in the old version and in the new version concurrently.

The Entity Framework may impose some additional limitations in the options, because it generates the SQL statements on behalf of the application, so you would have to take that into consideration when planning the stages.

Staging environment

Changing the production database structure and executing mass data changes is risky business, especially when it must be done in a specific sequence while data is being entered and changed by users. Your options to revert mistakes can be severely limited.

It would be necessary to do extensive testing and simulation in a separate staging environment before executing the upgrade procedures on the production environment.

Upvotes: 1

Related Questions