• Publisert
  • 2 min

Episerver in ReadOnly database mode

In Episerver CMS Core 9.7, there is a new feature to put Episerver's database in ReadOnly mode. When is this useful, and what parts of a site are affected?

ReadOnly mode in an Episerver Alloy demo site
There's a new configuration setting, DatabaseMode, which allows  server admins to specify two distinct modes;
  • ReadWrite (default)
  • ReadOnly
Note that this setting has to be set in web.config, and cannot be changed through Episerver's UI interface. 
Much of this blog post is lifted from the official release notes for Update 100, but I've elaborated on the parts of Episerver that are affected by this setting.

When is ReadOnly useful?

Readonly mode is useful as a temporary stop-gap, primarily for maintenance purposes. 
  • Disaster recovery - If a rollout went bad, or the server is experiencing critically heavy load, divert traffic to a read-only backup version of the site while you work on fixing the production site. Since the database won't change in the mean time, there will be no diff between the backup site and the production site. 


  • Auditing - If you need to (temporarily) freeze access to restricted parts of the site for editors or users.


  • Publishing freeze - When you don't want editors to add new content. This can be useful for upgrade scenarios where you want to copy the production database to your development environment, to run database upgrade scripts and testing, before finally restoring back to production.


What does ReadOnly affect?

The Scheduler Service is disabled. 

This means none of your scheduled jobs (built-in or custom) will be able to run, automatically nor manually.

Many jobs do CRUD operations on content items (which obviously isn't allowed in read-only mode), but running a job also requires updating database fields specific to the scheduled job, like last/next execution date, running status, result, etc.

Model synch is disabled. 

Usually, when the site initializes, Episerver checks if the code contains updates to the content models (GUID, property types/names, etc), and can update them automatically.  In read-only mode, any changes you made to content models won't actually take effect when you deploy them.

Indexing of content is disabled.

Indexing statistics and logging can't be saved to the database in read-only mode. 

User, role and claims synch are disabled.

This basically means no users can login, no users can be created, no users can change their roles, and no profiles can be updated. 
This applies to both external users (think extranet users) using your site's custom login dialog, as well as editors/admins using Episerver's default login screen. None shall pass!
(If read-only mode is enabled, you might want to put up a maintenance banner where your login dialog would usually be, to avoid a flood of support requests from frustrated users. Use IDatabaseMode to check which mode is active.)

Automatic database updating is disabled.

Episerver can be configured to detect if database schema updates are needed (if the database version is lower than the assemblies deployed), and apply the database update script automatically. Obviously, this can't be allowed to happen in read-only mode. 

Statistics Logger is disabled.

Again, logging to the database is a no-go.

Episerver Forms won't work.

Any forms you have on your site (that are configured to save to database) will stop working.
Note: In fact, when I tested a plain Alloy site with CMS 9.7 and Forms 1.0 installed, the site crashed on initialization (because the Forms initialization module tries to synch settings with the database). If you have other initialization modules, you might want to disable them while in read-only mode, to avoid a site crash.