Improvements in Upgrading Sitefinity in Load Balancing Environment

Improvements in Upgrading Sitefinity in Load Balancing Environment

October 22, 2015 0 Comments

In this blog post I would like to explain a new feature released in Sitefinity 8.2 that allows older Sitefinity assemblies to attempt to run on a newer (upgraded) database. As you may know, upgrading Sitefinity in a load balancing environment without downtime and data loss requires quite a complicated deployment setup in order to pull it off. While avoiding downtime is more easily achievable, data loss prevention is the more sensitive and harder to achieve goal. I am not going to go into details about how to achieve such setups, I would like to introduce a handy new feature that will improve the success rate of both of the goals mentioned above, especially when it comes to avoiding downtime.

At its current state, Sitefinity assemblies’ version must be greater or equal to the database schema version. When they are equal, the application is in a stable state. Otherwise, the database is upgraded to version of the assemblies, thus achieving the stable state. Now if by any chance you try to run older assemblies on a newer database that would result in a Yellow Screen of Death screaming: Downgrade is not allowed! To get a better idea of this behavior, see the chart below.

 

Database

Assemblies

Result

1.0

1.0

App is running as usual

1.0

2.0

Assemblies Upgrade Database to 2.0

2.0

1.0

Yellow screen: Downgrade not allowed

 

Throwing this exception is meant to warn you that a downgrade is not allowed and to prevent your web application from starting. Sitefinity can, in fact, start under these conditions but it might be unstable. Notice the word might in the previous sentence. The stability of the application in such a case would depend on the amount and nature of the database changes between the two versions. On a lucky day, the newer database model would have breaking changes in, let's say, the Events but not in the News. For example, if on your homepage you are displaying News, the page will load without problems. If, however, it has Events widget, it will throw an exception related to the change. We can all agree that throwing exceptions is not something you want on your production website. At least not most of the time.

There is one scenario, however, where you might want to give this unstable state a try. For instance, imagine a website in a load balanced environment that has two Sitefinity instances connected to one common database and you need to do an upgrade to a newer version. In order to avoid downtime during the upgrade, which is the point of the load-balanced setup in the first place, you would want to upgrade the instances one by one. However, when you upgrade the first instance, the second one will start throwing the downgrade exception because at that point its assemblies' versions are lower than the database schema version. To reiterate, if this is an upgrade where the breaking database changes do not affect your most visited pages, you might want to give this old instance a shot. This type of scenario is why we introduced the IgnoreDowngradeExceptions setting. By default the warning is set to false, but if you want to set it to true you will need to add it as an attribute to the connection string.

Example:

<add name="Sitefinity" connectionString="data source=.;Integrated Security=SSPI;initial catalog=SitefinityDb" ignoreDowngradeExceptions="true" providerName="System.Data.SqlClient" />

Please be aware that if your configurations are not stored in the files system, but in the database, you can enable this feature by adding SF_ignoreDowngradeException=true directly in the connection string:

<add name="Sitefinity" connectionString="data source=.;Integrated Security=SSPI;initial catalog=SitefinityDb;SF_ignoreDowngradeExceptions=true" providerName="System.Data.SqlClient" />

Such lucky days might be less probable on a major-version upgrade, but would be very probable when upgrading to hotfixes or internal builds. These releases usually contain bug fixes in the code and, very rarely, changes in the database model. Such release is the top candidate for taking advantage of this option.

Remember, the load-balanced communication between the two instances should be interrupted in order to prevent the upgrading instance to restart the old instance while performing the changes. How and why this communication between instances happens is out of the scope of this blog post, but as I said, it is important it is stopped. It can be stopped by removing the configured instances in the System config, under the load balancing section. So in a nutshell, you need to stop the communication between the instances in the System config, and to set ignoreDowngradeExceptions flag of the connection string to true. See the documentation for more details.

However, before you get all excited, there is one final thing to consider. We released this feature with Sitefinity 8.2, but it is meant to be used on the older version in the upgrade process, i.e. the version which you are upgrading from should be at least 8.2. That means you can take advantage of the benefits of this feature when you upgrade to the first internal build after 8.2 or on the next major release.

Give it a try and tell me what you think in the comments below.

Ivan Eftimov

View all posts from Ivan Eftimov on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.

Comments
Comments are disabled in preview mode.
Topics
 
 
Latest Stories in
Your Inbox
Subscribe
More From Progress
d12fcc0bdb669b804e7f71198c9619a7
5 Questions Automakers Should Ask to Improve Asset Uptime
Download Whitepaper
 
SF_MQ_WCM
2018 Gartner Magic Quadrant Web Content Management (WCM)
Download Whitepaper
 
What-Serverless-Means-For-Enterprice-Apps-Kinvey
What Serverless Means for Enterprise Apps
Watch Webinar