[SERVER-46760] unrecognized field 'useNewUpsert' with sharded cluster running 4.2.1 Created: 09/Mar/20 Updated: 27/Oct/23 Resolved: 17/Mar/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Alex Lepailleur | Assignee: | Carl Champain (Inactive) |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
It is not possible to run Collection.aggregate or Collection.count_document with pymongo against a sharded cluster. It returns
Same query runs just fine against a non sharded collection with the same data in there. |
| Comments |
| Comment by Carl Champain (Inactive) [ 17/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We really appreciate your interest. However, we are not going to pursue a reproduction of this issue since you are not encountering it in 4.2.3. I will now close this ticket and mark it as "gone away". Thank you! | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Lepailleur [ 12/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Carl, I guessed that I should look for mongos.log, but there was no log file at all to be found. Please let me know if I can be of any help. I could probably setup a temporary shard and config server using Docker to reproduce this if needed. Thanks, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Carl Champain (Inactive) [ 12/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Sorry, I misspoke in my previous comment! I meant mongos.log (not mongod.log). Can you find it? Thanks, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Lepailleur [ 12/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Carl, I ran that but don't have a mongod.log (nor a mongodb.log) in /var/log/mongodb. I don't use a config file so I'd expect it to use the default location for logging.
Is this what you wanted? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Carl Champain (Inactive) [ 11/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
To help us understand what is happening, can you please
Once the three steps are completed, you can go back to the default log level by running
Kind regards, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bernie Hackett [ 10/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I've been told by the query team that useNewUpsert does not exist in the 4.2.1 codebase. They can't explain why you would still be getting this error. I'm going to move this ticket to the SERVER project for further discussion. This is definitely not a Python problem, since the Python driver does not set this field. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Lepailleur [ 10/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hello, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bernie Hackett [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Can you have you script log the server version? In PyMongo you can do: MongoClient.server_info()["version"] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Lepailleur [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hello, Thanks for the answer. Best regards, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bernard Gorman [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Many thanks for bringing this issue to our attention. This is not a problem with the Python driver, but is a result of running a version of mongoS on your cluster that is more recent that the version running on your shards. The only supported path for upgrading a sharded cluster, whether for a minor-version upgrade (e.g. from 4.2.1 to 4.2.2) or a major-version upgrade (e.g. from 4.0 to 4.2) is to upgrade the config servers first, then the shards, and finally the mongoS. When we are writing the code necessary to transition smoothly between versions, we base our decisions on the knowledge that a mongoS should never need to communicate with shards which have not yet been upgraded. In fact, if you attempt to upgrade the mongoS first when upgrading between major versions, it will actually refuse to start until the config servers and all shards are upgraded first. We aren't quite that strict when upgrading between minor versions, but it is still true that your cluster should never be running a mongoS with a later version than your shards. In this particular case, we backported a major improvement to 4.2.2 which fundamentally changes the way certain aggregation pipelines operate. Because the mongoS should always be upgraded last, it sends the useNewUpsert flag to the shards - which should all be on 4.2.2 at this point - to let them know that all shards have been upgraded, and that it is safe to switch over to the new mechanism. If you are running a 4.2.2 mongoS with 4.2.1 shards, then the shards will not understand this flag, and will throw the exception you observed. As such, I would recommend that you either upgrade your entire cluster to 4.2.3, or stick with mongoS 4.2.1 until such time as the rest of the cluster can be upgraded as well. Thanks again for taking the time to file this report! Best regards, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bernie Hackett [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I've discussed this with the query team. The upgrade path for a sharded cluster includes upgrading the mongos instances last, not first. There is a detailed explanation here. To solve this problem you have to upgrade the config servers and shards. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Lepailleur [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yes, any aggregate basically ``` col.aggregate([ { '$match': {'x': y} } ]) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bernie Hackett [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I would guess there is some difference in the commands being sent. Can you post a code example here that causes the command to fail with PyMongo? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Lepailleur [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks for the answer. I am planning to upgrade it but it's kind of outside of my control and need to wait for somebody else to do it so cannot test it immediately sadly. But it's definitely something which happened between 4.2.1 and 4.2.2 of mongodb. https://github.com/mongodb/mongo/blob/r4.2.2/src/mongo/db/pipeline/aggregation_request.h https://github.com/mongodb/mongo/blob/r4.2.1/src/mongo/db/pipeline/aggregation_request.h However, when connecting to my 4.2.1 mongos using robo3t, I can run aggregations without any issues while PyMongo fails with this exception. Any idea what might be different? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bernie Hackett [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Can you upgrade your cluster to 4.2.2? PyMongo doesn't use useNewUpsert. I'd never heard of it before now and it's not in our codebase anywhere. I'm guessing this is a bug in the server. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Lepailleur [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I realized robo3t returns the same when I run a mongos 4.2.3 to proxy a shard running mongod 4.2.1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Lepailleur [ 09/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Just wanted to add that I tried with 3.5 up to 3.10.1 and the log pasted here is for 3.10.1 |