OPERATIONAL DEFECT DATABASE
...
...
When mongos rewrites a query over a view as a query over the view's backing collection, it discards the readPreference. The result is that reads over views will always target the primary node of all involved shards, even if the application specified a read preference such as "secondary" or "secondaryPreferred". Note that mongos will always forward a query over a view to the primary shard in order to obtain the view definition, since it does not currently store view catalog information. This initial query will respect the readPreference. It is only as mongos rewrites the query given the view definition that we erroneously discard the server selection metadata.
james.wahlin@10gen.com commented on Wed, 5 Apr 2017 17:53:47 +0000: A fix for this issue was delivered under SERVER-28040. james.wahlin@10gen.com commented on Wed, 8 Mar 2017 20:29:25 +0000: I suspect readConcern is being discarded as well on mongos rewrite. Will confirm and fix under this ticket if it is the case.
Start a one-shard cluster consisting of a two-node replica set: var st = new ShardingTest({shards: {rs: {nodes: 2}}}); Observe which node becomes the primary of the replica set. Then connect to mongos and create both a collection and a view on that collection: db.c.drop(); db.createCollection("c"); db.v.drop(); db.createView("v", "c", []); Examine the logs to determine which node is targeted for the following queries: db.c.find().readPref("secondary").itcount(); db.v.find().readPref("secondary").itcount(); The query on c correctly targets the secondary, whereas the query on v incorrectly targets the primary.
Click on a version to see all relevant bugs
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.
