[SERVER-13044] Aggregation cursor behaves inconsistently in mixed-version cluster Created: 05/Mar/14  Updated: 07/Mar/14  Resolved: 05/Mar/14

Status: Closed
Project: Core Server
Component/s: Aggregation Framework, Sharding
Affects Version/s: 2.6.0-rc0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Samantha Ritter (Inactive) Assignee: Mathias Stearn
Resolution: Done Votes: 0
Labels: 26qa, aggregation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Operating System: ALL
Steps To Reproduce:

-Start a sharded cluster with the following members:
2.6 mongod (shard a)
2.4 mongod (shard b)
2.6 mongos

  • Shard a namespace and insert some data.
  • Stop the balancer.
  • Manually move chunks to both shards, run aggregation cursor query, get error.
  • Manually move chunks to 2.6 shard, run aggregation cursor query, get no error.
Participants:

 Description   

We deploy a sharded cluster with a 2.6 mongos, a 2.6 mongod as one shard and a 2.4 mongod as the second shard. In this configuration, we run an aggregation query with the cursor option specified:

> db.coll.aggregate([{$match: {a: { "$lte" : 10}}}], { cursor: { batchSize: 10 }})

If both shards have chunks on them, then we get the following error: "exception: All shards must support cursors to get a cursor back from aggregation"

However, if only the 2.6 mongod has data and the 2.4 shard is empty, then this operation runs the aggregation query without an error and returns the cursor normally.



 Comments   
Comment by Mathias Stearn [ 05/Mar/14 ]

We only support sharded agg cursors once the cluster is fully upgraded (as the error message indicates). We happen to work when all shards we need to talk to are on 2.6, since there is no reason to talk to nodes that don't support cursors.

Generated at Thu Feb 08 03:30:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.