[SERVER-36786] mongod and mongos result format for collMod differs Created: 21/Aug/18 Updated: 27/Oct/23 Resolved: 14/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 4.0.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Derick Rethans | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Sharding
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The documentation at https://docs.mongodb.com/manual/reference/command/collMod/#change-expiration-value-for-indexes shows the result document as:
We expect this format for the https://docs.mongodb.com/php-library/master/reference/method/MongoDBDatabase-modifyCollection/ method. However, we are adding additional topologies for our tests, and noticed that with a sharded cluster, the output format changes to:
This makes our test fail. I would argue that the outputs should always be the same, or documented in some form. |
| Comments |
| Comment by Esha Maharishi (Inactive) [ 28/Sep/18 ] | ||||||||||||||||||
|
ravind.kumar, yes, and it is also the format of any commands that use the 'appendRawResponses()' helper in the C++ code. A quick grep on any branch can show the commands that used it on that version On master, it looks like it's these:
So
| ||||||||||||||||||
| Comment by Ravind Kumar (Inactive) [ 28/Sep/18 ] | ||||||||||||||||||
|
Small clarification esha.maharishi - is this generally the output format for collMod in a sharded cluster? e.g.:
Where the raw document has one document per shard, containing the status and response of the collMod operation on that shard? | ||||||||||||||||||
| Comment by Ian Whalen (Inactive) [ 24/Aug/18 ] | ||||||||||||||||||
|
Sending to Sharding under the logic that catalog operations on sharded clusters are typically owned by the sharding team. CC milkie too. | ||||||||||||||||||
| Comment by Esha Maharishi (Inactive) [ 23/Aug/18 ] | ||||||||||||||||||
|
Hi derick, There is a bit of a fundamental issue in reporting the output of collMod in a cluster (as opposed to a single replica set), which is that collMod is not guaranteed to succeed or fail atomically across a cluster. Consider the scenario: 1) User sends collMod with "expireAfterSeconds: 5". It succeeds on shardA and shardB, but fails on shardC due to a network error between mongos and shardC. The collMod command reports failure. 2) User ignores the first collMod's failure, and runs another collMod with "expireAfterSeconds: 10". It succeeds on shardA and shardC, but fails on shardB due to a network error between mongos and shardB. Now the collection in the cluster looks like: shardA: expireAfterSeconds=10 shardB: expireAfterSeconds=5 shardC: expireAfterSeconds=10 collMod in a cluster reports each shard's individual response to help make the cluster's behavior after the collMod make more sense. Further, collMod in a cluster cannot report the same thing as collMod in a single replica set, because, as you can see above, it cannot report a single "expireAfterSeconds" value that reflects the state of every shard in the cluster. To avoid this anomalous behavior, it would be nice to make collMod a distributed transaction, which we hope to do at some point. Hope this helps explain the behavior, |