[CSHARP-640] ReadPreference and Commands such as Count Created: 07/Dec/12 Updated: 05/Apr/19 Resolved: 11/Dec/12 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.6, 1.6.1, 1.7 |
| Fix Version/s: | 1.8 |
| Type: | Task | Priority: | Minor - P4 |
| Reporter: | Andrew Fladmark | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 0 |
| Labels: | question | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
The later releases of the C# driver have added support for Read Preference and we've had great success using that in our environment. One aspect of the implementation around Command queries surprised us though. In previous versions, commands such as Count were forced to run against the primary and I'm pleased to see that's been addressed, but now with a read preference of Primary Preferred all of our 'secondary ok' commands like counts seem to always go to the secondary if one is available. Is this the desired/intended behaviour? To me, it doesn't seem correct or at least not intuitive. If I've said "I want everything to go to the primary, unless it's not available" why don't counts respect this? If the data on the secondary isn't wanted or shouldn't be trusted for a read why would it be ok to count potentially stale data? I understand the semantic difference that they're 'commands' but it seems the change in the driver was intended to recognise these as safe/more innocuous/query type commands which could/should respect the read preference we're providing. Thank you for all your hard work on the latest drivers. Since 1.6 we've seen a tremendous improvement in the handling of changes to replica set config/failovers. All much more graceful. Well done! |
| Comments |
| Comment by Andrew Fladmark [ 07/Dec/12 ] |
|
My apologies for not making that clearer sooner. I think what lead me to think of the C# driver in this case is that prior to the implementation of Read Preference, all counts were always run against the master. When we updated to 1.6.1 and simultaneously upgraded the MongoSes to 2.2 the counts shifted to the secondaries... seemingly in response to and yet in defiance of the specified read preference. According to the documentation at http://docs.mongodb.org/manual/applications/replication/: "mongos currently does not route commands using read preferences; clients send all commands to shards’ primaries. See So, apparently, full support is being worked on for 2.3 and the situation we have should be impossible. I'll have a check for any existing issues on MongoS and refile there. Thank you very much for your help Robert. It is greatly appreciated. |
| Comment by Robert Stam [ 07/Dec/12 ] |
|
Sorry, that was a typo. I was using a ReadPreference of PrimaryPreferred also. I didn't realize you were using a sharded environment. In that case, it's really up to mongos to decide where to send the commands. The C# driver's role in this case is to forward the desired ReadPreference to mongos. Can you file a new JIRA ticket against mongos? |
| Comment by Andrew Fladmark [ 07/Dec/12 ] |
|
Hi Robert, We're using PrimaryPreferred, not ReadPrimary in this instance (I can't confirm if it occurs with Primary only). I've enabled Database Profiling on the collection on the secondary and I get about 400 a second of these type of queries which I believe are counts? /* 0 */ }, , }, A similar trace on the primary reveals no such counts, just regular get and update queries as expect. The primary is likewise doing 400/s of those. If I shutdown the secondary, the counts do move over to the primary, but when both are online I'm unable to get anything but this situation. I've tried reversing the roles of the servers and the load reverses accordingly. This is a sharded collection of two replica sets. We have 2 servers and and an arbiter in each set. All the servers involved (config, mongoSes, and mongoDs are running 2.2.2 on Amazon Linux and/or Centos. We're running the 1.7 version of the C# driver today, but we've only just upgraded from 1.6.1. Both showed the behaviour consistently. We also have a non-sharded replica set which I've just checked and it doesn't seem to be exhibiting this behaviour (the primary is handling 200 queries and 200 commands per second there with no queries and maybe 10 commands a second on the secondary). Could this be an issue with the MongoS servers not respecting or not receiving the ReadPreference or is this maybe desired for some reason I'm not aware of in a sharded situation? I'm happy to produce a simplified chunk of code including our settings if its needed. |
| Comment by Robert Stam [ 07/Dec/12 ] |
|
I tried to reproduce this and for me the count commands are going to the Primary (not the Secondary) when using a read preference of ReadPrimary. Let me know if you have any more details on how to reproduce. |
| Comment by Robert Stam [ 07/Dec/12 ] |
|
How are you determining that your count commands are going to a secondary when your read preference is PrimaryPreferred? Does it make any difference whether you call Count on MongoCollection or MongoCursor? There is code in the driver to force most commands to be sent to the primary (commands that aren't specifically identified as being OK to send to secondaries), but I don't see any code that would force any commands to be sent to a secondary. If you can provide some code to reproduce it would be helpful (just to make sure we are looking at the same scenario). |