Ops Tools
457 results found
-
On demand snapshots in Ops Manager
Allow the possibility of performing a snapshot on-demand.
Usually the snapshot time ends too far away in time after configuration changes of the backup job (i.e: changing the block size). For testing purposes it would make sense to allow performing a snapshot on-demand to get it generated and proceed with further testing/tuning if required.
80 votesWe have begun development to allow on demand snapshots in a future version of Ops Manger and Cloud Manager. I will provide an update at later time with a potential release date
-
Allow Ops Manager users to move/migrate backup job snapshots from one S3 bucket to a different S3 bucket
Ops Manager users with S3 blockstores may need to move snapshots and backup jobs to a new S3 bucket. For MongoDB blockstores, this is accomplished using a groom.
Move Blocks to a Different Blockstore
https://docs.opsmanager.mongodb.com/current/core/administration-interface/#groom-priority-pageThis feature request is to provide the same feature to groom backup snapshots/jobs to a new bucket for S3 blockstores.
42 votes -
Show time it took to complete a snapshot
In order to better troubleshoot snapshot performance issues, or maintain an understanding of how snapshots are performing and whether one is approaching a threshold where they wont be able to keep up, its a good idea to expose how long a snapshot took in the View All Snapshots page. This would also aid in quickly identifying which snapshots are full vs incremental.
41 votes -
OpsManager Application DataBase Backup and Restore
Ops Manager Application needs a way to backup and restore AppDB without Ops Manager Downtime to recover from infrastructure failures or fatal errors.
39 votes -
Provide recurring/daily reporting on backup status from Ops Manager
Ops Manager should generate a recurring/daily report of the status of all backups. This report should include at least a list of successful snapshots, a list of unsuccessful snapshots (over the configured reporting period), and the latest successful snapshot for each deployment being backed up. Additionally, this report may include resource availability such as storage available for future snapshots.
39 votes -
Support migrations to different snapshot stores
Currently it is not possible to transition between snapshot store types.
There are two options currently when transitioning to the new one.
- Terminate backups (deleting all previous snapshots)
- Create a new project and abandon the previous one to allow automated restores at a later time
Both of these options are difficult to manage for large deployments. The first option requires you to store the snapshots elsewhere and disallows automated restores. The second option requires many operations and clutters the Ops Manager project list.
Ideally we should be able to transition from any store location/type to any other location/type. One of…
31 votes -
Configure Ops Manager LDAP Auth via an API call
Currently, there is no way to enable LDAP Auth for the Ops Manager Users via an API call.
This essentially means that one would not be able to use LDAP and ci/cd simultaneously with Ops Manager.
Mongodb enterprise support has confirmed that in the event of disaster recovery or a deployment of a new cluster, manual steps must be done to enable LDAP during a ci/cd deployment.
It should not be expected to sign in and manually do anything in a web gui in an enterprise solution. It is simply not scalable.
22 votes -
Add support for virtualization volume management in Ops Manager Backup snapshots and restores.
Streaming snapshots during a restore from a blockstore out to the MongoDB Agent cases the RTO (recovery time objective) to grow linearly with the compressed datasize in the largest shard/RS of the snapshot. The RTO of an Ops Manager restore could be very significantly improved by leveraging volume management infrastructure (such as from VMWare) to restore previously acquired snapshots as virtual filesystems (volumes).
22 votes -
Automated restores between multiple Ops Manager deployments
Ability to utilize API and/or UI to restore a snapshot downloaded from one Ops Manager deployment to a separate distinct Ops Manager deployment.
Some environments require separation of Production and Staging systems, including Ops Manager deployments. It is desirable to use Production data in some testing scenarios. Currently the data has to be loaded or restore manually.
21 votes -
Ops Manager: Test Failover
The ability to Test Failover was added to Atlas https://docs.atlas.mongodb.com/tutorial/test-failover.
Please add this functionality to Ops Manager in order to facilitate failover testing. This is especially useful in multi-tenant Ops Manager setups.
19 votes -
Add the ability for the backup daemon to download and validate snapshots
In order to test snapshots automatically, create a new job type that allows the Backup Daemon to download the snapshot from the snapshot store, then run validate on each collection.
If any collection fails validation, send an alert to the Backup Admin with the list of corrupted data.
18 votes -
Ops Manager API call for Host Mappings
This feature request is for a new Group/Project API call for the management of the host mappings created in Ops Manager from monitoring information. Whether it be an endpoint for "Reset Duplicates" or full featured create/delete of individual host mappings, both will alleviate issues where overlapping mappings affect monitoring in Ops Manager.
Note: The issue of overlapping mappings may occur when a mongod process has moved/changed IP addresses multiple times. With enough cycling (as seen in Kubernetes clusters with frequent pod restarts), eventually a previously mapped IP address may now be associated with a different mongod process.
17 votes -
Headless OPS Manager deployment
Currently Ops Manager CRD deployment requires configuration using GUI which is a manual step. An option completely define all OPS Manager settings / Org in declarative manner via yaml will be great in building completely automated CI/CD Pipelines
17 votes -
SNMP traps for `AUTOMATION_AGENT_DOWN`, `MONITORING_AGENT_DOWN`, `BACKUP_AGENT_DOWN` alert types does not contain hostname information
What is the problem that needs to be solved? SNMP traps for
AUTOMATION_AGENT_DOWN
,MONITORING_AGENT_DOWN
,BACKUP_AGENT_DOWN
alert types does not contain hostname information in.1.3.6.1.4.1.41138.1.1.1.4
(.iso.org.dod.internet.private.enterprises.mms.server.serverMIBObjects.mmsAlertObject.mmsAlertHostAndPort
) OID.Why is it a problem? (the pain) User is blocked to act quickly on the alert and identify the host where Ops Manager's Automation/Monitoring/Backup Agent is in
DOWN
state. Missing<HOSTNAME>:<PORT>
information at.1.3.6.1.4.1.41138.1.1.1.4
SNMP OID does not allow user to mapAUTOMATION_AGENT_DOWN
,MONITORING_AGENT_DOWN
,BACKUP_AGENT_DOWN
alert types into a particular hostname.17 votes -
arm64 support for Kubernetes Operator
Arm64 processors are getting more and more popular. Would be really nice to be able to run MongoDB Kubernetes Operator on a Raspberry Pi cluster.
Otherwise, meanwhile would be nice to get documentation updated on how to produce arm64 images to still make it possible without having full CI infrastructure support.
16 votesARM support is now in progress for the Community Operator (https://github.com/mongodb/mongodb-kubernetes-operator) and will be released in the next few weeks.
ARM support for the Enterprise Operator is TBD but is in the roadmap, likely for 2024.
-
Change namespace option on mongomirror
I was wondering why you can migrate data but you actually (as far I as saw) cannot change the database name during the process of migration (not using mongod/mongorestore unix/win commands but Atlas directly).
From the technical support:
"This is because Live Migration using mongomirror as an underlying process, which in this case tails the oplog and recreates the data exactly as is. This tool is typically used to minimize downtime, especially in production environments, for users who are migrating their data as is while writes are still occurring on the source instance. "
However, as I responded:
"Ok thanks…
16 votes -
Deploy Changes without restarting mongod/mongos instance immediately.
Whenever we want to make changes, eg. set a new parameter or add new parameter in configuration (advance configuration options), after we save changes, review and deploy, automation immediately starts applying that change and does a rolling restart.
We need flexibility in restart, means one should have an option to perform immediate rolling restart or defer it to later time. We may apply multiple changes at different times and set one preferred window to restart instance instead of doing multiple restarts.15 votes -
Do not download EOL releases
Currently our Ops Mgrs keep re-downloading EOL releases of mongodb, e.g. mongodb-linux-x8664-2.6.12, mongodb-linux-x8664-3.0.15, etc. Ops Manager should automatically exclude EOL releases - they are taking up unnecessary disk space.
15 votes -
mongo push
Why doesn't MongoDB provide a tool (integrated or standalone) to operate document migration across on-prem (sharded) clusters? Suggestion might be to officially support tools like "mongo push", which may cover situations of hardware changes, production servers migration, re-sharding.
14 votes -
Apply Project Maintenance Windows to Global Alerts
Apply Project Maintenance Windows to Global Alerts
Make the existing Project-level maintenance windows also silence Global alerts associated with the Project.
We have many projects that share the Global Alerts and do not want to turn off all global alerts as we still need that alerting for the projects that are not being worked on.
In combination with the existing API for Project Maintenance Windows, this really allows full control.
14 votes
- Don't see your idea?