How many forests should my Security database have?
21 May 2020 02:51 PM
The Security database is typically fairly small and there is really no reason to have more than one forest for the Security database. Having more than one Security forest causes additional complexity during failover events, server upgrades, and restarts. Given how critical the Security database is for the cluster, it is less damaging for it to have a single forest and failover when it goes down, rather than go into a difficult to resolve state with multiple forests.
In terms of forest failover, one or at most two local disk failover forests may and should be configured for high availablity. In terms of database replication, replica forests in replica clusters can be configured.
If you have more than one Security forest(s):
We have seen incidents where customers attached more than one Security forest either intentionally or inadvertently (scripting bug or user error) and run into issues while detaching them.
Most of the issues are rebalancer related. Since the rebalancer is 'on' for all databases by default, when a new forest is attached, the database would automatically redistribute the content across all attached forests. This is expected behavior and how the rebalancer normally works. However, problems arise when forests are detached without first retiring them. This is generally true for any database, but it is particularly problematic when dealing with the Security database.
When a Security database forest is detached without first retiring it, a portion of the Security documents are effectively removed from the database - which causes users to be locked out of the cluster (in this case, please contact MarkLogic Support to help with the repair).