226 results found

1. Properties option for a server node

   Up until Ops Manager version 4.0+, we are/were able to view "Properties" of all servers/Replica sets by clicking on the ellipsis option on the each server. But will the latest versions of Ops Manager, that option is no longer available. We are often looking to quickly identify the allocated resources such as CPU/RAM on servers to help troubleshoot and deduct if we need to add more resources, so this has been a helpful feature we have used. We would very much like to see this feature option to be revived in the current versions of Ops Manager 4.2 and 4.4.4.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Project template defaults for replica set Attributes

   Our standard replica set deployments require a number of items to be set in the edit/modify area of each replica set...such as:
   sslMode
   directoryPerDB
   directoryForIndexes
   javascriptEnabled
   redactClientLogData

   Since we create hundreds of replica sets the amount of time spent repeatedly setting these attributes, which are considered "default" in our shop, adds up. Having the ability to set a template of defaults per project would save a great deal of time.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Only download to /mms/mongodb-releases/ those versions actually in use in a deployment

   /mms/mongodb-releases/ is continually updated with the most current minor release of each major version which can fill the partition.
   This request is for "Only download to /mms/mongodb-releases/ those versions actually in use in a deployment"
   eg if I am only using 4.2.20 in my actual deployments only download the most recent 4.2.x and not 3.6.x
   of course if I do decide to deploy a 3.6.x deployment this FR would need to automatically be bypassed and download my 3.6.x and the most recent 3.6.x.
   This request is similar to but not the same as another Feature Request:
   Do not download EOL releases

   /mms/mongodb-releases/ is continually updated with the most current minor release of each major version which can fill the partition.
   This request is for "Only download to /mms/mongodb-releases/ those versions actually in use in a deployment"
   eg if I am only using 4.2.20 in my actual deployments only download the most recent 4.2.x and not 3.6.x
   of course if I do decide to deploy a 3.6.x deployment this FR would need to automatically be bypassed and download my 3.6.x and the most recent 3.6.x.
   This request is similar to but not the same as another Feature Request:
   Do not download EOL… more

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Add to the Continues Backup UI more information about the snapshots

   Currently, the Ops Manager UI under Continues Backup only shows the following information about the snapshots:
   - Replica set name
   - Status
   - Last Snapshot
   - Last Oplog Slice

   It would be very helpful to also see:
   - Start date/time
   - Finish date/time
   - Backup duration
   - Snapshot size

   •  

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Support rolling rebuild index

   In some particular situation indexes need to be rebuild.
   It would be nice to support a rolling index rebuild like Ops Manager does for the standard create index.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Use word, not letter to define log levels in Ops Manager

   The following log messages are "info" level messages which can be found in the kubernetes logs from the ops-manager-db pods:

   {"logType":"mongodb","contents":"2020-12-16T02:42:28.557+0000 I  WRITE    [conn7329] update monitoringstatus.config.agentSessions command: { q: { _id: \"mongodb-rs-1.mongodb-rs-svc.mongodb.svc.cluster.local-48cc126fc451d9fa2ffa7569363971f2-5fbedc8dc354771c77dd1932\", s: \"KHNA9JiqXcos5V0d\" }, u: { $set: { s: \"PRIMARY\", p: true } }, multi: false, upsert: false } planSummary: IXSCAN { _id: 1 } numYields:0 queryHash:6C451E2F planCacheKey:38AD5486 ok:0 errMsg:\"E11000 duplicate key error collection: monitoringstatus.config.agentSessions index: cid_1_s_1 dup key: { cid: ObjectId('5fbedc8dc354771c77dd1932'), s: \\\"PRIMARY\\\" }\" errName:DuplicateKey errCode:11000 locks:{ ParallelBatchWriterMode: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } }, Mutex: { acquireCount: { r: 1 } } } flowControl:{ acquireCount: 1 } storage:{} 200ms"}
   
   {"logType":"mongodb","contents":"2020-12-16T02:42:53.558+0000 I  WRITE    [conn129189] update backupagentstatus.backupAgentSessions command: { q: { groupId: ObjectId('5fbedc8dc354771c77dd1932'), tag: \"unassigned\", $or: [ { sessionKey: \"5fd130ec9621b221acd18451\" }, { heartbeat: { $lt: 1608086273347 } } ] }, u: { $set: { groupId: ObjectId('5fbedc8dc354771c77dd1932'), tag: \"unassigned\", sessionKey: \"5fd130ec9621b221acd18451\", heartbeat: 1608086573347, hostname: \"mongodb-rs-0.mongodb-rs-svc.mongodb.svc.cluster.local\", addr: \"10.200.30.0\" }, $inc: { callsSinceSuccess: 1 } }, multi: false, upsert: true } planSummary: IXSCAN { groupId: 1, tag: 1 } keysInserted:1 numYields:0 queryHash:5BA6C0B5 planCacheKey:AEFF88E2 ok:0 errMsg:\"E11000 duplicate key error collection: backupagentstatus.backupAgentSessions index: groupId_1_tag_1 dup key: { groupId: ObjectId('5fbedc8dc354771c77dd1932'), tag: \\\"unassigned\\\" }\" errName:DuplicateKey errCode:11000 locks:{ ParallelBatchWriterMode: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } }, Mutex: { acquireCount: { r: 1 } } } flowControl:{ acquireCount: 1 } storage:{} 209ms"}
   

   Despite the fact that the word "error" is in these logs many times, and they have an error code, error name, and error message, this is considered an info level log.

   This is because the letter I is after the date. This makes using regex really hard when trying to setup alerts and monitoring, if I wanted to exclude info level logs.

   It would be great of instead of using a letter like I, W, or E, a word or abbreviation was used such as INFO, WARN or ERROR.

   The following log messages are "info" level messages which can be found in the kubernetes logs from the ops-manager-db pods:

   {"logType":"mongodb","contents":"2020-12-16T02:42:28.557+0000 I  WRITE    [conn7329] update monitoringstatus.config.agentSessions command: { q: { _id: \"mongodb-rs-1.mongodb-rs-svc.mongodb.svc.cluster.local-48cc126fc451d9fa2ffa7569363971f2-5fbedc8dc354771c77dd1932\", s: \"KHNA9JiqXcos5V0d\" }, u: { $set: { s: \"PRIMARY\", p: true } }, multi: false, upsert: false } planSummary: IXSCAN { _id: 1 } numYields:0 queryHash:6C451E2F planCacheKey:38AD5486 ok:0 errMsg:\"E11000 duplicate key error collection: monitoringstatus.config.agentSessions index: cid_1_s_1 dup key: { cid: ObjectId('5fbedc8dc354771c77dd1932'), s: \\\"PRIMARY\\\" }\" errName:DuplicateKey errCode:11000 locks:{ ParallelBatchWriterMode: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { w:

   … more
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Rewrite Informational Message "E11000 duplicate key error collection"

   Rewrite the informational AppDB log message so that monitoring tools such as Dynatrace and Splunk does not consider this message as an error message.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Provide a UI for uploading release archives to the mongodb-releases directory

   When Ops Manager is in "Local Mode", a system administrator must manually populate the mongodb-releases directory.

   Please consider adding a GUI for uploading the releases over HTTP(s) from the Ops Manager admin panel. This will alleviate server access restrictions/issues, as well as provide a quick method of populating the releases from a workstation in an internet restricted environment.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Update automation config through API without pushing entire config file

   For updating any Automation managed parameter, the only method through API is involving pushing the entire Automation config (which is a json file of hundreds lines) with modifications/addition all together.

   Even though I just want to update one single value.

   Is it a bit dangerous that there may be human mistake when modifying such a large json file. Wrong configuration may be push to the server.

   Graceful if there is a feature which allow user to partial update the configuration through API.

   Ref Case: 00730243

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Add ability to merge metrics when host renamed

    If a host is renamed and a new mapping is made with a unique ID, there is no way to merge the metrics to view the, historically.

    Adding the ability to merge metrics from previous hosts (when the user is sure the hosts are equivalent) would allow history to be viewed and maintained.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Ability to control Ops Manager log rotation from an Admin Page in the UI

    The Ops Manager Application Server Log Directory is typically located in /opt/mongodb/mms/logs/.

    Currently, the log rotation of the Ops Manager log files /opt/mongodb/mms/logs/mms0.log, /opt/mongodb/mms/logs/daemon.log and /opt/mongodb/mms/logs/mms0-access.log are configured by default to rotate the log file every day and compress it with a retention of 30 days. After 30 days the compressed files are deleted.

    Please allow the configuration of these log rotation settings through the Ops Manager Web UI.

    Currently, this can only be done manually. The default installation of Ops Manager includes a file in /opt/mongodb/mms/conf called logback.xml. This is the file that the library uses to configure Ops Manager logs and log rotation for /opt/mongodb/mms/logs/mms0.log and /opt/mongodb/mms/logs/daemon.log. By default this is configured with the following settings:

    
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${log_path}.log</file>
<encoder class="com.xgen.svc.mms.util.HeaderPatternLayoutEncoder$Classic">
<pattern>
%d{"yyyy-MM-dd'T'HH:mm:ss.SSSZ"} [%thread] %XF{groupId, "gid:%s "}%XF{jobId, "jobId:%s "}%-5level %logger [%file.%method:%line] - %msg%n
</pattern>
</encoder>
<!-- Rollover the logs once per day, keep 30 days, compressed -->
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${log_path}.%d{yyyyMMdd}.log.gz</fileNamePattern>
<maxHistory>30</maxHistory>
</rollingPolicy>
</appender>


    The file /opt/mongodb/mms/conf/logback-access.xml controls rotation of the /opt/mongodb/mms/logs/mms0-access.log. It has the same <!-- Rollover the logs once per day, keep 30 days, compressed --> policy.

    The logs will be compressed and rotated each day and deleted after 30 rolling days. If you modify the maxHistory option to 10, this should delete the files after 10 days. Please note that any upgrade of Ops Manager may overwrite this change with a new configuration file. Additionally, after modifying these values you will need to restart Ops Manager.

    The /opt/mongodb/mms/logs/mms-migration.log, mms0-startup.log and daemon-startup.log log files are not rotated as it contains only some log entries generated during the startup/migration phases of the Ops Manager Application Server processes.

    The Ops Manager Application Server Log Directory is typically located in /opt/mongodb/mms/logs/.

    Currently, the log rotation of the Ops Manager log files /opt/mongodb/mms/logs/mms0.log, /opt/mongodb/mms/logs/daemon.log and /opt/mongodb/mms/logs/mms0-access.log are configured by default to rotate the log file every day and compress it with a retention of 30 days. After 30 days the compressed files are deleted.

    Please allow the configuration of these log rotation settings through the Ops Manager Web UI.

    Currently, this can only be done manually. The default installation of Ops Manager includes a file in /opt/mongodb/mms/conf called logback.xml. This is the file that the library uses… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. mms.ldap.bindPassword

    We need to deploy ops manager with LDAP settings via yaml file where one of the setting "mms.ldap.bindPassword=" requires clear text password.
    Is there any secure option to this?

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. index review before sharding with OPS Manager

    Currently, when you use OPS Manager to shard a collection, it automatically creates a foreground index that exactly matches the sharding key, when such index doesn't exist. When the sharding key column(s) is(are)already prefixing an existing index, it's not sufficent.
    This is dangerous in Live environments because the whole database is blocked for a long time (sharded collections are usually big collections).
    So, several features could exist :
    - before continuing with sharding, OPS Manager warns that it needs to create this foreground index first. You can stop if you don't agree (and create this index by yourself first).
    - OPS Manager creates instead a background index or creates this index with the rolling manner.
    - OPS Manager is able to use one exiting indexes that contains the sharding key as a prefix of this index, no need to create a new one.

    Currently, when you use OPS Manager to shard a collection, it automatically creates a foreground index that exactly matches the sharding key, when such index doesn't exist. When the sharding key column(s) is(are)already prefixing an existing index, it's not sufficent.
    This is dangerous in Live environments because the whole database is blocked for a long time (sharded collections are usually big collections).
    So, several features could exist :
    - before continuing with sharding, OPS Manager warns that it needs to create this foreground index first. You can stop if you don't agree (and create this index by yourself first).
    -… more

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. bigpanda

    Prefer to get BigPanda integrated with OpsManager for event correlation .
    www.bigpanda.io

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Alerts if MMS Application goes down

    Dear Team,

    We are looking for an option to set alerts if any of the Ops Manager Application goes down in a HA environment. Being with HA configuration, we at least expect this feature to in place - as currently it looks like that OPS Manager is not aware of its own HA configuration.

    Mongo Case: 00723232

    Thanks,
    Tom

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Disk Space Grow Rate Metric

    DB Storage metric is not enough for us. We want to know the GROW RATE not the current value. We want to calculate the database used grow rate space regarding, comparing a past value with the current value. The result of the calculation can be positive (grow rate) or negative meaning database space did not grew up in that period. This is important to define tendency and trigger a disk expansion.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Request "Send SMS Test Message" tab similar to "Admin > Control Panel > Send Test Message" for email.

    This could be useful for testing SMS messages and twilio integrations.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. 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.

    12 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Ops Manager Base URL should support custom paths/sub-directories

    It may be desired to place Ops Manager behind a proxy or load balancer based on a URL path (aka sub-directory or prefix). For example, an nginx location may want to proxy pass connections to Ops Manager on "location /opsmanager"
    Currently, the Ops Manager Base URL appears to only accept and use the scheme, hostname/domain, and port. Additional path details are ignored by redirects sourcing from javascript functions and html links/resources.

    Current workarounds require a unique/dedicated server name for proxying or load balancing to Ops Manager web service(s).

    This feature request is for supporting custom URL paths when using Ops Manager behind a proxy or similar network appliances.

    It may be desired to place Ops Manager behind a proxy or load balancer based on a URL path (aka sub-directory or prefix). For example, an nginx location may want to proxy pass connections to Ops Manager on "location /opsmanager"
    Currently, the Ops Manager Base URL appears to only accept and use the scheme, hostname/domain, and port. Additional path details are ignored by redirects sourcing from javascript functions and html links/resources.

    Current workarounds require a unique/dedicated server name for proxying or load balancing to Ops Manager web service(s).

    This feature request is for supporting custom URL paths when using Ops… more

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Significantly Throttle or Skip MongoDB Agent Connections to Intentionally Disabled Clusters

    When performing an automated snapshot restore in Ops Manager, the MongoDB Agents shut down all MongoDB cluster members while the snapshot(s) are downloaded to the dbPath's.
    During this phase of the plan, the MongoDB Agents continue to attempt network connections to the cluster members; as frequently as ~4 per second per mongod. This traffic may pose problems for certain cluster deployment designs. Of note, clusters that are "micro-sharded" (multiple cluster members residing on the same physical hosts) and clusters with members in a remote datacenter can receive an amplification and/or excessive amount of connections relative to what the network can accommodate.

    This feature request is to make the MongoDB Agents state aware. If the agent plans call for shutting down the cluster members, skip or avoid frequent network connectivity tests until the download of the snapshot(s) completes.

    This enhancement will also have the benefit of reducing spurious error logging during cluster maintenance and restore from backup.

    When performing an automated snapshot restore in Ops Manager, the MongoDB Agents shut down all MongoDB cluster members while the snapshot(s) are downloaded to the dbPath's.
    During this phase of the plan, the MongoDB Agents continue to attempt network connections to the cluster members; as frequently as ~4 per second per mongod. This traffic may pose problems for certain cluster deployment designs. Of note, clusters that are "micro-sharded" (multiple cluster members residing on the same physical hosts) and clusters with members in a remote datacenter can receive an amplification and/or excessive amount of connections relative to what the network can… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close