Safely Configuring Replication for the Schema Database
23 May 2017 06:31 PM
There have been a number of reported incidents where database replication has been configured and where the main Schema database on the replica has been used alongside database replication; in a situation where MarkLogic's default Schema database is used for data, replicating the Schemas database to itself on a foreign cluster will cause instability and likely will lead to a system outage that can only be resolved by breaking replication for the Schemas database.
MarkLogic's documentation on database replication warns users against this, stating that:
You cannot replicate a Master database that acts as its own schema database. When replicating a Master schema database, create a second empty schema database for the Replica schema database on the Replica cluster.
What happens if I attempt to do this?
In earlier releases of MarkLogic Server, this has been known to cause cluster outage and several support cases have been raised due to this configuration causing undesired - and unexpected - results.
In newer releases of the product (such as MarkLogic 8.0-5 and above), the Admin GUI on port 8001 and our admin APIs will now stop users from making this configuration change in the following ways:
This is still an issue for MarkLogic 7 and earlier releases, so it's important to always ensure that you are using a separate database for your replica as advised in our documentation.
Best Practice: Always separate out Schemas Databases where necessary
If your application makes use of Schemas, create a completely separate schemas database for your application. Doing this keeps your application self contained and allows you to replicate it as you would with any other database.