Maintenance window is a weekly four-hour window. All changes that may cause service interruption (like upgrades) will be executed within the maintenance windows. During maintenance window, an uncontrolled disconnections and inability to connect to cluster can happen. Such disconnections are destructive for any ongoing transactions and also clients should reconnect.
Maintenance window consists of two parts. The first part specifies the day of the week, while the second part specifies the expected time. Here is an example of a maintenance window configuration:
For more information, see Create a Cluster.
MongoDB is a widely used NoSQL database system that excels in performance, scalability, and flexibility, making it an excellent choice for managing large volumes of data. MongoDB offers different editions tailored to meet the requirements of enterprise-level deployments, namely MongoDB Business and MongoDB Enterprise editions. You can try out MongoDB for free with the MongoDB Playground edition and further upgrade to Business and Enterprise editions.
MongoDB Playground is a free edition that offers a platform to experience the capabilities of MongoDB with IONOS. It provides one playground instance for free and each additional instances created further are charged accordingly. You can prototype and learn how best the offering suits your enterprise.
MongoDB Business is a comprehensive edition that combines the power and flexibility of MongoDB with additional features and support to address the needs of businesses across various industries. It provides an all-in-one solution that enables organizations to efficiently manage their data, enhance productivity, and ensure the reliability of their applications.
MongoDB Enterprise is a powerful edition of the popular NoSQL database system, MongoDB, specifically designed to meet the demanding requirements of enterprise-level deployments. It offers a comprehensive set of features, advanced security capabilities, and professional support to ensure the optimal performance, scalability, and reliability of your database infrastructure.
IONOS DBaaS offers you a replicated MongoDB setup in minutes.
DBaaS is fully integrated into the Data Center Designer. You may also manage it via automation tools like Terraform and Ansible.
Compatibility:
DBaaS currently supports MongoDB Playground versions 5.0 and 6.0.
DBaaS currently supports MongoDB Business versions 5.0 and 6.0.
DBaaS currently supports MongoDB Enterprise versions 5.0 and 6.0.
Locations:
Offered in the following locations: de/fra, de/txl, gb/lhr, es/vit, us/ewr, us/mci and fr/par.
Offered in the following locations: de/fra, de/txl, gb/lhr, es/vit, us/ewr, us/mci and fr/par.
Offered in the following locations: de/fra, de/txl, gb/lhr, es/vit, us/ewr, us/las, us/mci and fr/par.
The MongoDB Playground, MongoDB Business, and MongoDB Enterprise editions offer the following key capabilities:
Availability: Single instance database cluster with a small cube template availability.
Security: Communication between instances and between the client and the database cluster is protected with Transport Layer Security (TLS) using Let's Encrypt.
Resources: Cluster instances are dedicated Servers, with a dedicated CPU, storage, and RAM.
Backup: Backups are disabled for this edition. You need to upgrade to MongoDB Business or MongoDB Enterprise to avail database backup capabilities.
High availability: Multi-instance database clusters across different physical hosts with automatic data replication and failure handling.
Security: Communication between instances and between the client and the database cluster is protected with Transport Layer Security (TLS) using Let's Encrypt.
Management: Efficient monitoring and management are essential for maintaining the health and performance of MongoDB deployments. IONOS MongoDB Business Edition includes powerful monitoring and management tools to simplify these tasks. The MongoDB management enables centralized monitoring, proactive alerts, and automated backups, allowing businesses to efficiently monitor their clusters and safeguard their data.
Resources: Cluster instances are dedicated Servers, with a dedicated CPU, storage, and RAM. All data is stored on high-performance directly attached NVMe devices and encrypted at rest.
Backup: Daily snapshots are kept for up to seven days.
Restore: Databases can be restored from snapshots.
Shards: Supports horizontal scalability through MongoDB sharding, which allows for data to be distributed across multiple servers. For an example of how to create a sharded cluster, see Create a Sharded Database Cluster.
Resources: Cluster instances are Virtual Servers with a boot and a data volume attached. The data volume is encrypted at rest.
BI Connector: The MongoDB Connector for BI allows you to query MongoDB data with SQL using tools such as Tableau, Power BI, and Excel. For an example of how to create a cluster with a BI Connector, see Enable the BI Connector.
Network: Clusters can only be accessed via private LANs.
High availability: Multi-instance clusters across different physical hosts with automatic data replication and failure handling.
Security: Communication between instances and between the client and the cluster is protected with Transport Layer Security (TLS) using Let's Encrypt.
Backup: Daily snapshots are kept for up to seven days.
Restore: Databases can be restored from a specific snapshot given by its ID or restored from a point in time given by a timestamp.
Offsite Backup: Backup data is stored in a location other than the deployed database cluster.
Enterprise Support: With MongoDB Enterprise, you gain access to professional support from the MongoDB team ensuring that you receive timely assistance and expert guidance when needed. IONOS offers enterprise-grade Service Level Agreements (SLAs), guaranteeing rapid response times and 24/7 support to address any critical issues that may arise.
Note: IONOS Cloud does not allow full access to the MongoDB cluster. For example, due to security reasons, you cannot use all roles and need to create users via the IONOS API.
DBaaS services offered by IONOS Cloud:
Our platform is responsible for all back-end operations required to maintain your database in optimal operational health. The following services are offered:
Database management via the DCD or the DBaaS API.
Configuring default values, for example for data replication and security-related settings.
Automated backups for 7 days.
Regular patches and upgrades during the maintenance.
Disaster recovery via automated backup.
Service monitoring: both for the database and the underlying infrastructure.
Customer database administration duties:
Tasks related to the optimal health of the database remain the responsibility of the user. These include:
choosing adequate sizing,
data organization,
creation of indexes,
updating statistics, and
consultation of access plans to optimize queries.
Cluster: The whole MongoDB cluster is currently equal to the replica set.
Instance: A single server or replica set member inside a MongoDB cluster.
MongoDB Backups: A cluster can have multiple snapshots. A snapshot is a copy of the data in the cluster at a certain time and is added during the following cases:
When a cluster is created, known as initial sync which usually happens in less than 24 hours.
After a restore.
Every 24 hours, a base snapshot is taken, and every Sunday, a full snapshot is taken.
Snapshots are retained for the last seven days; hence, recovery is possible for up to a week from the current date. You can restore from any snapshot as long as it was created with the same or older MongoDB patch version.
Snapshots are stored in an IONOS S3 Object Storage bucket in the same region as your database. Databases in regions where IONOS S3 Object Storage is not available is backed up to eu-central-2.
Warning: If you destroy a MongoDB cluster, all of its snapshots are also deleted.
MongoDB Enterprise edition supports Offsite Backups, this allows backup data being stored in a location other than the deployed database cluster.
Available locations are de, eu-south-2, eu-central-2.
Info: The location can only be set during cluster creation. Changes to the backup location of a provisioned cluster will result in unexpected behaviour.
Recovery is achieved via the restore jobs. A restore job is responsible to create and catalog a cluster restoration process. A valid snapshot reference is required for a restore job to recover the database. The API exposes available snapshots of a cluster.
There must be no other active restore job for the cluster to create a new one.
Warning: When restoring a database, it is advised to avoid connections to it until its restore job is complete and the cluster reaches AVAILABLE state.
This feature is available only for enterprise clusters. The restoration of cluster here includes points in time and operations log (oplog) timestamps. A custom snapshot can be created for the exact oplog timestamp that you choose to restore the database cluster is possible with point in time recovery.
For more information on restoring database from backup by using the Cloud API, see Restore a Database.
Note: Currently, DBaaS - MongoDB does not support scaling existing clusters.
The WiredTiger cache uses only a part of the RAM; the remainder is available for other system services and MongoDB calculations. The size of the RAM used for caching is calculated as 50% of (RAM size - 1 GB) with a minimum of 256 MB. For example, a 1 GB RAM instance uses 256 MB, a 2 GB RAM instance uses 512 MB, a 4 GB instance uses 1.5 GB, and so on.
You get the best performance if your working set fits into the cache, but it is not required. The working set is the size of all indexes plus the size of all frequently accessed documents.
To view the size of all databases' indexes and documents, you can use a similar script as described in the MongoDB Atlas documentation. You must estimate what percentage of all documents are accessed at the same time based on your knowledge of the workload.
Additionally, each connection can use up to 1 MB of RAM that is not used by WiredTiger.
The disk contains:
OpLogs for the last 24 hours. The size of these depends on your workload. There is no upper limit, so they can grow quite large. But they are removed after 24 hours on their own.
The data itself. Operating systems and applications are kept separately outside the configured storage and are managed by IONOS.
Connection Limits: As each connection requires a separate thread, the number of connections is limited to 51200 connections.
CPU: The total upper limit for CPU cores depends on your quota. A single instance cannot exceed 31 cores.
RAM: The total upper limit for RAM depends on your quota. A single instance cannot exceed 230 GB.
Storage: The upper limit for storage size is 4 TB.
Backups: Storing cluster backups is limited to the last 7 days. Deleting a cluster also immediately removes all backups of it.
IP Ranges: The following IP ranges cannot be used with our MongoDB services:
172.16.0.0/12
192.168.230.0/24
To guarantee partition tolerance, only odd numbers of cluster members are allowed. For the playground edition you can only have 1 replica. All other editions allow the use of 3 replicas. Soon we will allow more than 3 replicas per cluster.
The secondary instances are automatically highly available and replicate your data between instances. One instance is the primary, which accepts write transactions, and the others are secondary, which can optionally be used for read operations.
The instances in an IONOS MongoDB cluster are members of the same replica set, so all secondary instances replicate the data from the primary instance.
By default the write concern before acknowledging a write operations is set to "majority" with j: true. The term "majority" means the write operation must be propagated to the majority of instances. In a three-instance cluster, for example, at least two instances must have the operation before the primary acknowledges it. The j option also requires that the change has already been persisted to the on-disk journal of these instances.
If data is not replicated to the majority, it may be lost in the event of a primary instance failure and subsequent rollback.
You can change the write concern for single operations, for example due to performance reasons. For more information, see Write Acknowledgement.
You can determine which instance to use for read operations by setting the read preference on the client side, if your client supports it. For more information, see Read Preference.
If you read from the primary instance, you always get the most up-to-date data. You can spread the load by reading from secondary sources, but you might get stale data. However, you can get consistency guarantees using a Read Concern.