272 results found

1. Mongo replicaset init sync issue

   When we have large size mongo replica set, we may have to take out each nodes for maintenance for few hrs or days.

   In that case we have to increase size of Oplog to keep several days of transactions to resync nodes after maintanance.

   If the RS headroom falls below oplog window, then we have blow away data and do init sync to add node back after maintanence.

   The problem with very large size Oplog, will slow down any Change Stream process. Also it will occupy un neccasary space within collections.

   Can mongo offer alternative way to constantly dump oplog data to local file system? Then we can use this data to re-apply transactions, to sync failed nodes, instead of doing init sync. Some thing similar to archichive log mechanism for redo log, Oracle uses.

   This will avoid init sync issue for very large replica sets.

   Thanks
   Rama Arumugam

   When we have large size mongo replica set, we may have to take out each nodes for maintenance for few hrs or days.

   In that case we have to increase size of Oplog to keep several days of transactions to resync nodes after maintanance.

   If the RS headroom falls below oplog window, then we have blow away data and do init sync to add node back after maintanence.

   The problem with very large size Oplog, will slow down any Change Stream process. Also it will occupy un neccasary space within collections.

   Can mongo offer alternative way to constantly dump oplog… 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  ·  Replication  ·  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. Shard Drain/ Removal issue

   If we have more shards, and if want to remove few shards (more than 1), we use below command.

   db.adminCommand( { removeShard : "Shardname" } )

   Ex, if I have Shard 1, 2, 3, 4, 5. want to remove Shard 2 & 5.

   I want to remove one shard at a time to minimize impact to users , then want to remove, say Shard 2, then want to remove Shard 5.

   If we do this, some chunks from Shard#2 also get moved to "Shard#5", which is suppose to removed later. This causes Shard#5 chunk size increase. Then takes more time.

   Offcourse we can remove more than 1 shard in parellel (from version 4.4 onwards), but it may cause performance issue since balancer will be busy migrating chunks.

   So, it will be good, mongo an add new command, "mark the shards to be removed". No new chunks should move to these shards. Then we can remove 1 shard at time, to reduce performance impact.

   Thanks
   Rama

   If we have more shards, and if want to remove few shards (more than 1), we use below command.

   db.adminCommand( { removeShard : "Shardname" } )

   Ex, if I have Shard 1, 2, 3, 4, 5. want to remove Shard 2 & 5.

   I want to remove one shard at a time to minimize impact to users , then want to remove, say Shard 2, then want to remove Shard 5.

   If we do this, some chunks from Shard#2 also get moved to "Shard#5", which is suppose to removed later. This causes Shard#5 chunk size increase. Then takes more time.

   … 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  ·  Sharding  ·  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. Implement read-only fields and documents in database

   I haven't tracked down this functionality yet, so excuse me if it is already implemented.

   As a developer and system administrator I came to a dilemma how to prevent myself to make changes to documents.

   I can limit myself as a programmer, but as a administrator I can always logon to console and make changes ''by hand''.

   I was thinking of read-only field type, which once set, could not be updated nor removed from document (although backup and restore is the first problem which comes to mind). This limit should be set on a database level. Read-only field could typically hold some computed hash value, which would guaranty that the field or document was not changed in any way.

   There could also be collections with read-only documents. For example when ''read-only-document'' field is set, database would prevent any updates (deletes) to document. Although more problems can arise here. Like how to remove outdated documents or move them to archive collection.

   by
   TheR

   I haven't tracked down this functionality yet, so excuse me if it is already implemented.

   As a developer and system administrator I came to a dilemma how to prevent myself to make changes to documents.

   I can limit myself as a programmer, but as a administrator I can always logon to console and make changes ''by hand''.

   I was thinking of read-only field type, which once set, could not be updated nor removed from document (although backup and restore is the first problem which comes to mind). This limit should be set on a database level. Read-only field could typically… 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  ·  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

