[SERVER-43310] mongos tries to connect to the secondary to create the index if `rs.slaveOk()` is set. Created: 13/Sep/19  Updated: 29/Oct/23  Resolved: 02/Jan/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.2.3, 4.3.3

Type: Bug Priority: Major - P3
Reporter: Linda Qin Assignee: Blake Oler
Resolution: Fixed Votes: 0
Labels: KP42, sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.2
Steps To Reproduce:
  1. Start a sharded cluster on 4.2:

    mongos> db.version()
    4.2.0
    

  2. Connect to the mongos and run rs.slaveOk().

    mongos> rs.slaveOk()
    

  3. After that, the insert succeeds - meaning that the mongos is connecting to the primary to insert the document.

    mongos> db.docs.insert({x:1})
    WriteResult({ "nInserted" : 1 })
    

  4. But ensureIndex fails - the mongos is trying to connect to a secondary to run ensureIndex.

    mongos> db.docs.ensureIndex({x:1})
    {
    	"raw" : {
    		"shard01/localhost:20002,localhost:20003,localhost:20004" : {
    			"ok" : 0,
    			"errmsg" : "not master",
    			"code" : 10107,
    			"codeName" : "NotMaster"
    		}
    	},
    	"code" : 10107,
    	"codeName" : "NotMaster",
    	"ok" : 0,
    	"errmsg" : "not master",
    	"operationTime" : Timestamp(1568357018, 1),
    	"$clusterTime" : {
    		"clusterTime" : Timestamp(1568357018, 1),
    		"signature" : {
    			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
    			"keyId" : NumberLong(0)
    		}
    	}
    }
    

Sprint: Sharding 2019-12-02, Sharding 2019-12-16, Sharding 2019-12-30, Sharding 2020-01-13
Participants:
Case:

 Description   

On the mongos, we can run rs.slaveOk() to set the read preference to secondaryPreferred.

After running rs.slaveOk() on the mongos, the insert operation will still be routed to the primary so the insert will succeed.

However, ensureIndex will be routed to the secondary, so this command would fail.



 Comments   
Comment by Githook User [ 02/Jan/20 ]

Author:

{'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}

Message: SERVER-43310 Always route a sharded cluster's createIndexes call through a replica set's primary node

(cherry picked from commit bbca8dbaf5a32ece935d2a14a8d7f94da41378e3)
Branch: v4.2
https://github.com/mongodb/mongo/commit/4f81376f5584638da9610c60260ab6e353607e74

Comment by Githook User [ 02/Jan/20 ]

Author:

{'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}

Message: SERVER-43310 Always route a sharded cluster's createIndexes call through a replica set's primary node
Branch: master
https://github.com/mongodb/mongo/commit/bbca8dbaf5a32ece935d2a14a8d7f94da41378e3

Comment by Esha Maharishi (Inactive) [ 18/Nov/19 ]

I think the issue is that the createIndexes command on mongosĀ uses the readPreference on the OperationContext.

It should be pretty easy to just change that line to use ReadPreference:PrimaryOnly like enableSharding does.

Generated at Thu Feb 08 05:02:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.