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!
- related to
-
SERVER-7876 Counts running against secondaries with ReadPreference of PrimaryPreferred
- Closed