1258 results found

1. Granular archiving window - schedule archiving at multiple times

   At present online archiving can only be sceduled once per day/week/month. There should be an option to add multiple scheduling windows in a day/week/month to enable schedules such as "every Saturday and Sunday", or "at 3AM and 10PM".

   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  ·  Online Archive  ·  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

2. Atlas shards with different clusters tiers

   For solutions of hot and cold storage, there is at least 2 options:
   - Online archiving
   - Hot and cold cluster (using a trigger and datalake)
   But these solutions have limitations (https://www.mongodb.com/docs/datalake/limitations/)

   There is another solution: using sharding.
   We can set shards like so:
   1 shard: Data from the last 2 months -> Hot data
   1 shard: Data between 2 and 24 months -> Warm data
   1 shard: Data more than 24 months -> Cold data

   The usage pattern: 95% of the accesses/queries go to shard with the hot data.
   On Atlas, we need to set the same Cluster Tier in all the shards.
   But in this scenario, the shards with warm and cold data, doesn't need as much CPU and RAM as the other, but it needs more storage.

   So, it would be good to have the availability to set custom cluster tiers for different shards.

   Something like:
   Hot data shard: M60 with 128GB
   Warm data shard: M40 with 256GB
   Cold data shad: M30 with 512GB

   For solutions of hot and cold storage, there is at least 2 options:
   - Online archiving
   - Hot and cold cluster (using a trigger and datalake)
   But these solutions have limitations (https://www.mongodb.com/docs/datalake/limitations/)

   There is another solution: using sharding.
   We can set shards like so:
   1 shard: Data from the last 2 months -> Hot data
   1 shard: Data between 2 and 24 months -> Warm data
   1 shard: Data more than 24 months -> Cold data

   The usage pattern: 95% of the accesses/queries go to shard with the hot data.
   On Atlas, we need to set the same… more

   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  ·  Other  ·  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. Minimum Oplog Retention Period - Set Minimum Oplog Window

   The documentation states: "New in version 4.4: Starting in MongoDB 4.4, you can specify the minimum number of hours to preserve an oplog entry." https://www.mongodb.com/docs/manual/core/replica-set-oplog/#minimum-oplog-retention-period

   The mongodbatlas_cluster resource in the terraform mongodbatlas provider only provides for the oplog_size_mb argument. https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/cluster#oplog_size_mb

   It would be nice to have that exposed so that terraform can update that value.

   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  ·  Monitoring and Metrics  ·  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. Query Online Archive over Web UI

   There is currently no possibilty to query a collection of an Online Archive via the Web UI of Atlas. This is only possible for the "normal" collections.
   It would be great if it would be possible to also query Online Archivce collections similar.

   This is related to the request of https://feedback.mongodb.com/forums/924277-data-federation-and-data-lake/suggestions/40949902-access-online-archive-in-customer-data-lake

   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  ·  Online Archive  ·  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

5. Should give download CSV option for getting all the slow queries details

   It will be better if a have an option to download all the slow query related information as whatever we see in the Atlas UI.

   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

   1 comment  ·  Performance Advisor  ·  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. API for slowQueryLogs should give response in a proper json format like in UI

   API for slowQueryLogs should give response in a proper json format like in UI rather than giving raw logs

   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  ·  Performance Advisor  ·  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. increasing the data retention of slow queries to a week.

   Currently atlas storing only 24 hours data for slow queries in Profiler. If it enable for a week atleast it will be very helpful for users to track the slow queries in the last week by sorting the query execution time.

   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  ·  Performance Advisor  ·  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. Test maintenance effects

   While Atlas provides the 'test failover' feature, this only takes effect on the primary of each shard. Customers who run large sharded clusters on Atlas require testing the effects of a full maintenance patch that would restart all mongod's and mongos's, config servers, etc. This feature is a request to improve the chaos engineering features of Atlas.

   At present, customers are being advised to change the TLS version of the cluster which could force restarts of all mongod's, mongos's and config servers. While this may be acceptable in non-production environments, it is unlikely in production environments.

   I believe there's an internal ticket for this already:
   https://jira.mongodb.org/browse/PRODTRIAGE-3411

   While Atlas provides the 'test failover' feature, this only takes effect on the primary of each shard. Customers who run large sharded clusters on Atlas require testing the effects of a full maintenance patch that would restart all mongod's and mongos's, config servers, etc. This feature is a request to improve the chaos engineering features of Atlas.

   At present, customers are being advised to change the TLS version of the cluster which could force restarts of all mongod's, mongos's and config servers. While this may be acceptable in non-production environments, it is unlikely in production environments.

   I believe there's an… 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  ·  Other  ·  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. WriteOnly DATA API

   Hello,

   We have a similar need as the one in ticket 44935186, but we would like a WriteOnly (no delete nor read) access to the API so a partner could push data in a collection without being able to read it

   Thx and have a nice day!

   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  ·  Data API  ·  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. Basic operational metrix support with instana and grafana

    Hi MongoDB Team,

    We are using grafana and instana SRE tools for application monitoring.

    But MongoDB did not exposing the basic statistics like Total number of records and record insertion / updation / selection rates (over a sepcific period of time ) with grafana and instana .

    Kindly note that grafana and instana are widely used as industry standard SRE tool and it will be really helpful if MongoDB team could also expose these kind of detailed statistics with grafana and instana.

    I would request you to prioritize this request since lack of these reports is creating an empty space in our SRE reporting side.

    Hi MongoDB Team,

    We are using grafana and instana SRE tools for application monitoring.

    But MongoDB did not exposing the basic statistics like Total number of records and record insertion / updation / selection rates (over a sepcific period of time ) with grafana and instana .

    Kindly note that grafana and instana are widely used as industry standard SRE tool and it will be really helpful if MongoDB team could also expose these kind of detailed statistics with grafana and instana.

    I would request you to prioritize this request since lack of these reports is creating an empty space… 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  ·  Monitoring and Metrics  ·  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

11. prometh

    Hi MongoDB Team,

    We are using grafana and instana SRE tools for application monitoring.

    But MongoDB did not exposing the basic statistics like Total number of records and record insertion / updation / selection rates (over a sepcific period of time ) with grafana and instana .

    Kindly note that grafana and instana are widely used as industry standard SRE tool and it will be really helpful if MongoDB team could also expose these kind of detailed statistics with grafana and instana.

    I would request you to prioritize this request since lack of these reports is creating an empty space in our SRE reporting side.

    Hi MongoDB Team,

    We are using grafana and instana SRE tools for application monitoring.

    But MongoDB did not exposing the basic statistics like Total number of records and record insertion / updation / selection rates (over a sepcific period of time ) with grafana and instana .

    Kindly note that grafana and instana are widely used as industry standard SRE tool and it will be really helpful if MongoDB team could also expose these kind of detailed statistics with grafana and instana.

    I would request you to prioritize this request since lack of these reports is creating an empty space… 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  ·  Monitoring and Metrics  ·  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

12. Allow disabling TTL Monitor (to allow restoring a snapshot)

    Problem:
    If you are restoring a snapshot to check the data, or to look at old data, and the collection has a ttl index, then a snapshot, once restored, will immediately mark a bunch of records for deletion, thus making it impossible to examine, export, or otherwise use that data.

    Solutions recommended by support include a) download the snapshot (which is very large) and load it on a local instance with the ttl monitor disabled. b) open a ticket to ask for the ttl monitor to be disabled on a target cluster, however once complete you also need to ask for the ttl monitor to be enabled, as otherwise "...eventually, the sessions collection may become full". This means that examining backup data now has multiple support delay loops involved.

    We need a way to restore a snapshot so that we don't lose data to the ttl monitor, without requiring support involvement.

    Possible Proposed Solutions:
    - Allow project owners to disable the TTL Monitor for a cluster, OR
    - Allow restoring a snapshot to include an option to disable TTL monitor for [ select a duration | v ], OR
    - Allow a new cluster, on creation, to be created with the ttl monitor (permanently?) disabled (and some other mechanism clearing the sessions or anything else thats necessary) ,OR
    - some other solution to allow marking a restore as "don't allow restored records to be ttl'd out"

    • It might also be useful to provide a mechanism for cleaning the sessions while the TTL Monitor is disabled

    Why this matters to me:
    - We tried to pull data from a backup to calculate a longer history and didn't realize that the data was being deleted while we were trying to export the data, which meant we provided bad info.
    - There was no real way for us to restore quickly - best case is a several hour delay after creating a cluster to restore to.
    - Without some solution here, relying on snapshots as backups seems really.... bad, and needlessly slow to recover.

    Problem:
    If you are restoring a snapshot to check the data, or to look at old data, and the collection has a ttl index, then a snapshot, once restored, will immediately mark a bunch of records for deletion, thus making it impossible to examine, export, or otherwise use that data.

    Solutions recommended by support include a) download the snapshot (which is very large) and load it on a local instance with the ttl monitor disabled. b) open a ticket to ask for the ttl monitor to be disabled on a target cluster, however once complete you also need to ask… more

    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  ·  Backup  ·  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. Allow API Access via Private Endpoint Connection

    To automate processes ATLAS Admin API is used but does only work if your cluster is not connected via Private Endpoint.

    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

    2 comments  ·  Data API  ·  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. upload prebuilt typescript provider for cdktf support

    I am trying to add the mongodb/mongodbatlas provider to a newly created cdktf project generated in the typescript language but the installation fails as npm is unable to find a prebuilt cdktf provider for the provider

    • 

    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  ·  Terraform Provider  ·  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. Atlas Administration API: Expose more information on cluster status

    We are using the Atlas Administration API in order to automate scaling a production database cluster deployment in a more fine-grained way than the existing autoscaling offer. The specific database cluster is deployed as a replica set, so there is a number of electable nodes (one primary + 2, 4 or 6 secondaries) and any number of read-only (RO) nodes.

    The goal is to be able to tune the number of nodes in a specific region, and being able to monitor the progress of the change being rolled out. Currently, the API offerings are too limited to do this effectively, but the web console clearly has access to the information we need.

    The current implementation of the returnAllMongodbProcessesInOneProject operation in the administration API lists all processes in the project, which would need to be filtered down to the processes that apply to just the specific cluster. The specific cluster processes do have a unique replicaSetName string in common but that name appears to be internal to Atlas and only appears in the connectionString -> standard URI for the given cluster. This information doesn't distinguish electable nodes from read-only nodes or analytics nodes, nor will it indicate if a machine is in the process of being deployed or decommissioned.

    Because of this the public administration API only gets you part of the way there, as it won't let a process on our side recover from being restarted during a cluster adjustment operation: there is no way of detecting a machine being decommissioned (which will delay deploying a new change), nor would a net-zero machine count change (e.g. moving from RO nodes to electable nodes) be observable.

    The web console on the other hand, has access to much more information, via the (private) https://cloud.mongodb.com/nds/clusters/{groupId}/{name} and https://cloud.mongodb.com/nds/clusters/{groupId}/{name}/instances endpoints; these are, respectively, a more detailed version of the public returnOneCluster operation and an array of process states specific to the cluster (so a filtered version of returnAllMongodbProcessesInOneProject) . These APIs lets us monitor cluster change operations much, much better, as they include more detailed node role information (electable vs read-only vs analytics).

    To properly manage scaling via the public API, we'd really need to have that information available in the public API too.

    We are using the Atlas Administration API in order to automate scaling a production database cluster deployment in a more fine-grained way than the existing autoscaling offer. The specific database cluster is deployed as a replica set, so there is a number of electable nodes (one primary + 2, 4 or 6 secondaries) and any number of read-only (RO) nodes.

    The goal is to be able to tune the number of nodes in a specific region, and being able to monitor the progress of the change being rolled out. Currently, the API offerings are too limited to do this effectively,… 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  ·  Other  ·  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. mongodbatlas_database_connection

    A resource that creates a connection for a database.

    resource "mongodbatlas_database_connection" "connection" {
      database        = "test"     # Name of database
      connection_type = "Standard" # or Private Endpoint
      database_user   = "test"     # Name of DB_USER
      method          = "shell"    # other options  "application | compass | vscode"
    
      # For Standard Connection
      ip = "accessAnywhere" # or other IP Address
    
      # For Private Endpoint
      endpoint = "" # ID of Private Endpoint
    }
    
    

    OUTPUT ARGUMENTS

    • id
    • connection_string
    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  ·  Terraform Provider  ·  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. Restored snapshots from a dedicated instance to a serverless instance

    I'd like to be able to spin up serverless instances for automatically provisioned dev/QA environments. I'd like to have production data available in them. So I'd like to restore a dedicated instance snapshot to a serverless instance.

    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

    2 comments  ·  Backup  ·  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. Replicaset elected new primary alert needs to show user given cluster name and the region in which the primary node is running

    Replicaset elected new primary alert needs to show user given cluster name and the region in which the primary node is running. For a multi-region cluster, cross-region failovers are a major application impacting event, so the Alert needs to include details around the region in which the primary is running. Also Alerts should use the same node names that are visible in the Atlas console and not use the internal node names in the Alert. This very critical for support teams ability to identify impacted clsuters and applications.

    7 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  ·  Alerts  ·  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. webhook

    Have the ability to specify template for the webhook being send. Currently this is static information and it would be better if it is possible to customize it. This will also make the integrations with not supported 3rd parties more easier and it doesn't have to create a mitm service that translates the atlas webhook to some other format.

    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  ·  Integrations  ·  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

20. Add project user role to Create App Services apps

    (Creating on behalf of a customer.)
    Create an Atlas project user role to only allow Create App Services apps (similar to the Atlas Search index creator role we have.

    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

    2 comments  ·  Other  ·  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