Safely Configuring Replication for the Schema Database
31 August 2020 03:21 PM
|
|
IntroductionThere 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 (pre-ML9) 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. | |
|