4. The ability to perform a quick rollback or rewind of the database

   This is along the lines of a flashback, to a previous point in time say from a very impacting change to data.. A large delete or data modification event. This avoids the need to take a complete outage for hours and hours restoring TBs of data and re-applying change logs. Would be great if this could be done to the granularity of a single or multiple collections too. This could use the oplogs present locally or in the oplog store.

   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  ·  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. `Blocking` Flag for Explain Output

   It's not always obvious which aggregation stages are blocking or non-blocking when viewing explain output for an aggregation command. It would be helpful to include a blocking flag for each stage of an aggregate command in its explain output.

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

6. restricted mode for database

   database in restricted mode can very helpful .. so we can carry out , lock users out, rebuild indexes, compact and other admin tasks.

   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

   2 comments  ·  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. Support for converting between UUID and String

   It would be nice to have UUID support for $convert and $toString functions - and maybe also having a new $toUuid function added.

   We have documents with UUIDs stored as UUIDs, and others where they are stored as Strings - and need to $lookup a document with an UUID type _id from a document where that uuid is stored as a String. As far as I can tell that is currently not possible.

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

8. Allow changing config values without restart

   It would be great if configuration changes could be effected without needed to restart nodes.

   For example, audit filter, enabling/disabling different security mechanisms.

   This would be especially useful for Atlas and clients with large clusters where restarts will cause a performance deficit due to cold cache after node restarts.

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

9. Provide straightforward syntax for 1-to-1 joins in aggregation

   The syntax for joins that bring back multiple documents from foreign collections is very straightforward and yields exactly what one would expect, but simple joins that are bread and butter in SQL require very convoluted and expensive to run syntax.

   Consider a product database that has products, categories and reviews collections. Each product has a unique category and may have multiple reviews. Getting all reviews in an aggregation is very straightforward (top stage), but getting categories, similar to SQL, is as convoluted as it gets (bottom stage).

   db.products.aggregate(
   [
       //
       // Document aggregates naturally aggregate foreign documents
       // into the primary document.
       //
       {$lookup: {
         from: "reviews",
         localField: "_id",
         foreignField: "product_id",
         as: "reviews"
       }},
   
       //
       // A simple join that is supposed to bring a couple of fields
       // into the primary document translates into this convoluted
       // syntax just to get those two fields.
       //
       {$lookup: {
         from: "categories",
         let: {category_id: "$category"},
         pipeline: [
           {$match: {
               $expr: {$eq: ["$_id", "$$category_id"]}
           }},
           {$project: {
               _id: 0,
               cat_name: "$category",
               cat_description: "$description"
           }}
         ],
         as: "category_details"
       }},
       {$replaceRoot: {
         newRoot: {
           $mergeObjects: [
             "$$ROOT", {$arrayElemAt: ["$category_details", 0]}
           ]
         }
       }},
       {$project: {
           category_details: 0
       }}
   ])
   

   Notice that keeping category.category and category.description in products, the noSQL-way, isn't an option because updating 10000's of products when category or description change is just not a good idea any way one looks at it. Denormalization is useful in many noSQL scenarios, but this isn't one of them.

   Having some simple join syntax that would identify the joined collection as a 1-to-1 join and would bring field names and values as if they existed in the primary document, possibly aliased via a projection-like syntax, would be extremely helpful in keeping aggregations readable, keeping data reasonably normalized, and would run much faster because it would be just multiple parallel BSON append calls when constructing aggregation results documents.

   Data for the query:

   products:
   
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d07e"},"name":"Product A","category":1,"price":111}
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"name":"Product B","category":2,"price":222}
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d080"},"name":"Product C","category":1,"price":333}

   categories:
   
{"_id":1,"category":"Clothing","description":"All kinds of clothing"}
{"_id":2,"category":"Electronics","description":"Cool gadgets"}

   reviews:
   
