[SERVER-21661] v3.0 mongos and v3.2 cluster explain command are not compatible Created: 24/Nov/15  Updated: 14/Mar/17  Resolved: 22/Dec/15

Status: Closed
Project: Core Server
Component/s: Querying, Sharding
Affects Version/s: 3.2.0-rc3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: David Storch
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-8943 v3.0 mongos and v3.2 cluster explain ... Closed
Related
related to SERVER-20236 Read preference for an explain routed... Closed
is related to SERVER-21586 Investigate v3.0 mongos and v3.2 clus... Closed
Operating System: ALL
Sprint: QuInt E (01/11/16)
Participants:

 Description   

Some incompatibility observed include:

1. Using v3.2 shell on v3.0 mongos can cause the mongos to ignore the read preference setting. This is because the read preference setting used to be inside the explain subdocument in v3.0 and is now moved to the top level in v3.2.

2. Using v3.0 shell and v3.0 mongos with v3.2 shards to run an explain with slaveOk will result in:

{
	"ok" : 0,
	"errmsg" : "Failed to parse options: { slaveOk: true }. You may need to update your shell or driver.",
	"code" : 9
}



 Comments   
Comment by David Storch [ 22/Dec/15 ]

After further discussion, we have decided to close this issue as "Won't Fix". The format changes made to $readPreference and the find command during the 3.2 cycle were made knowing that this could cause some compatibility problems in mixed version scenarios. Our assessment was that these compatibility problems would not arise in common use cases. If we find that mixed version explain using readPreference or slaveOk is an important configuration to support, we can re-open this ticket and provide a fix.

Comment by David Storch [ 29/Nov/15 ]

renctan spencer, we did intentionally change how the shell passes read preference to mongos for explain. In 3.0, there is a special format for attaching read preference to explain; specifically, the read preference goes inside the find command itself:

{explain: {find: "collection", $readPreference: {...}}}

In 3.2, read preference for explain is just like read preference for any other command. We use the "wrapped" command form:

{$query: {explain: {find: "collection"}}, $readPreference: {...}}

This change was intentional in order to make read preference handling consistent for all commands. However, we still may want to fix problem #1. The likely approach for the fix would be to write compatibility code in the shell. If a 3.2 shell detects that it sending an explain command to a 3.0 mongos, it should use the deprecated read preference format that a 3.0 mongos can understand.

Comment by Randolph Tan [ 24/Nov/15 ]

Based on my last discussion with david.storch, it sounded like #1 was an intentional design decision.

Comment by J Rassi [ 24/Nov/15 ]

If we decide to fix #1, we may also want to fix related ticket SERVER-20236 (an outstanding issue with v3.0 mongos ignoring read preference for explain of operations other than find).

Comment by Spencer Brody (Inactive) [ 24/Nov/15 ]

Per offline discussion #2 above was previously considered and deemed to be acceptable behavior.

#1, however, is a bug that we should fix for 3.2.1

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