When designing for a Geo-Distributed Sitecore implementation you have a decision to make on how you are going to handle updates to your Web databases located in different regions.
Traditionally you would set up a multiple publishing targets – one for each region and publish to each target. However, Sitecore supports Azure Active Geo-Replication of the read-only web database for Sitecore 9.0 and above. Which means you only need to publish to one web database and let Azure SQL replication update the other regions.
While this still experimental it offers faster publishing as you only publish to one target and let Azure handle the updating to the other regions.
Shared Web System DB
For this to work you need to setup a shared web system database to contain a copy of the EventQueue and Properties table, as these cannot be shared and must remain common amongst each Content Delivery role.
Sitecore provides information on how to configure the Content Delivery roles for separate EventQueue and Properties tables.
Having followed Sitecore’s documentation on how to setup the shared Web DB I noticed exceptions and YSOD on each of our Content Delivery instances in the two regions where the CDs were attempting to write to the web database.
Following some troubleshooting with and some help from a friend and colleague Jens Mikkelsen and Sitecore Support we were able to resolve the issue. Basically we had to make some modifications to Sitecore configuration so that the ClientDataStore and TaskDatabase are also located in the newly created Shared Database in the neutral region. NOTE: This was not covered by the Sitecore documentation at the time, I believe the documentation has since been updated.
Sitecore have updated their documentation and posted a few warnings regarding geo-distributed web database:
- Possibility of Stale Content – a visitor could make a request while replication has not yet completed fully causing the newly cleared cache to populate with old content. Sitecore are currently working on a solution for this.
- Decreased performance – you might experience a decrease in performance when the EventQueue and Properties tables are shared by all regions.
While I have not experienced either of these issues in the wild you might want to check with Sitecore if they have a solution or recommendations before you go down the path of geo-replication as every Sitecore implementation is different. I also utilized Sitecore Publishing Service in this implementation.
- Walkthrough: Replicating the Web database using Azure active geo-replication
- Configure Content Delivery roles for separate EventQueue and Properties tables
- Support for SQL scaling options
- How to configure SQL Server Transactional Replication
- SQL Server Replication