Walkthrough: Replicating the Web database using Azure active geo-replication
You can speed up the publishing of content to multiple Web databases by using Azure active geo-replication. Instead of publishing separately to each Web database, you publish to only one and let Azure replicate that database. However, before you can take advantage of geo-replication, you must move the EventQueue, Properties and Tasks tables out of the local Web database and into a separate and shared Web database because they cannot be replicated.
You cannot use Sitecore Publishing Service (SPS) if you set up geo-replication because SPS does not support EventQueue separation.
This walkthrough describes how to:
-
Deploy the application and storage roles
-
Configure the Azure active geo-replication
The traditional publishing configuration
Consider a configuration that consists of the following: A main USA region that handles the content management, a European affiliate region, and an Asian affiliate region. In a traditional publishing configuration, the USA region Content Management (CM) role publishes the content to the Web databases in all three regions, and each regional Web database has its own EventQueue, Properties, and Tasks tables.

Region |
Content Management role |
Web database including EventQueue, Properties, and Tasks tables |
Content Delivery role |
---|---|---|---|
USA |
|
|
|
Europe |
None |
|
|
Asia |
None |
|
|
The accelerated replication configuration
By reconfiguring the same scenario to use Azure active geo-replication, the USA region CM role only publishes to the USA region Web database. On completion, Azure active geo-replication replicates the USA region Web database to the European and Asian Web databases. The three regions share a separate Web database containing the EventQueue, Properties, and Tasks tables that cannot be replicated.

Region |
Content Management role |
Web database |
Content Delivery role |
Shared Web database with EventQueue, Properties, and Tasks tables |
---|---|---|---|---|
USA |
|
|
|
|
Europe |
None |
|
| |
Asia |
None |
|
|
To prevent errors from occurring when you replicate the Web database, disable the CompactClientDataAgent
and CleanupPublishQueue
agents on the CD servers.
To disable the agents, in the Sitecore.CES.GeoIp.config
file, set the interval to "00:00:00":
<!-- Agent to clean up client data -->
<agent type="Sitecore.Tasks.CompactClientDataAgent" method="Run" interval="00:00:00" />
<!-- Agent to clean up publishing queue -->
<agent type="Sitecore.Tasks.CleanupPublishQueue, Sitecore.Kernel" method="Run" interval="00:00:00">
<DaysToKeep>30</DaysToKeep>
</agent>
Deploy the application and storage roles
You must deploy the main USA region as a standard Sitecore installation and remove the Core databases from the Europe and Asia regions.
To deploy the application and storage roles:
-
In the USA region, deploy the CM and CD roles.
-
In the Europe and Asia regions, deploy the CD role only.
NoteYou must configure Azure active geo-replication target databases as read-only.
-
In the Europe and Asia regions, remove the Core database from both regions. You can disable the Security database on a Content Delivery instance if you are not using the Federated Experience Manager (FXM) because the CD role can run without it.
-
Deploy an empty Web database for sharing the separate EventQueue, Properties, and Tasks tables.
ImportantYou might experience decreased performance when the EventQueue, Properties, and Tasks tables are shared by all regions.
-
Configure your Sitecore roles to share the separate EventQueue, Properties, and Tasks database.
Configure the Azure active geo-replication
All that is left to do is to configure Azure active geo-replication to replicate data from the USA region Web database (web_usa
) to the Europe and Asia region Web databases (web_europe
and web_asia
).
On CD roles using replicated Web databases, visitor requests can potentially repopulate the newly cleared cache with old content, until the replication is completed. Sitecore is working on a solution to this.