Sitecore Core Database - multiple copies

Hi All,

Just wanting to get some advice from others who have maybe gone down this route as i've only ever had to work with a single core DB setup and currently considering options for new setup of prod using 2 clusters.

This is all in relation to Sitecore 8.2 (update 5/7) and Sitecore 9 soon.

Say we wanted to setup Sitecore on 2 DCs so for DR purposes if one goes down the other would remain active, CM would remain on 1 DC only.

DC1:

1 CM

1 DB server (Core,Master, Web, session)

2 CD 

 

DC2:

1 DB server (Core2,Web2, Session2)

2 CD 

 

Basically similar to description here: https://doc.sitecore.com/developers/90/platform-administration-and-architecture/en/clustering-and-geographic-distribution.html

There is this statement there:

***********

Each cluster has its own dedicated core database - core databases cannot be replicated and must be managed per cluster. When you set up a new cluster, you can copy the existing core database from your existing cluster to get started.

Note
This setup is not recommended if you are managing extranet users in the core database

***********

 

There is also this link: https://doc.sitecore.com/developers/90/platform-administration-and-architecture/en/scale-databases.html

Which says:

****

If you have multiple Content Delivery clusters, consider dedicating a core database to each cluster

Note
Replication of the core database is not officially supported - refer to the following article for information about supported SQL scaling features: https://kb.sitecore.net/articles/423602

******

So my questions are:

- In this scenario do we need to keep core DB's synched in situations where site doesn't have any login functionality and doesn't use WFFM? 

- In other sites where we do use Virtual Users to authenticate users and based on roles show specific parts of site, and do use WFFM. Do we need to sync the Core DB. (Users are not managed in Sitecore, uses 3rd party authentication) 

- What is the best method to do this sync given replication is not supported (in an Active/Active scenario where both DCs are Active eg 4 Content Delivery Servers are active) and also in Active/Passive scenario where a couple of hours of downtime is acceptable.


Thanks

  • You tagged it with Sitecore 9.1, do you mean you go to Sitecore 9.1? or 9.0..
    There is an interesting difference between 9.0 and 9.1 In Sitecore 9.1 the core database is not needed for the CD. :)

    For Sitecore 9.0, Beside the WFFM (event queue), users in membership tables, the core database also contain for example the API keys needed for JSS. But basically the core db is pretty static for the CD. no need to synchronize if you don't use the exceptions.

  • In reply to Jan Bluemink:

    Thanks for your comment Jan, sorry i should have been more clear. I have a couple of tags because the question is in relation to what we currently have (Sitecore 8.2 Update 5 & 7) but also wanting to know the impact of when we upgrade to 9.1 in future.

    It's also pretty broad because we have a few different sites.

    Some sites have WFFM and some don't. Likewise some are pretty brochureware and so don't have any client side login functionality so no need to worry about membership tables and such whereas some use 3rd party SSO so we use virtual users (the users are managed externally not in sitecore).

    From what i have read, sites where you don't use WFFM and don't use sitecore managed users (or don't need any users at all) then Core does not need to be synched.

    In the case of WFFM it seems that you only need to worry about core DB being in synch if you have the file upload field as that uses the EventQueue? But i can't remember what version i saw that info about.

    Thanks for the info about 9.1 not needing Core DB in CD that is great! I have only had a chance to play around with JSS in 9.0 so haven't delved into 9.1 too much but sounds like things much more straight forward in 9.1.
  • In reply to Santos Nunez:

    For WFFM, it is about the remote save actions, also the create item and some others save action use the event queue, but if you know that you can easily test if not syncing the core db works for you.