[DOCS-13613] Investigate changes in SERVER-31368: Log time spent waiting for other shards in merge cursors aggregation stage Created: 23/Apr/20 Updated: 13/Nov/23 Resolved: 10/Aug/21 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.0-rc5, 4.7.0, 4.2.10, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Backlog - Core Eng Program Management Team | Assignee: | Jason Price |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Issue Links: |
|
|||||||||||||||
| Sub-Tasks: |
|
|||||||||||||||
| Participants: | ||||||||||||||||
| Days since reply: | 2 years, 26 weeks, 1 day ago | |||||||||||||||
| Epic Link: | DOCSP-15042 | |||||||||||||||
| Story Points: | 3 | |||||||||||||||
| Description |
| Comments |
| Comment by Githook User [ 10/Aug/21 ] |
|
Author: {'name': 'jason-price-mongodb', 'email': 'jshfjghsdfgjsdjh@aolsdjfhkjsdhfkjsdf.com'}Message: |
| Comment by Githook User [ 10/Aug/21 ] |
|
Author: {'name': 'jason-price-mongodb', 'email': 'jshfjghsdfgjsdjh@aolsdjfhkjsdhfkjsdf.com'}Message: |
| Comment by Githook User [ 09/Aug/21 ] |
|
Author: {'name': 'jason-price-mongodb', 'email': 'jshfjghsdfgjsdjh@aolsdjfhkjsdhfkjsdf.com'}Message: |
| Comment by Jeffrey Allen [ 13/May/21 ] |
|
Hi bhaskarhnarula@gmail.com , this change is reflected in the 4.2.10 release notes. There, you will see an entry stating " The issue here was caused by upgrading the mongos before upgrading the shards. This procedure explains how to upgrade a sharded cluster to the latest revision of a MongoDB release: https://docs.mongodb.com/v4.2/tutorial/upgrade-revision/#upgrade-sharded-clusters. Following these steps in the order they are presented ensures that your deployment does not behave unexpectedly when upgrading minor versions. |
| Comment by Bhaskar Narula [ 13/May/21 ] |
|
Alright, after a day of digging into this I could understand that from 4.2.13 onwards all requests going out of mongos have recordRemoteOpWaitTime: true. Since rest of the nodes are lower than 4.2.13 they aren't able to recognise this attribute hence erroring out. Next hunt is to figure out a way to disable mongos passing this attribute to shards. Can someone please help me understand why don't have this available in the release notes of 4.2.13? |
| Comment by Bhaskar Narula [ 13/May/21 ] |
|
Team, Need quick help regarding the problem below - We run a sharded mongo database in production environment. Recently, we deprecated one of the mongos instances and the new instance has spawned up with a latest version of Mongo 4.2.14. Rest of the instances (shards, mongos and configs) are on 4.2.5. Soon after this we started facing a problem to which we can find absolutely no documentation over the web. The problem happens only for the node which has 4.2.14. Error - Command failed with error 40415 (Location40415): 'BSON field '$mergeCursors.recordRemoteOpWaitTime' is an unknown field.' on server 10.17.9.84:27017. The full response is {"ok": 0.0, "errmsg": "BSON field '$mergeCursors.recordRemoteOpWaitTime' is an unknown field.", "code": 40415, "codeName": "Location40415", "operationTime": {"$timestamp": {"t": 1620920773, "i": 1}}, "$clusterTime": {"clusterTime": {"$timestamp": {"t": 1620920773, "i": 1}}, "signature": {"hash": {"$binary": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "$type": "00"}, "keyId": {"$numberLong": "0"}}}}
We understand this happening owing to a long time taken between communication among shards but it wasn't the case with the lower version. Is there a configuration which we can override? Any leads would be helpful. |