{"type":"cluster","id":"d02de413-d5af-4104-a6f9-3a3c2766ee61","metadata": {"state":"AVAILABLE","createdDate":"2020-12-10T12:37:50.000Z","createdBy":"clientname@ionos.com","createdByUserId":"012342f-411f-1eeb-9d07-046c59cc737e","lastModifiedDate":"2020-12-18T21:37:50.000Z","lastModifiedBy":"clientname@ionos.com","lastModifiedByUserId":"012342f-411f-1eeb-9d07-046c59cc737e" },"properties": {"displayName":"an even better name!","location":"de/fra" }, ...}
Upgrading the MongoDB version
DBaaS supports MongoDB versions 5.0 and 6.0. We keep the MongoDB minor version up to date with the MongoDB's latest release for that major version.
Changing the version of a running MongoDB cluster via the API is not allowed.
Scaling a cluster vertically (RAM, CPU, Storage)
DBaaS allows you to scale up and down the size of your database instances. Database instance sizes are managed similarly to Cubes; each template exposes a combination of resource sizes that can be assigned to any of your clusters.
The provisioning engine will delete a secondary replica and create a new server of the desired size. Once ready, it will replicate the existing data to this new server via the MongoDB Replication mechanism. During this procedure, the cluster should operate normally. When the provisioning engine identifies the new server is complete and healthy, it will continue the rollout for every remaining secondary replica up to the primary.
Note: Be prepared for a possible downtime in case of a cluster with only one replica.
Note: Decreasing storageSize to a size lower than your consumed storage is not allowed.
Scaling a cluster vertically (RAM, CPU, Storage)
MongoDB for the Enterprise Edition allow you to freely choose the amount of CPU, RAM and Storage for your cluster. Additionally, you can also choose between the following available StorageTypes: HDD, SSD and SSD Premium.
Note: Decreasing storageSize to a size lower than your consumed storage is not allowed.
Scaling a cluster horizontally (Replicas)
DBaaS allows you to scale up and down the number of database replicas. Increased replica count may result in a cluster with improved availability, performance (capacity to handle more data reads), and fault tolerance for upgrades. A new IP address must be provided for each new instance. To do so, send a PATCH request with the new instances count (supported values are: 1, 3):
The patch example takes a previous cluster with one replica and adds two more replicas to it. The two new IP addresses are added to the connection properties cidrList, and the instances property receives the total number of replicas.
New servers are provisioned and added one at a time to the pool of replicas, implying an incremental rollout.
Downgrading a cluster follows the same pattern, with replica sets being removed one at a time and the desired replica set is reached.
Note: Only MongoDB Business edition provides an option to downscale the number of instances. Scaling down may result in one or more failovers and the disruption of open connections.
DBaaS allows you to increase the number of shards for MongoDB Enterprise sharded clusters. An increased shard count increases the overall storage of the cluster.
Note: We recommend you to review the Considerations before adding shards.
To increase the number of shards, send a PATCH request with the new shards count as shown in the following request:
Note: You can increase the number of shards to a maximum of 100.
The PATCH example modifies a previously created sharded cluster and sets the number of shards to three.
New shards added this way are created by provisioning new servers and adding them to the sharded cluster. Each shard has the number of servers provided by the instances field. Sharded collections' data will then be distributed to the new shards. For more information, see Balancer Internals.
Note: Decreasing shards is currently not possible.
Setting maintenance windows
If you do not specify a maintenance window when creating your database, a random window is assigned. You can update the window at any time, as shown in the example.
If your cluster only has one replica, you may experience a brief outage while your database instance is being updated during this maintenance window. In a replicated cluster, secondaries are updated first and rolled out one by one; each rollout must be complete and healthy before the next one can begin.
Maintenance windows are used to update the cluster's MongoDB minor version. Other maintenance updates related to the cluster infrastructure and security might take place during a maintenance window.
Updating users and roles
The user management for IONOS MongoDB clusters happens completely via the IONOS API. Creation or modification of users from within MongoDB itself is not allowed. For more information, see Users Management.
