272 results found

1. Support Two Array Fields in Compound Indexes

   Hi,

   I've come across a lot of use cases where the business logic has demanded unique constraints on 1-2 fields that have been modeled as arrays on documents. The cases that only contain a single array field is already taken care of using unique indexes in MongoDB, however the cases with 2 array fields have required application level constraints since the database only supports a single array field in compound indexes. While multiple arrays in a single index would massively increase the size of the indexes, it would be very helpful if it would still be possible. If there are other limitations that makes it difficult to implement support for N number of array fields, then my request would be to increase the limit from 1 to 2, as this would solve all of the cases that I've encountered (and any reasonable cases that I could think of).

   Thanks in advance,

   Hi,

   I've come across a lot of use cases where the business logic has demanded unique constraints on 1-2 fields that have been modeled as arrays on documents. The cases that only contain a single array field is already taken care of using unique indexes in MongoDB, however the cases with 2 array fields have required application level constraints since the database only supports a single array field in compound indexes. While multiple arrays in a single index would massively increase the size of the indexes, it would be very helpful if it would still be possible. If there are… 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  ·  Indexes  ·  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. hint support for $graphLookup

   Currently you can supply a hint to the aggregation call in order to tell MongoDB to use a specific index for the initial $match. But there is currently no way to specify which index to use for a $graphLookup later in the pipeline.

   I would like an optional hint property on the $graphLookup stage.

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

3. Support expressions in $densify range bounds

   The $densify aggregation pipeline stage seems unable to evaluate range bounds expressions, requiring the range bounds to be constant.

   See the following example (the collection testcoll contains a single documents with only the _id field):

   sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [0, 5], step: 1}}}])
   
   [
   
     { a: 0 },
   
     { _id: ObjectId("6284a16d64553eaf74b1e189"), a: 1 },
   
     { a: 2 },
   
     { a: 3 },
   
     { a: 4 }
   
   ]
   
   
   
   sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [{$toInt: "0"}, 5], step: 1}}}])
   
   MongoServerError: A bounding array must be an ascending array of either two dates or two numbers
   

   The first aggregate() call gives the correct result, and I'd expect the second one to evaluate the $toInt and yield the same result. Of course $toInt isn't a particularly useful use case but there are indeed useful computations which an user may want to do on the range bounds; for example, when using dates, one may want to truncate the start and end date to the hour or to the day before they are used for the densify operation.

   The $densify aggregation pipeline stage seems unable to evaluate range bounds expressions, requiring the range bounds to be constant.

   See the following example (the collection testcoll contains a single documents with only the _id field):

   sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [0, 5], step: 1}}}])
   
   [
   
     { a: 0 },
   
     { _id: ObjectId("6284a16d64553eaf74b1e189"), a: 1 },
   
     { a: 2 },
   
     { a: 3 },
   
     { a: 4 }
   
   ]
   
   
   
   sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [{$toInt: "0"}, 5], step: 1}}}])
   
   MongoServerError: A bounding array must be an ascending array of either two dates or

   … 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

   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

4. TTL Support within a document

   The current TTL implementation where documents can expire after a certain amount of time is extremely useful, especially because of its robustness in terms of if the db crashes.

   I would love for this to be extended upon with the ability to allow data within a document to expire after a set time. So for example, if you add data to a document you could set that data and that data only to expire with its own time to live value

   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

