You are looking at the documentation of a prior release. To read the documentation of the latest release, please
visit here.
New to KubeDB? Please start here.
This guide will give an overview on how KubeDB Enterprise operator reconfigures MongoDB
database components such as ReplicaSet, Shard, ConfigServer, Mongos, etc.
KubeDB
concepts:The following diagram shows how KubeDB Enterprise operator reconfigures MongoDB
database components. Open the image in a new tab to see the enlarged version.
The Reconfiguring MongoDB process consists of the following steps:
At first, a user creates a MongoDB
Custom Resource (CR).
KubeDB
Community operator watches the MongoDB
CR.
When the operator finds a MongoDB
CR, it creates required number of StatefulSets
and related necessary stuff like secrets, services, etc.
Then, in order to reconfigure the various components (ie. ReplicaSet, Shard, ConfigServer, Mongos, etc.) of the MongoDB
database the user creates a MongoDBOpsRequest
CR with desired information.
KubeDB
Enterprise operator watches the MongoDBOpsRequest
CR.
When it finds a MongoDBOpsRequest
CR, it halts the MongoDB
object which is referred from the MongoDBOpsRequest
. So, the KubeDB
Community operator doesn’t perform any operations on the MongoDB
object during the reconfiguring process.
Then the KubeDB
Enterprise operator will replace the existing configuration with the new configuration provided or merge the new configuration with the existing configuration according to the MogoDBOpsRequest
CR.
Then the KubeDB
Enterprise operator will restart the related StatefulSet Pods so that they restart with the new configuration defined in the MongoDBOpsRequest
CR.
After the successful reconfiguring of the MongoDB
components, the KubeDB
Enterprise operator resumes the MongoDB
object so that the KubeDB
Community operator resumes its usual operations.
In the next docs, we are going to show a step by step guide on reconfiguring MongoDB database components using MongoDBOpsRequest
CRD.