New to KubeDB? Please start here.
Reconfiguring MongoDB
This guide will give an overview on how KubeDB Ops-manager operator reconfigures MongoDB
database components such as ReplicaSet, Shard, ConfigServer, Mongos, etc.
Before You Begin
- You should be familiar with the following
KubeDB
concepts:
How Reconfiguring MongoDB Process Works
The following diagram shows how KubeDB Ops-manager 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
Provisioner operator watches theMongoDB
CR.When the operator finds a
MongoDB
CR, it creates required number ofPetSets
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 aMongoDBOpsRequest
CR with desired information.KubeDB
Ops-manager operator watches theMongoDBOpsRequest
CR.When it finds a
MongoDBOpsRequest
CR, it halts theMongoDB
object which is referred from theMongoDBOpsRequest
. So, theKubeDB
Provisioner operator doesn’t perform any operations on theMongoDB
object during the reconfiguring process.Then the
KubeDB
Ops-manager operator will replace the existing configuration with the new configuration provided or merge the new configuration with the existing configuration according to theMongoDBOpsRequest
CR.Then the
KubeDB
Ops-manager operator will restart the related PetSet Pods so that they restart with the new configuration defined in theMongoDBOpsRequest
CR.After the successful reconfiguring of the
MongoDB
components, theKubeDB
Ops-manager operator resumes theMongoDB
object so that theKubeDB
Provisioner 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.