5. Enhancement on Native Auditing

   When we enable native auditing the following three information is missing. Its more useful from security aspects . Can it be considered to capture these information in current or future releases soon..

   Session ID
   
   OS user
   Service name

   Kannan

   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  ·  Security  ·  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. Raise an error when "majority" writes not possible

   This topic is related to https://www.mongodb.com/docs/v6.0/tutorial/mitigate-psa-performance-issues/ in a PSA ReplicaSet configuration.

   When you try to execute a command with writeConcern {w: "majority"} in a three-member Primary-Secondary-Arbiter configuration where one data bearing node is not available, then the command hangs forever - unless the missing member becomes available again or you reconfigure the ReplicaSet to {votes: 0, priority: 0} on the non-available member.

   Instead of waiting forever, MongoDB should rollback the change and raise an error. This behavior should apply mainly for operations where {w: "majority"} is set implicitly and cannot be changed by the user, for example at "renameCollection" issued on 'mongos'. You may introduce a new optional parameter which controls whether the command waits forever (the current behavior) or raises an error after a given timeout.

   This topic is related to https://www.mongodb.com/docs/v6.0/tutorial/mitigate-psa-performance-issues/ in a PSA ReplicaSet configuration.

   When you try to execute a command with writeConcern {w: "majority"} in a three-member Primary-Secondary-Arbiter configuration where one data bearing node is not available, then the command hangs forever - unless the missing member becomes available again or you reconfigure the ReplicaSet to {votes: 0, priority: 0} on the non-available member.

   Instead of waiting forever, MongoDB should rollback the change and raise an error. This behavior should apply mainly for operations where {w: "majority"} is set implicitly and cannot be changed by the user, for example at "renameCollection" issued… 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  ·  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. Add numerically-ordered index feature which forces a field to maintain ordering

   I would like MongoDB to add better support for ordered lists across documents in a collection. This feature would allow the user to designate a field such as "position", and the DB would ensure the values of that field across documents remain in a monotonically-increasing integer sequence 0, 1, 2, 3, ... N.

   I am the maintainer of a Ruby library called "Mongoid Orderable". This library makes numerically ordered field across documents. I'd like to ask MongoDB to investigate moving the functionality of this library to the server.

   What use case would this feature/improvement enable?

   This feature would be useful in a wide-variety of real world applications; ordered lists are extremely common. In my app (standard SaaS related to restaurant management) I have at least 20 instances of such ordered lists.

   Suggested implementation

   I propose to do this using a new "ordered" index type.

   For example, suppose my application has many Car documents, and I want to maintain the "position" of the Cars in a consistent order for each Dealer.

   I add the following index to the Car collection:

   Cars -> createIndex({ dealer_id: 1, position: 1 }, { ordered: 1 })

   Then in my Car collection, I see:

   Car A -> dealerid: ***, position: 0
   Car B -> dealerid: **, position: 1
   Car C -> dealer_id: **, position: 2
   Car D -> dealerid: yyy, position: 0
   Car E -> dealerid: yyy, position: 1

   Due to this special "ordered" index, the position field will always maintain a zero-based ordered value for the given scope. If I modify any member, this ordering is preserved:

   Change Car C position

   Car C -> updateOne(position: 1)

   Car A -> dealerid: ***, position: 0
   Car B -> dealerid: **, position: 2 <-- updated
   Car C -> dealer_id: **, position: 1 <-- updated
   Car D -> dealerid: yyy, position: 0
   Car E -> dealerid: yyy, position: 1

   Change Car C dealer_id

   Car C -> updateOne(dealer_id: yyy)

   Car A -> dealerid: ***, position: 0
   Car B -> dealerid: ***, position: 1 <-- updated
   Car C -> dealerid: yyy, position: 1 <-- updated
   Car D -> dealerid: yyy, position: 0
   Car E -> dealer_id: yyy, position: 2 <-- updated

   Change Car C position to be a very large value

   Car C -> updateOne(position: 999)

   Car A -> dealerid: ***, position: 0
   Car B -> dealerid: ***, position: 1
   Car C -> dealerid: yyy, position: 2 <-- updated, stays in order
   Car D -> dealerid: yyy, position: 0
   Car E -> dealer_id: yyy, position: 1 <-- updated

   Change Car C position to a non-numeric value

   Car C -> updateOne(position: "foo")

   update is ignored; nothing changes

   This feature should work with partial filter expressions, etc.

   I would like MongoDB to add better support for ordered lists across documents in a collection. This feature would allow the user to designate a field such as "position", and the DB would ensure the values of that field across documents remain in a monotonically-increasing integer sequence 0, 1, 2, 3, ... N.

   I am the maintainer of a Ruby library called "Mongoid Orderable". This library makes numerically ordered field across documents. I'd like to ask MongoDB to investigate moving the functionality of this library to the server.

   What use case would this feature/improvement enable?

   This feature would be useful… 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  ·  Indexes  ·  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. BSON::Proxy Proxy content from/to another collection

   I would like a mongodb data type, called

   BSON::Proxy # not indexable or searchable

   Which would hold the value of another collection & id.

   IE:

   BSON::Proxy({database: "this_one", collection: "blobs", _id: "123"})

   This would allow my code to request a field that would be used for reading ONLY IF REQUESTED in the projection.

   Example record:
   {
   id: "abc",
   username: "test user",
   blob: BSON::Proxy({database: "thisone", collection: "blobs", _id: "123"})
   age: 50
   }

   db.collection.find(query, projection, options)

   db.users.find({_id: "abc"}) # returns all fields except blob.

   db.users.find({_d: "abc", { _id: true, username: true, blob: true, age: true }}) # returns all fields including blob.

   This would allow me to store BLOBS with the document that are accessable only on demand and would not adversely affect performance
   when searching as the BLOB would not be loaded with the document

   Under the hood the BLOB would be stored in another collection tables.

   This maximizes scan and queries but allows for the simplification of a schema for storing large blocks of data.

   No FK validation would be expected.

   I would like a mongodb data type, called

   BSON::Proxy # not indexable or searchable

   Which would hold the value of another collection & id.

   IE:

   BSON::Proxy({database: "this_one", collection: "blobs", _id: "123"})

   This would allow my code to request a field that would be used for reading ONLY IF REQUESTED in the projection.

   Example record:
   {
   id: "abc",
   username: "test user",
   blob: BSON::Proxy({database: "thisone", collection: "blobs", _id: "123"})
   age: 50
   }

   db.collection.find(query, projection, options)

   db.users.find({_id: "abc"}) # returns all fields except blob.

   db.users.find({_d: "abc", { _id: true, username: true, blob: true, age: true }}) # returns all fields including blob.

   … 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  ·  Data Models  ·  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. Get metadata about source client connection that submitted a given change

   Currently with change streams it is impossible to know who or what connection initiated the changes.

   It would be a good feature to have to be able to receive some data about the source client connection that initiated a change.

   My particular use case is the following:

   I have an app that connects to Atlas. (source client connection)
   I can subscribe to change streams and then execute some logic when it applies.

   That app can scale to multiple instances.
   Each instance subscribes to the change streams.
   But I only want each instance to execute the logic that applies to only events that they have initiated through their own connection.

   Right now it seems impossible and the only way to do so would be to generate a unique App ID for each instance and log it in a separate collection for each change and subscribe to that. Although this would work, it would be simpler to have this feature built-in without the need for a separate collection.

   Maybe this could be good for other use cases.

   Another use case that I can think of, is the following:

   If a change is done in a collection that is not made by the source client connection, then apply some logic.

   For example: my app instance would execute some logic when data was manipulated outside my app, either manually or by third parties.

   Hope I am being clear, thanks!

   Currently with change streams it is impossible to know who or what connection initiated the changes.

   It would be a good feature to have to be able to receive some data about the source client connection that initiated a change.

   My particular use case is the following:

   I have an app that connects to Atlas. (source client connection)
   I can subscribe to change streams and then execute some logic when it applies.

   That app can scale to multiple instances.
   Each instance subscribes to the change streams.
   But I only want each instance to execute the logic that applies to only… 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  ·  Change Streams  ·  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. Enable BigInt Support for Blockchain Use

    Smart contracts on Ethereum and on Ethereum compatible chains are represented as 256bit integers. There are several libraries widely used to deal with these data types in JavaScript such as bn.js and BigNumber.js.

    A potential workaround could be to split the data, store using Decimal128, and recombine using Aggregation Framework. However, this would add performance and programming overhead that encourages customers to select alternatives to MongoDB.

    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  ·  Storage (Wired Tiger)  ·  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. Add pipeline stage for "downsampling" data

    Down sampling is an extremely common operation used when plotting time-series data on graphs when there is too much data to get a good looking/meaningful graph. This would pick and choose "important" data points based on an algorithm such as "Largest-Triangle-Three-Buckets" (https://skemman.is/bitstream/1946/15343/3/SS_MSthesis.pdf) instead of returning the entire data set.

    Not only would this make prettier graph but it will also reduce the overall payload returned from the data thus reducing network related latency.

    This would be an awesome addition to timeseries!

    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  ·  Time Series  ·  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 redundant createView() a no-op

    If I call createView() with params that match an existing view (in name and all other attributes), it returns an error. It'd be more convenient if the call simply succeeded without doing any work. The behavior I propose is analogous to the way that createIndex() behaves. With the current behavior my only choices are to (1) unconditionally drop and recreate the view, or (2) read the current view definition and see whether it matches the definition I want. The first choice is unacceptable because for a period of time (albeit a short one) the view won't exist and queries that use it will fail.

    This type of scenario comes up in the context of automatic deployment-time DB operations that my service does. Today these operations consist mostly of index creations and rely on the createIndex() behavior I describe above I would like to add view creations to the set of operations and have the same behavior.

    If I call createView() with params that match an existing view (in name and all other attributes), it returns an error. It'd be more convenient if the call simply succeeded without doing any work. The behavior I propose is analogous to the way that createIndex() behaves. With the current behavior my only choices are to (1) unconditionally drop and recreate the view, or (2) read the current view definition and see whether it matches the definition I want. The first choice is unacceptable because for a period of time (albeit a short one) the view won't exist and queries that… 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  ·  Query and Aggregation Pipeline  ·  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. Raise the limit of 16 MB JSON between aggregation stages

    When doing analytics, the 16 MB JSON limit between aggregation stages restricts the ability to process large amount of data. allowDiskUse does not help with all the various $operators and stages that we use. See ticket 00774514 for details.

    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

    0 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

14. Allow Dynamic Object In $project and $addFields

    Assume I have a field mapping defined in some configuration collection of my application. And this field mapping varies for different clients on my application.

    I would like to pass the dynamic object in my $project or $addFields stage

    Like:

    $project: {
    {$arrayToObject: "$field_mapping"},
    }

    {$arrayToObject: "$field_mapping"} would return something like

    "email" : "$data.Email",
    "phone" : "$data.Phone,
    "firstname" : "$data.FirstName",
    "lastname" : "$data.LastName",
    "preferredchannel" : "$data.Channel",
    "preferredlanguage" : "$data.LanguageCode",
    "emailchannel" : "$data.Email",
    "smschannel" : "$data.SMS",
    "province" : "$data.CustomerState"

    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  ·  Query and Aggregation Pipeline  ·  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. Implement restrict Network access list to improve Security risk

    Currently the Network access list admits to add IP addresses to allow connections from. However, we are using Private Endpoints to connect to our clusters; from Google Cloud we cannot add rules to PSC in the firewall, so this means that being in our VPN all devices internally has access to our mongo databases.

    How can we prevent access from any place in our company to our databases. This is a huge security risk.

    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  ·  Security  ·  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. Add SSO authentication support to mongoDB database

    Existing issue: One user has accounts in multiple mongoDB databases on Atlas that exist in different Projects and maybe Organizations as well. When he wants to switch from one database to the other from a 3rd party app, he has to provide his credentials every time.

    Adding SSO authentication support to the mongoDB databases would add flexibility to a user like that, to switch from one database to the other without being asked for his credentials every time when connecting from a 3rd party application.

    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  ·  Security  ·  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. add view，index，user，role to mongodb Change Stream

    I tested the changeStream of mongodb. The changes of adding view, index, user and role to mongodb are not reflected in changeStream, but the corresponding log can be found in oplog. I have an issue on https://jira.mongodb.org/browse/SERVER-66460 and got it confirmed, but Chris Kelly thinks this should be a feature. Hopes to add this feature in future versions

    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  ·  Change Streams  ·  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. Bidirectional Data Replication beetween two or more clusters

    In order to provide active-active deployments on multiple datacenter without need to shard data and route trafic based on shard-key. Develop a bidirectional replication with a conflict resolution method , for example , timestamp-based.

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

19. Use dedicated interface for replication and balancing

    Like many other big database system, MongoDB may support to specify dedicated interfaces for replication and/or for the balancer (sharding)

    Currently you can configure replication sets and shards members only by single hostname/IP-Address, i.e. all data is transmitted over the same network interface.

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

20. Make it clear an index not on present on all shards

    We recently had an issue where an index did not get created on all shards. When we ran getIndexes() on mongos it reported the index was present. So we dropped another redundant index thinking all would be well - it was not. We had serious performance issues on the shard that was missing the new index and our app was unavailable for a few hours whilst we re-created the missing index on a huge collection.

    It would be better if getIndexes called on mongos reported some sort of warning or indication that it was not present on all shards. The same should also be clear on mongo cloud's index view. Even better would be some guarantees that an index will get distributed to all shards, even if there is a transient problem with one of the shards.

    We recently had an issue where an index did not get created on all shards. When we ran getIndexes() on mongos it reported the index was present. So we dropped another redundant index thinking all would be well - it was not. We had serious performance issues on the shard that was missing the new index and our app was unavailable for a few hours whilst we re-created the missing index on a huge collection.

    It would be better if getIndexes called on mongos reported some sort of warning or indication that it was not present on all shards. The… 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  ·  Indexes  ·  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