{"_id":{"$oid":"6140e7cadfe7b9d6e597d08a"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07e"},"review":"Product A is great","rating":4}
{"_id":{"$oid":"6140e813dfe7b9d6e597d090"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"review":"This product is horrible","rating":1}
{"_id":{"$oid":"6140e8eff4ff76778b48ba88"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"review":"This product is not the best, but usable","rating":2}


   The syntax for joins that bring back multiple documents from foreign collections is very straightforward and yields exactly what one would expect, but simple joins that are bread and butter in SQL require very convoluted and expensive to run syntax.

   Consider a product database that has products, categories and reviews collections. Each product has a unique category and may have multiple reviews. Getting all reviews in an aggregation is very straightforward (top stage), but getting categories, similar to SQL, is as convoluted as it gets (bottom stage).

   db.products.aggregate(
   [
       //
       // Document aggregates naturally aggregate foreign documents
       // into

   … 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

   3 comments  ·  Query and Aggregation Pipeline  ·  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. MultiTenant Abstraction

    Just as a time-series collection in MongoDB 5.0 abstracts the underlying implementation of the bucketing pattern, customers who implement a multi-tenant model through separate databases per tenant run into the issue of too many dhandles and would benefit from an abstraction of the implementation of a collection-with-discriminator-field - they would be able to meet their internal compliance requirement of separate databases per customer, and would have minimal changes to their code.

    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  ·  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. Retrywrite error fixed in Mongodb 4.4

    We have test the retry write in Atlas by using mongodb java driver in Mongodb 4.4 cluster. The error is similar to SERVER-53624(https://jira.mongodb.org/browse/SERVER-53624). The supporter respond the error will fix in Mongodb 5.0. We hope this error can also fixed in Mongodb 4.4

    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  ·  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. Make targeted query to a specific shard without using the shard key as part of query.

    As of right now you need to use the shard key as part of the query to make a target query to a specific shard. Would like the ability to make targeted query to a specific shard without using the shard key as a part of the query.

    Maybe one way of doing this is using index metadata to avoid scatter gather query and using that index meta data to instead make targeted queries on sharded clusters.

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

13. Easy Paging with offset

    Paging is a common functionality for REST APIs. When implementing paging queries for large datasets skip and limit is often not an option. When using query filters with non unique fields, such as creation date there can be problems such as duplicate entities on subsequent pages. It would be great to be able to additionaly pass in an offset document reference, that would be used as a start in case the filter does not lead to a unique starting point.

    so for example
    db.test.find({"creationDate" : {$gte:ISODate('2021-08-27T07:25:00Z')}, {"offset":<ObjectId>).sort({"creationDate":1}).limit(20)

    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  ·  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. Add a $median accumulator

    There is the $avg operator that returns the average of a set of values. Why not a $median?

    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

    planned  ·  1 comment  ·  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. Provide global collection-aggregated latency stats

    The global latency stats Server Status section currently aggregates all the latency information known to the server.

    We have a need for the same information except aggregated by collection.

    The actual command: db.serverStatus().opLatencies.

    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  ·  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. $lookup with the option to return only the first element

    Often I have a $lookup and the next stage is a $addFields { $first: "" }} because I know the lookup will return only one entry. It'd be nice to have this option directly in the lookup, so it'd return the first object instead of an array. Thanks!

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

17. When using EA, auto update the list of cluster node members similar to what happens within Atlas

    As we add new nodes, it requires us to update the URI. Would like a way to have this automatically update.

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

18. Would like the ability to restore a single zone based shard

    If the idea that data is stored within a region (via zone based sharding) and they are "just" replica sets, why can't we just restore a single shard? Right now we have to restore the entire cluster.

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

19. Create and use db links in Mongodb

    Allow Mongodb to access an external database for:
    1.select identifiers on an external rdbms (ex: postgres, sqls, oracle, ...)
    2.use these identifiers to perform aggregations in Mongodb

    Currently, it is necessary to use a third-party tool that connects to several data sources to perform these actions.
    The idea is to be able to perform these "joins" only in Mongodb CLI.

    Regards,
    Jerome

    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  ·  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 build for Linux Alpine and Debian

    A build in ARM support (Apple M1) for Alpine Linux (or Debian) is needed to run the mongocryptd process. Currently the official node docker images are available only in Alpine and Debian.

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